Hi,
I have a question about using libtool...
Here's the situation:
Our project has the FOX gui toolkit as a dependency. FOX is
autoconfiscated and uses libtool too, so when FOX installs itself
there is a libFOX.la created in /usr/lib. One unfortunate thing
about FOX is that it has some OpenGL widgets in it, and thus, the
libFOX.la files has some OpenGL libs on the dependency_libs="..."
line. Now, my application (an audio editor) does not use any of
these OpenGL widgets from FOX. And if we just (temporarily) edit that
dependancy_libs line in the libFOX.la file then the final link stage
does not complain since no OpenGL functions were ever invoked.
Now, FOX's configure script does have an option to disable the
OpenGL widgets, and I built FOX from a tarball and disabled GL for a
while, but now that I'm trying to make this package as portable as
possible, I'm testing using the rpms for FOX (on my mandrake machine)
and the packager did not disable OpenGL.
The reason this is an issue with me is that not all machines will
have OpenGL installed and setup (and some of my beta testers have
attested to this). So I'm seeking a way to exclude the dependency on
the GL libs even though FOX's .la file says it needs them.
I have come up with two possible work-arounds, neither of which I like
very much:
1) At application build-time, programmatically copy the libFOX.la
file to a temporary place and sed out the libGL lines from the
dependency_libs line, then somehow get libtool to find the temporary
copy of libFOX.la instead of the one in the system lib directory.
2) Just after configure creates the libtool script in the package
programmatically apply a patch to the libtool script which adds a line
that seds out the libGL items on the dependancy_libs variable. I have
already created this patch file and it works, but I can't be sure that
this patch would necessarily work on anyone's machine who may have a
slightly different version of libtool and they
re-libtoolized/re-autoconfed/re-automaked the package (a simple
'bootstrap' script we created in the package's toplevel directory).
Both of these solutions seems a little kludgy to me, so I'm asking
this mailing list for possibly a better way.
We also have the GNU CommonC++ library as a dependancy but it hasn't
caused problems yet because I don't think they're properly building
the .la since the dependaency_libs line in their .la file is blank.
Perhaps they meant to do this so that this problem wouldn't arise, but
it sort of defeats the purpose of libtool's convenience of not having
to know all the dependancies. (i.e. not having to make your
application link against -lpthread if using commonc++'s thread wrapper
API which wouldn't necessarily be called 'pthread' on another
platform... that is, let commonc++ figure out this stuff when it was
built)
Also, FOX uses several image libraries (libjpeg, libtiff, libpng),
and I don't use any of these formats (yet.. maybe png somday) either.
And these must be installed on the system for my application to link
(using libtool to link) even though I don't use this functionality.
I guess I could describe the problem more generally in the following way:
Anytime a package(I'll call this 'level 1') depends on a rather
general-purpose library('level 2') and that libraries depends on other
libraries('level 3') the final package always ends up linking against
many unneeded level 3 libraries. And thus, the user attempting to use
the (level 1) package ends up having to unnecessarily install the
level 3 libraries which frustrates the whole process.
Now my question is: Is there a prescribed method to solving this
problem? And if so, what is it?
Also, I know that commonc++ has the ccgnu-config script which can be
used to get linker flags and include flags, but I thought that libtool
was a superior replacement for this method of doing things.
Thanks,
Davy
BTW- My project is named 'ReZound' and housed at
http://rezound.sourceforge.net
_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool