Re: fixing linkage against uninstalled libtool archives on macos?
On 11-Nov-08, at 6:16 AM, Andy Wingo wrote: Hi, I posted a message to bug-libtool that hasn't gotten a response: http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00012.html In short, "libtool --tag=CC --mode=link gcc ... /path/to/libfoo.la" does not do the right thing on Mac OS with libtool 2.2.6a. Can I get confirmation of this bug? Just to recap, the bug is that having "../../../gst/libgstreamer-0.10.la" on the link line expands into "-L../../../gst/.libs -lgstreamer-0.10" instead of "../../../gst/.libs/libgstreamer-0.10.dylib". I tested replacing the "-L -l" combination with the path to the dylib, and that seems to work. So it seems to be a bug in libtool. Sorry, I did not get back to you. Could you please send the output of ./libtool --config. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool problem with library dependencies on ppc64
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 "-Ldir>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//in
Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Hello, i just tried to run the "Hello World" example c++ project in Kdevelop as i got the output below. Can anyone support me please and tell me what i did wrong? If you need more information, please tell me. Thanks in advance. Jan ../libtool: line 832: X--tag=CXX: command not found ../libtool: line 865: libtool: ignoring unknown tag : command not found ../libtool: line 832: X--mode=compile: command not found ../libtool: line 999: *** Warning: inferring the mode of operation is deprecated.: command not found ../libtool: line 1000: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../libtool: line 1143: Xg++: command not found ../libtool: line 1143: X-DHAVE_CONFIG_H: command not found ../libtool: line 1143: X-I.: command not found ../libtool: line 1143: X-I/home/jan/test/src: No such file or directory ../libtool: line 1143: X-I..: command not found ../libtool: line 1143: X-O0: command not found ../libtool: line 1143: X-g3: command not found ../libtool: line 1143: X-MT: command not found ../libtool: line 1143: Xtest.lo: command not found ../libtool: line 1143: X-MD: command not found ../libtool: line 1143: X-MP: command not found ../libtool: line 1143: X-MF: command not found ../libtool: line 1143: X.deps/test.Tpo: No such file or directory ../libtool: line 1143: X-c: command not found ../libtool: line 1195: Xtest.lo: command not found ../libtool: line 1200: libtool: compile: cannot determine name of library object from `': command not found make: *** [test.lo] Error 1 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Hello Jan, * Jan Leimbach wrote on Tue, Nov 11, 2008 at 10:22:10PM CET: > > i just tried to run the "Hello World" example c++ project in Kdevelop > as i got the output below. > > Can anyone support me please and tell me what i did wrong? You are mixing an ltmain.sh file from Libtool 1.5.x with macro files (libtool.m4 and others) from Libtool 2.2.x, or vice versa. The macro files may have been copied into your package with 'libtoolize --install', or 'aclocal --install', or their contents copied into the aclocal.m4 file from aclocal. All of this may have been caused by autoreconf, or a bootstrap script. The solution is to point aclocal to the right macro files. By default, it looks in $prefix/share/aclocal, where $prefix is the prefix where Automake was installed. You can add search paths to aclocal for example by listing directories in the file $prefix/share/aclocal/dirlist. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Hallo Ralf, danke für Deine schnelle Antwort. Da ich recht neu in der Programmierung unter Linux bin, wird mich Deine Antwort sicher ein paar Tage beschäftigt halten =) Wünsche Dir einen schönen Abend... Grüße Jan On Tue, Nov 11, 2008 at 10:37 PM, Ralf Wildenhues <[EMAIL PROTECTED]>wrote: > Hello Jan, > > * Jan Leimbach wrote on Tue, Nov 11, 2008 at 10:22:10PM CET: > > > > i just tried to run the "Hello World" example c++ project in Kdevelop > > as i got the output below. > > > > Can anyone support me please and tell me what i did wrong? > > You are mixing an ltmain.sh file from Libtool 1.5.x with macro files > (libtool.m4 and others) from Libtool 2.2.x, or vice versa. > > The macro files may have been copied into your package with 'libtoolize > --install', or 'aclocal --install', or their contents copied into the > aclocal.m4 file from aclocal. All of this may have been caused by > autoreconf, or a bootstrap script. > > The solution is to point aclocal to the right macro files. By default, > it looks in $prefix/share/aclocal, where $prefix is the prefix where > Automake was installed. > > You can add search paths to aclocal for example by listing directories > in the file $prefix/share/aclocal/dirlist. > > Hope that helps. > > Cheers, > Ralf > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Hi Ralf, On Tue, Nov 11, 2008 at 1:37 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > The macro files may have been copied into your package with 'libtoolize > --install', or 'aclocal --install', or their contents copied into the > aclocal.m4 file from aclocal. All of this may have been caused by > autoreconf, or a bootstrap script. This is a bit off-topic, but what is the exact reason why autoreconf does not run libtoolize? It's obviously not ideal that using the autoreconf defaults will cause breakage. -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Hello Dan, * Dan Nicholson wrote on Tue, Nov 11, 2008 at 10:46:59PM CET: > On Tue, Nov 11, 2008 at 1:37 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > > The macro files may have been copied into your package with 'libtoolize > > --install', or 'aclocal --install', or their contents copied into the > > aclocal.m4 file from aclocal. All of this may have been caused by > > autoreconf, or a bootstrap script. > > This is a bit off-topic, but what is the exact reason why autoreconf > does not run libtoolize? But it does! Which autoreconf version are you using? Maybe it fails to detect that you're using Libtool? > It's obviously not ideal that using the > autoreconf defaults will cause breakage. Erm, they shouldn't by default. The typical problem is that Automake and Libtool have been installed in different prefixes. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
On Tue, Nov 11, 2008 at 1:49 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Dan, > > * Dan Nicholson wrote on Tue, Nov 11, 2008 at 10:46:59PM CET: >> On Tue, Nov 11, 2008 at 1:37 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > >> > The macro files may have been copied into your package with 'libtoolize >> > --install', or 'aclocal --install', or their contents copied into the >> > aclocal.m4 file from aclocal. All of this may have been caused by >> > autoreconf, or a bootstrap script. >> >> This is a bit off-topic, but what is the exact reason why autoreconf >> does not run libtoolize? > > But it does! Which autoreconf version are you using? > Maybe it fails to detect that you're using Libtool? I mean the `autoreconf' vs. `autoreconf -i' issue. Specifically, `autoreconf' will run aclocal, potentially updating the libtool macros, but then it will skip running libtoolize and you have the old ltmain.sh. Looking at autoconf git, this is still the case. Do you know why it does this? -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
fixing linkage against uninstalled libtool archives on macos?
Hi, I posted a message to bug-libtool that hasn't gotten a response: http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00012.html In short, "libtool --tag=CC --mode=link gcc ... /path/to/libfoo.la" does not do the right thing on Mac OS with libtool 2.2.6a. Can I get confirmation of this bug? Just to recap, the bug is that having "../../../gst/libgstreamer-0.10.la" on the link line expands into "-L../../../gst/.libs -lgstreamer-0.10" instead of "../../../gst/.libs/libgstreamer-0.10.dylib". I tested replacing the "-L -l" combination with the path to the dylib, and that seems to work. So it seems to be a bug in libtool. Andy ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
This is exactly the place, where using Gentoo pays off. You learn some very unsual things, while you do. The problem here is KDevelop. It's using autotools in a such hacky way, that the only sane way to fix it, is to manually set things up. It adds a dir, with a lot of old m4 macros, that autoreconf detects but libtoolize does not and, as such, never overwrites the old macro. Simply look at the stuff, that got created as configure.ac. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
* Rafał Mużyło wrote on Wed, Nov 12, 2008 at 03:10:36AM CET: > > The problem here is KDevelop. It's using autotools > in a such hacky way, that the only sane way to fix it, > is to manually set things up. > > It adds a dir, with a lot of old m4 macros, that autoreconf > detects but libtoolize does not and, as such, never overwrites the > old macro. Then maybe it is sufficient to add AC_CONFIG_MACRO_DIR([m4]) to configure.ac, and ACLOCAL_AMFLAGS = -I m4 to the toplevel Makefile.am. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Help with libtool 2.2.4 on kubuntu 8.10 [newbie]
Rafał Mużyło wrote: The problem here is KDevelop. It's using autotools in a such hacky way, that the only sane way to fix it, is to manually set things up. Is there a good reason not to ship the autotools with a script to build a template directory? (This probably belongs on the autoconf list, and in fact I brought it up briefly on that list a few weeks ago.) I tried using KDevelop briefly once but found that it was not very useful, primarily because the tree it created needed a lot of modification. It seems like it would be feasible to generate a useful, functional, modern, and reasonably flexible dir tree that would work 99% of the time. Is there a use case? It seems to me that it would be a great help for the novice. -- William Pursell ___ http://lists.gnu.org/mailman/listinfo/libtool
