[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: |
JONES, BILL |
Subject: |
bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update |
Date: |
Mon, 30 Jan 2012 12:43:03 +0000 |
Bob,
For you question about the /usr/local/lib/libiconv.la, I have built several
other tools from GNU that detect the new
/appl/gfpip/local/lib/sparcv9/libiconv.la properly over the /usr/local/lib
version.
NOTE: I changed all the test "configure" files to add _64 to the Solaras
instances of LD_LIBRARY_PATH and ALL TESTS PASSED....
NOTE: The section of code in f77demo/configure that defined shlibpath_var is
duplicated, and I changed both instances. Same goes for tagdemo/configure.
libtool-2.4.2/configure.
HOWEVER, once the first set of tests passed another section I have never seen
before started...and it has failures also...I had to change all instances of
configure in the directory tree, but still not all the tests passed...I sent
the results of testsuite.log from the server with the bug# in the subject.
In test/cdemo/configure I see this code...so there IS a mechanism to detect
which bit size being used. Could this be leveraged in the LD_LIBRARY_PATH
section?
*-*solaris*)
# Find out which ABI we are using.
echo 'int i;' > conftest.$ac_ext
if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
(eval $ac_compile) 2>&5
ac_status=$?
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; then
case `/usr/bin/file conftest.o` in
*64-bit*)
case $lt_cv_prog_gnu_ld in
yes*)
case $host in
i?86-*-solaris*)
LD="${LD-ld} -m elf_x86_64"
;;
sparc*-*-solaris*)
LD="${LD-ld} -m elf64_sparc"
;;
esac
# GNU ld 2.21 introduced _sol2 emulations. Use them if available.
if ${LD-ld} -V | grep _sol2 >/dev/null 2>&1; then
LD="${LD-ld}_sol2"
fi
;;
*)
if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
LD="${LD-ld} -64"
fi
;;
esac
;;
esac
fi
rm -rf conftest*
;;
esac
Bill
________________________________________
From: JONES, BILL
Sent: Monday, January 30, 2012 12:37 AM
To: Bob Friesenhahn
Cc: address@hidden; address@hidden
Subject: RE: bug#10643: BUG REPORT libtool-2.4.2 Solaris 10 64bit - Update
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 address@hidden
Sent: Sunday, January 29, 2012 9:31 PM
To: JONES, BILL
Cc: address@hidden; address@hidden
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
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
bug#10643: UPDATE: [GNU Libtool 2.4.2] testsuite: 15 16 71 72 73 91 92 93 95 96 97 98 99 100 105 106 108 110 111 112 113 120 failed, gfpmtipb GFP IP App ID, 2012/01/30