libtool
[Top][All Lists]
Advanced

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

excluding libraries


From: David Durham
Subject: excluding libraries
Date: Tue, 19 Mar 2002 12:52:11 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204

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






reply via email to

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