[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Building fltk; using *-config programs in configure
From: |
Rob Savoye |
Subject: |
Re: [Gnash-dev] Building fltk; using *-config programs in configure |
Date: |
Thu, 25 Jan 2007 08:34:45 -0700 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20070102) |
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 -