[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Building fltk; using *-config programs in configure

From: Martin Guy
Subject: [Gnash-dev] Building fltk; using *-config programs in configure
Date: Thu, 25 Jan 2007 14:02:16 +0000

I'm opening this issue to the list for the record...

Briefly, vanilla fltk compilation fails for me bcos the configure
stuff doesn't use *-config programs.

Gnash fltk uses fltk2, while on Debian etch, only fltk1.1 exists (and
this will be the case for the next 3 years or so since Debian etch is
about to become the new "stable") so you have to install fltk2.0.1.*
from cvs source.

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

the compilation of gnash then barfs on the final link with
distcc -g -O2 ... -o .libs/gnash gnash.o ...
./.libs/ undefined reference to `FcObjectSetBuild'
./.libs/ undefined reference to `XftDrawSetClip'
./.libs/ undefined reference to `XftDrawString32'
./.libs/ undefined reference to `XRenderFreePicture'
./.libs/ undefined reference to `XftDrawSrcPicture'
./.libs/ undefined reference to `XineramaQueryExtension'
./.libs/ undefined reference to `XftDrawCreate'

I managed to hack it into building by disabling xinerama in the fltk2
build (you can't disable xft at present; the fltk build fails :-/) and
by adding two lines in gui/

FLTK_SRCS = fltk.cpp fltksup.h $(FLTK_AGG_SRCS) $(FLTK_CAIRO_SRCS)
#   FLTK2_LIBS only has '-L/usr/local/lib -lfltk2 ' and the build fails
#   missing Xft* and libXinerama, dependencies of fltk2.
#   fltk2-config --ldflags outputs -lXft and the rest as it should.
#   I have added the following 2 lines and diked Xinerama out of
#   my local fltk build to get gnash-fltk to build.
#   The real answer is to respect what ftlk2-config --ldflags says.

Bastian says:
I agree. I think we should consider adding <package>-config
support to gnashpkgtool.m4.

On Thu, 2007-01-25 at 12:57 +0000, Martin Guy wrote:
I wonder where it gets FLTK_LIBS from then...

It searches common paths for the library file derived from the
first argument, in this case fltk2. So it looks for libfltk2.{so,a}
in /usr/local/lib, /opt/local/lib, etc. gnashpkgtool.m4 currently
already attempts to detect the package using pkg-config -- but
fltk doesn't install pkg-config scripts. So I think we want this sequence:

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

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?


reply via email to

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