I haven't heard from you about this bug. I realize all of you are busy, and 
this may not seem important.

This is important: binary installations do not work correctly. Developers 
not using gpt to build their programs who link against Globus and use 
libtool can't get it to work without modifying all of the .la files. This 
includes European Data Grid developers, which is a fairly large number of 
people.

On the other hand, it is clearly a hard problem to solve. The files are 
created when you build Globus, and libtool wants hardcoded pathnames. What 
are you to do?

Here is one idea: In the VDT Pacman installation, I install and run a 
script to fix the hardcoded pathnames after I install Globus. This could be 
made into a globus setup package, and provided with Globus. Then when 
people do a gpt-postinstall, the script would be run, and the .la files 
would be fixed.

Would this be a reasonable way to approach the problem? If so, I would be 
willing to help write this script, if someone could point me at any 
information about writing setup scripts for Globus, I can make sure to fit 
within the standards you have.

-alain

The Globus build process ignores the dependency_libs from the .la files (as
libtool is actually really bad about keeping a sane list of dependency_libs, and
that is actually one of the things the GPT does really well).

Perhaps you are bootstrapping your own packages, using a stock (unpatched)
version of libtool?  If that is the case, I could see this potentially coming up
and being a problem.  But if you use the patched versions of libtool that we use
(or have your own package that doesn't use libtool at all would be fine building
against our binary SDKs.

Ahh, I just noticed that in the second comment, it was acknowledged that this is
a problem (only) for those trying to build their own programs using libtool.
It would not be unreasonable to have a script that could munge the .la files,
but it would be a lot nicer, and probably easier in general if either people
used our patched versions of libtool, or, ideally, if we got the autotools
people to add a switch that lets one turn off libtool's use of dependency_libs.

>Ahh, I just noticed that in the second comment, it was acknowledged that 
>this is a problem (only) for those trying to build their own programs 
>using libtool.

Right: they use globus-makefile-header to figure out what libraries to link 
against, and a libtool to link against them. They are not using gpt-build.

>It would not be unreasonable to have a script that could munge the .la files,
>but it would be a lot nicer, and probably easier in general if either people
>used our patched versions of libtool, or, ideally, if we got the autotools
>people to add a switch that lets one turn off libtool's use of 
>dependency_libs.

I'm not sure what you are suggesting exactly. Are you saying that if they 
use the libtool installed with Globus, it simply won't be a problem? That 
because they are using a different libtool, it is a problem? The libtool in 
Globus specifically works around this problem?

Is there anything special to know about using the libtool you provide? Just 
use sbin/libtool-gcc32dbg or sbin/libtool-gcc32dbgpthr as a drop-in 
replacement for another libtool?

Thanks for your help--this is extremely valuable knowledge for me.

-alain

Alain,

In going through ancient bugs, I came across this one.  I suspect that I have
answered your question at some point outside of bugzilla, but for posterity I
will reply here: In answer to your question, the globus patched version of
libtool simply ignored the dependency_libs from the .la file.  Thus, it might
not be possible for someone to use it as a drop in replacement for a standard
libtool, if they were expecting to use the dependency_libs information for
their linking.

The recommended way for external applications to get a correct link line for
linking to globus libraries has always (well, since 2.0) been to use
globus-makefile-header.