Package: libtool;
Reported by: "JONES, BILL" <rj7252 <at> att.com>
Date: Sun, 29 Jan 2012 21:50:02 UTC
Severity: normal
View this message in rfc822 format
From: "JONES, BILL" <rj7252 <at> att.com> To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> Cc: 10643 <at> debbugs.gnu.org Subject: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update Date: Mon, 30 Jan 2012 05:37:34 +0000
OK...so I went to the source tree an edited configure.
cd src/libtool-2.4.2/tests/demo
vi configure
Changed:
solaris*)
...
shlibpath_var=LD_LIBRARY_PATH
TO
solaris*)
...
shlibpath_var=LD_LIBRARY_PATH_64
Reran the test and everthing worked.
If configure had --enable-64bit and handled it....
Your next point about libtool:
So if I have more than one "lib" and I need it to pay attention to my/lib instead of /usr/local/lib, how can I make libtool stop running home to mommy.
crle
Yes...I know crle...it's a system wide root enabled demon that the company police would rather not have users have access to. Can't use it for this. -R{path} will have to do for compiled objects, so build scripts have to know what they are doing.
Bill
________________________________________
From: Bob Friesenhahn [bfriesen <at> simple.dallas.tx.us]
Sent: Sunday, January 29, 2012 9:31 PM
To: JONES, BILL
Cc: 10643 <at> debbugs.gnu.org; bug-libtool <at> gnu.org
Subject: RE: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update
On Mon, 30 Jan 2012, JONES, BILL wrote:
> Bob,
>
> I believe this is what is happening.
>
> The test scripts are setting LD_LIBRARY_PATH to include the .libs
> directory for the temporary shared library, but the linker only
> seems to be looking at LD_LIBRARY_PATH_64.
>
> I was going to try to hack the test scripts to see if I changed it to _64 to see if the test suddenly worked.
Keep in mind that the wrapper does entirely wrap the exe so there is
no need to re-run the whole 'make check' to test a change to the
wrapper. Just try running the wrapper before and after and see if
things change.
You can also edit the 'libtool' script (in the build tree) directly.
I see two occurances of LD_LIBRARY_PATH. You can replace these two
occurances with LD_LIBRARY_PATH_64 and see if things clear up.
> I see support for such tests in other tools, but not in
> libtool...and glib is giving me a headache as well since it wants to
> always link with /usr/local/lib/libiconv.so instead of honoring the
> -R -L options in LDFLAGS and/or LD_LIBRARY_PATH_64...the spelled out
> path in actually on the command line put there by the bundled
> libtool with glib...which is why I was trying to get a better
> working version...libtool in glib is 2.2.
Ugh. Is there a /usr/local/lib/libiconv.la file?
The Solaris 10 ld.so.1 manual page suggests that LD_LIBRARY_PATH_64
may influence where the linker ('ld') searches for libraries as well.
The manual page is not very clear on this.
> o .libs/gslice.o .libs/gslist.o .libs/gstdio.o .libs/gstrfuncs.o .libs/gstring.o .libs/gtestutils.o .libs/gthread.o .libs/gthreadpool.o .libs/gtimer.o .libs/gtree.
> o .libs/guniprop.o .libs/gutf8.o .libs/gunibreak.o .libs/gunicollate.o .libs/gunidecomp.o .libs/gurifuncs.o .libs/gutils.o .libs/gvariant.o .libs/gvariant-core.o .
> libs/gvariant-parser.o .libs/gvariant-serialiser.o .libs/gvarianttypeinfo.o .libs/gvarianttype.o .libs/gprintf.o .libs/giounix.o .libs/gspawn.o -Wl,-z -Wl,allextr
> act libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,-z -Wl,defaultextract -R/usr/local/lib -R/usr/local/lib -R/appl/gfpip/local/lib/sparcv9:/usr/local/lib/
> sparcv9 -L/appl/gfpip/local/lib/sparcv9:/usr/local/lib/sparcv9 /usr/local/lib/libiconv.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -L/us
> r/X11R6/lib -L/usr/local/BerkeleyDB.4.7/lib /usr/local/lib/libintl.so -L/usr/local/BerkeleyDB.4.2/lib -lc -m64 -m64
> ld: fatal: file /usr/local/lib/libiconv.so: wrong ELF class: ELFCLASS32
> ld: fatal: File processing errors. No output written to .libs/libglib-2.0.so.0.2513.0
> collect2: ld returned 1 exit status
>
> The above example is the libtook in /usr/local/lib/libtool since I am having problems with the 64bit one.
>
> All the above in RED seems to be added by libtool, but I can't find
> it anywhere in the source or build directories....
Sorry, I don't see color. I assume that the RED bit includes
/usr/local/lib/libiconv.so. Check for a /usr/local/lib/libiconv.la
file. This is just a text file so you can use 'cat' on it and see its
content. Libtool searches for .la files to learn more about how to
link with a library.
> Then glib was next....with the problems.
>
> I need glib for atk which I need for vim as well as glib.
You have likely entered a twisty turny path of conflicting
dependencies. Other problems commonly encountered on Solaris 10 is
with pkg-config, which likes to offer up dependencies on old libraries
that you don't want to use.
> These are the environment variables I am using:
>
> #
> # Setup basic LIBRARY paths
> #
> LD_LIBRARY_PATH_64=${LIBTARGET64}:/usr/local/lib/sparcv9
> export LD_LIBRARY_PATH LD_LIBRARY_PATH_64
LD_LIBRARY_PATH is pretty evil. I use 'crle' to configure the system
search paths on my Solaris 10 systems rather than attempting to use
environment variables:
% crle -64
Configuration file [version 4]: /var/ld/64/ld.config
Default Library Path (ELF): /lib/64:/usr/lib/64:/usr/local64/lib
Trusted Directories (ELF): /lib/secure/64:/usr/lib/secure/64 (system default)
Command line:
crle -64 -c /var/ld/64/ld.config -l /lib/64:/usr/lib/64:/usr/local64/lib
Some people are deathly afraid of invoking 'crle', but it seems
similar to Linux 'ldconfig' that people don't seem to be so afraid of.
Bob
--
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.