[prev in list] [next in list] [prev in thread] [next in thread]
List: gnash-dev
Subject: Re: [Gnash-dev] Building fltk; using *-config programs in configure
From: Rob Savoye <rob () welcomehome ! org>
Date: 2007-01-25 15:34:45
Message-ID: 45B8CE15.7030107 () welcomehome ! org
[Download RAW message or body]
Martin Guy wrote:
> Briefly, vanilla fltk compilation fails for me bcos the configure
> stuff doesn't use *-config programs.
Then the path lookup is wrong. If you run "CONFIG_SHELL=sh -x ; sh -x
configure" you can look in the output to see why it fails, or send it to
me and I'll look into it.
> [sidenote: I plan to rename fltk to fltk2 in the few places where it
> isn't already called that, to allow for a fltk interface for the
> ubiquitous and stable fltk1. Does that sound reasonable?]
Sigh, I wish Debian could be more up to date. Fltk1 and Fltk2 are pretty
different from each other, so you'd have to change the GUI code.
> the compilation of gnash then barfs on the final link with
> ...
> distcc -g -O2 ... -o .libs/gnash gnash.o ...
> ./.libs/libgnashgui.so: undefined reference to `FcObjectSetBuild'
> ./.libs/libgnashgui.so: undefined reference to `XftDrawSetClip'
> ./.libs/libgnashgui.so: undefined reference to `XftDrawString32'
> ./.libs/libgnashgui.so: undefined reference to `XRenderFreePicture'
> ...
> ./.libs/libgnashgui.so: undefined reference to `XftDrawSrcPicture'
> ./.libs/libgnashgui.so: undefined reference to `XineramaQueryExtension'
> ./.libs/libgnashgui.so: undefined reference to `XftDrawCreate'
>
Hum, we do look for Xft. I guess one of these days I should setup a
machine with Etch and see what's so different. Can you email me the
output of "ldd gnash" ?
> Bastian says:
>> I agree. I think we should consider adding <package>-config
>> support to gnashpkgtool.m4.
Probably. It would have to be done using the new $pathlist, so it
still works when cross configuring.
> 1) check pkg-config for information on a package
> 2) fallback to <package>-config script
> 3) fallback to testing for library existence in standard paths
And then try AC_CHECK_LIB and AC_CHECK_HEADER last.
> I'm studying autotool now (something I have been avoiding for
> years...) - does someone (Tomas?) want to look at this or should I do
> it as a learning exercise?
It's probably more efficient for me or Markus to fix these issues, but
learn autotools if you want. :-)
- rob -
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic