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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
