On 7-Nov-08, at 12:47 PM, Maynard Johnson wrote:
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.
Sorry I did not get back to you.
Unless there is a .la file for the .a archive, libtool will have no
idea what libraries the .a archive requires. Since there does not seem
to be a libfd.la, you will have to add -lz.
Peter
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
--
Peter O'Gorman
http://pogma.com
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool