libtool
[Top][All Lists]
Advanced

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

Re: libjava testsuite problem under i686-pc-linux-gnu


From: John David Anglin
Subject: Re: libjava testsuite problem under i686-pc-linux-gnu
Date: Mon, 28 May 2001 14:07:43 -0400 (EDT)

> > As a result, the pre-install version of Array_1 (lt-Array_1) has an
> > incorrect runtime location for libgcc_s.so.0.  It uses the old
> > version in the install directory rather than the new version in the
> > gcc build directory.
> 
> As posted in the libgcj mailing list, the problem is that libgcc_s is
> not a libtool library, so libtool can't do its magic of handling
> to-be-installed libraries.  Setting LD_LIBRARY_PATH so that libgcc_s
> is found in the right place might work, but then, it's possible that
> LD_LIBRARY_PATH is ignored when looking for dependencies of dependence
> libraries.  I seem to recall such an odd behavior is present on some
> platform; perhaps Solaris?

Setting LD_LIBRARY_PATH has no effect on the problem although it does
affect the location listed by ldd for libgcc_s in the dependent libraries.
The system is i386 Suse 6.1.  ldso is version 1.9.9.

Looking at the results database, it seems that some but not all pc systems
have this problem.  for example, the objc failures on the Automatic Build
System suggest that it has it.

I still don't understand why libtool doesn't use `-B' and `-L' when it
creates the `rpath' list for building the preinstall version of an
application.  Why does it matter whether a library is a libtool library
in the magic .libs subdirectory or a non-libtool library?  Don't we
need rpath's for both kinds of libraries to correctly build a preinstall
application?

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)



reply via email to

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