Did anyone read my posting? I got no help or response whatsoever... If
you just don't know how to answer I guess just don't respond, but if you
don't understand my question, let me know and I'll try to explain again.
David Durham wrote:
> 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
>
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
