Peter,
I installed the same distro on a 32-bit Intel machine today and got the same
problem. So my hunch that this was a 64bit-only problem was wrong. To restate
the question . . . When only a libbfd.a is available for linking (i.e., no
libbfd.so), should libtool be smart enough to figure out that it should look for
libz.a? As I mentioned below, when I experimented with passing in a binutils
install directory to oprofile's configure (resulting in
"-L<binutils-install-dir>lib" added to LDFLAGS), then libtool was able to figure
that it should the -lz to its link command. So the problem only happens when
the libraries in question are in their default install locations.
Thanks.
-Maynard
Maynard Johnson wrote:
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:
+++++++++++++++++++
[EMAIL PROTECTED]:~/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:
++++++++++++++++++++
[EMAIL PROTECTED]:~/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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
