[Top][All Lists]

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

bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update

From: Bob Friesenhahn
Subject: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update
Date: Sun, 29 Jan 2012 20:31:28 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Mon, 30 Jan 2012, JONES, BILL wrote:


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 
act libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,-z 
-Wl,defaultextract  -R/usr/local/lib -R/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 
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 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 

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 Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

reply via email to

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