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
I forgot to mention that the libtool version being used in my situation is 2.2.6. Thanks. -Maynard > 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
