libtool
[Top][All Lists]
Advanced

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

libtool problem with library dependencies on ppc64


From: Maynard Johnson
Subject: libtool problem with library dependencies on ppc64
Date: Wed, 29 Oct 2008 17:33:29 -0500
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

Hello, Peter,
I've run into another problem with building the oprofile project that seems like it might be an issue with libtool. Recent versions of binutils have made libbfd dependent on libz (biniutilis 2.18.91 for sure . . . maybe earlier). I added a configure check in oprofile to handle this. Initially, the only way I had to verify this change was by installing the newer version of binutils in /usr/local and configuring oprofile with --with-binutils to point to that. The new check for libz seemed to work fine in that situation. Recently, I've been working on a POWER6 system that has a new distro beta installed on it, and it came with the updated binutils. (By the way, this new distro defaults to 64-bit, and I currently have only the 64-bit development environment installed. I think this fact is key.) Unfortunately, the oprofile project does not build on this platform. With both binutils and binutils-devel rpms installed, what I see in /usr/lib64 is the following:
        libbfd-2.18.91.20080917.so
        libbfd.a

So our oprofile build needs to statically link with libbfd.a. When I try to build oprofile, the failure I get is as follows:

+++++++++++++++++++
address@hidden:~/temp/oprof-cvs-2008.10.15/opjitconv> make
/bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x128): undefined reference to `inflateInit_' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x150): undefined reference to `inflateReset' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x184): undefined reference to `inflate' /usr/lib64/gcc/powerpc64-suse-linux/4.3/../../../../lib64/libbfd.a(compress.o):(.text+0x1b4): undefined reference to `inflateEnd'
collect2: ld returned 1 exit status
make: *** [opjitconv] Error 1
++++++++++++++++++++

The undefined references are all from libz (as libbfd now has a dependency on it). If I simply manually add the '-lz' to the end of the libtool command, then libtool generates the following link command, and it runs successfully: libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl -lz


As an experiment, I removed the installed BFD libraries and built a binutils 2.18 (cvs snapshot from September) and installed it in my home directory. I then tried an oprofile build from scratch, specifying the --with-binutils option. The build ran successfully. here is the libtool command (and the link command it generates) that corresponds to the above:

++++++++++++++++++++
address@hidden:~/oprof-cvs-2008.10.15/opjitconv> make
/bin/sh ../libtool --tag=CC --mode=link gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -I/home/mpj/binutils-install-2-18//include -L/home/mpj/binutils-install-2-18//lib64 -Xlinker -R -Xlinker /home/mpj/binutils-install-2-18//lib64 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o ../libutil/libutil.a -lbfd -liberty -ldl libtool: link: warning: library `/home/mpj/binutils-install-2-18//lib64/libbfd.la' was moved. libtool: link: warning: library `/home/mpj/binutils-install-2-18//lib64/libbfd.la' was moved. libtool: link: gcc -W -Wall -fno-common -Wdeclaration-after-statement -Werror -g -O2 -I/home/mpj/binutils-install-2-18//include -Wl,-R -Wl,/home/mpj/binutils-install-2-18//lib64 -o opjitconv opjitconv.o conversion.o parse_dump.o jitsymbol.o create_bfd.o debug_line.o -L/home/mpj/binutils-install-2-18//lib64 ../libutil/libutil.a /home/mpj/binutils-install-2-18//lib64/libbfd.a -lz -liberty -ldl
+++++++++++++++++++

Notice that libtool added the -lz to the link command in this case. So, it seems to me that passing in a -L to indicate an alternative binutils dir provides libtool with enough info to figure out it needed to add the -lz. Is it a bug that it can't figure this out when it should link with the default /usr/lib64/libbfd.a?

Sorry for the length of this message.  Thanks in advance for any help.

Regards,
-Maynard Johnson






reply via email to

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