libtool
[Top][All Lists]
Advanced

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

sparc openbsd 3.2 and cvs libtool


From: Kevin Ryde
Subject: sparc openbsd 3.2 and cvs libtool
Date: Sat, 12 Apr 2003 10:50:07 +1000
User-agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux)

I've been giving a recent libtool cvs snapshot (last week) a run in
gmp and have had trouble on sparc openbsd 3.2.

libgmp.la is a C library, and libgmpxx.la is a C++ library depending
on it.  A test program (in a subdirectory as it happens), uses both.
When it tries to run (against the uninstalled libraries of course),
the wrapper script gets an error

  /media/home/tege/gmp-obj/turbo/tests/cxx/.libs/t-assign: can't load library 
'./.libs/libgmp.so.6.0'

It seems libgmpxx.so.3.2 has ended up with a NEEDED record asking for
./.libs/libgmp.so.6.0, but that's not found in the path set by the
wrapper script.

  
LD_LIBRARY_PATH=/home/tege/prec/gmp-obj/turbo/tests/cxx/../../.libs:/media/home/tege/gmp-obj/turbo/.libs

Is it normal for a dependent library to have a path on its NEEDED
libraries?  I guess it's not on other systems, but I'm not up with the
conventions on openbsd.

It seems it comes about because libgmp.so.6.0 doesn't have a SONAME
record, so when creating libgmpxx.so.3.2 the linker puts in the path
it got on the command line.

Should there be a SONAME in libgmp.so.6.0?  The command run is just
something like

  gcc -shared  -fPIC -DPIC -o .libs/libgmp.so.6.0  .libs/assert.o
    ... scanf/.libs/vsscanf.o   -mcpu=v8

For what it's worth the libgmpxx.so.3.2 creation gets a -Wl,-soname
worked in, which made me wonder if it's somehow been missed from the C
command.




reply via email to

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