gnash-dev
[Top][All Lists]
Advanced

[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 -




reply via email to

[Prev in Thread] Current Thread [Next in Thread]