Bugzilla – Bug 174
Libtool files installed in an unusable way
Last modified: 2002-07-11 22:34:39
You need to log in before you can comment on or make changes to this bug.
I'm in charge of building the VDT for GriPhyN. Here is a problem I came across with the binary installation of Globus. ===== Short Description ===== When you install a binary bundles, the .la files that describe the libraries for libtool have hard coded pathnames in them that are incorrect. For example, libssl_gcc32pthr.la has two bad lines in it: dependency_libs=' - L/home/gose/latest/g/dm/sdk/lib /home/gose/latest/g/dm/sdk/lib/libcrypto_gcc32pt hr.la -ldl -lpthread' libdir='/home/gose/latest/g/dm/sdk/lib' Since these directories don't exist on my system, using libtool to link with Globus fail. ===== Longer description ===== I'm in charge of creating the VDT distribution for GriPhyn. I was building GDMP, and I had a problem because I was linking against our locally built-from- source Globus which used the gcc32dbgpthr flavor, but the VDT installs binaries bundles with the gcc32 or gcc32pthr flavor. Because GDMP uses dynamic linking, the binaries failed to execute. So I installed the binary Linux bundles that we install in the VDT. These are the binary bundles from the Globus web site. I used the "all" bundles, plus the pthreaded SDK bundles and the replica catalog bundles. Given that you distribute SDK bundles, one would hope that they would be usable for building software. Unfortunately, they are not. I just replicated this. I installed the "globus_data_management_bundle-sdk- linux-i686-gcc32.tar.gz" bundle, and it installed a number of .la files in my lib directory. I looked at "libglobus_ftp_client_gcc32.la", and the dependency_libs line and the libdir line contain hard-coded references to Scott Gose's home directory. When I try to use libtool, I get warnings and errors like: libtool: link: warning: library `/scratch.local/roy/globus/lib/libssl_gcc32pthr.la' was moved. libtool: link: cannot find the library `/home/gose/latest/g/dm/sdk/lib/libcrypto_gcc32pthr.la' That library is installed in my Globus lib directory. I don't have a /home/gose directory. Yes, there are work-arounds for this problem. I can edit all of the .la files to contain correct references. I can build Globus from source bundles. However, these are time-consuming and really shouldn't have to be done. When I install a Globus SDK, it should be a working SDK. -alain
> When you install a binary bundles, the .la files that describe the libraries > for libtool have hard coded pathnames in them that are incorrect. [...] > Since these directories don't exist on my system, using libtool to link with > Globus fail. [...] > Given that you distribute SDK bundles, one would hope that they would be usable > for building software. Unfortunately, they are not. [...] > Yes, there are work-arounds for this problem. I can edit all of the .la files > to contain correct references. I can build Globus from source bundles. However, > these are time-consuming and really shouldn't have to be done. When I install a > Globus SDK, it should be a working SDK. Roger. This sounds like a duplicate of bug 94. The shortest workaround is not to install all of Globus from source, but rather to install the globus_core package from source. This will create globus-build-env scripts in libexec which should pick up the correct libraries from your system. If the short version of the workaround does not work for you, let me know, and I will leave this bug open. If it does work for you, let me know, and I will close this bug as a duplicate. In either case, we agree with you that the binary SDK bundle should allow one to build software. We are currently working on that issue.
At 02:05 PM 7/11/2002 -0500, you wrote: >If the short version of the workaround does not work for you, let me >know, and I will leave this bug open. If it does work for you, let me >know, and I will close this bug as a duplicate. Thanks, one of the workarounds will work for me. I'm having trouble with the short workaround (probably my fault), but building from source will probably be fine. >In either case, we agree with you that the binary SDK bundle should >allow one to build software. We are currently working on that issue. That's my real goal: I'm glad you know about the problem and will fix it in the future. I'm sorry I didn't realize it was already reported in another bug. I did do a search in bugzilla, but didn't find it. -alain
No problem. Closing as duplicate. *** This bug has been marked as a duplicate of 94 ***