Absolute paths generated by libtool.

Hello folks. I'm developing Qt-based applications. The build system is controlled by the autotools rather than by Qmake. I'm porting our projects on Windows. We're using an automated build system (buildbot.sf.net) to build every commit on Linux/OSX/Windows. Automating the process on Windows

Re: Absolute paths generated by libtool.

Quoting Eric Blake [EMAIL PROTECTED]: According to Benoit Sigoure on 11/14/2006 9:35 AM: Qt distributes Windows binaries for mingw only so I ended up installing mingw. This entails that everything is built by the mingw-gcc toolchain rather than by the cygwin-gcc. Anyway, I *guess

Re: Absolute paths generated by libtool.

Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:27:13AM CET: Quoting Eric Blake [EMAIL PROTECTED]: According to Benoit Sigoure on 11/14/2006 9:35 AM: Have you tried writing the makefile with forward slashes? Windows tends to do all right with them

Re: Absolute paths generated by libtool.

Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:55:38AM CET: Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Wed, Nov 15, 2006 at 07:27:13AM CET: If simply passing -mno-cygwin to gcc is exactly like using mingw gcc, No, e.g

Support for VC++ toolchain (was Re: Absolute paths generated by libtool.)

Quoting Benoit Sigoure [EMAIL PROTECTED]: [SNIP, see http://lists.gnu.org/archive/html/libtool/2006-11/msg00018.html] Hello folks, I think I finally succeeded: I can now build any UNIX program as long as its code is portable on Windows with both mingw-gcc toolchain and MS VC++. I thought

RE: Support for VC++ toolchain (was Re: Absolute paths generatedby libtool.)

] On Behalf Of Benoit Sigoure Sent: Tuesday, November 28, 2006 2:14 PM To: libtool@gnu.org Subject: Re: Support for VC++ toolchain (was Re: Absolute paths generatedby libtool.) Quoting Howard Chu [EMAIL PROTECTED]: Benoit Sigoure wrote: Quoting Benoit Sigoure [EMAIL PROTECTED]: [SNIP, see http

Relocatable .la files?

Hello, what's the right why of distributing binary packages that are relocatable? $ ../configure -C --prefix=`pwd`/_inst make all install [...configuring liburbi-cpp...] === configuring in jpeg-6b (/Users/tsuna/svn/liburbi-cpp/_build/jpeg-6b) configure: running /bin/sh ../../jpeg-6b/configure

Re: Relocatable .la files?

Quoting Ralf Wildenhues [EMAIL PROTECTED]: Hello Benoit, * Benoit Sigoure wrote on Mon, Dec 18, 2006 at 02:35:43PM CET: what's the right why of distributing binary packages that are relocatable? With shared libraries: in general, that is not possible portably. Run paths encoded

Re: Relocatable .la files?

Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Mon, Dec 18, 2006 at 07:32:13PM CET: Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Mon, Dec 18, 2006 at 02:35:43PM CET: what's the right why of distributing binary packages that are relocatable

Linking against static instead of shared libs

Hello folks. I'm trying to distribute a project that depends on several libraries and in order to make it easier to end users, I'd like to provide them with self-contained binaries linked against static libs (so that they don't have to install these libs). I ran ./configure --disable-shared

Re: Shouldn't the definition of maintainer-clean be changed?

Quoting Ralf Wildenhues [EMAIL PROTECTED]: Hello everyone, First, please be aware of another thread discussing a similar topic: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/9692/focus=9695 * Benoit Sigoure wrote on Mon, Mar 19, 2007 at 12:39:32PM CET: In a first time, I'm trying

Re: Shouldn't the definition of maintainer-clean be changed?

Quoting Bruce Korb [EMAIL PROTECTED]: Not knowing the guts of this, my only complaint has to do with the help text for ``--clean'' and the lack of consistency WRT ``-c'' being an acceptable alias for it. Yeah you're right, the message should be consistent in the different programs. What

libstdc++.la listed in dependency_libs of a static C++ library?

fails. Any idea? Is it libtool? Me? ELDK? libkernel.la: http://www.tsunanet.net/~tsuna/eldk-libtool-problem/libkernel.la libtool --config: http://www.tsunanet.net/~tsuna/eldk-libtool-problem/libtool.config Thanks. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Re: libstdc++.la listed in dependency_libs of a static C++ library?

Quoting Ralf Wildenhues [EMAIL PROTECTED]: Hello Benoit, * Benoit Sigoure wrote on Tue, Apr 03, 2007 at 04:19:25PM CEST: [Compilation of the libkernel] This link line: /bin/sh ../libtool --tag=CXX --mode=link arm-linux-g++ [losts of -Warning flags] -pthread -g -O2 -pipe -static -o

Bootstrapping CVS HEAD fails without a Fortran compiler.

://www.tsunanet.net/~tsuna/libtool_cvs070404_bootstrap/ BTW, I can simply run ./configure make check but distcheck still fails in the same way. It also fails if I do a VPATH build. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Re: Bootstrapping CVS HEAD fails without a Fortran compiler.

Quoting Ralf Wildenhues [EMAIL PROTECTED]: Hello Benoit, * Benoit Sigoure wrote on Wed, Apr 04, 2007 at 12:42:52AM CEST: [...] checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking how to get verbose linking output from ... configure

Re: libstdc++.la listed in dependency_libs of a static C++ library?

Quoting Benoit Sigoure [EMAIL PROTECTED]: Quoting Ralf Wildenhues [EMAIL PROTECTED]: That's not the only (or important, FWIW) issue here, though. The installed libstdc++.la file is broken. Reason for that include bugs/limitations in Libtool, bugs in GCC, and possibly in the script that has

On Windows, $old_archive_cmds uses `lib' to create static archives.

just like GCC (this thread explains what I did: http://lists.gnu.org/archive/html/libtool/2006-11/msg00046.html). Thanks. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: On Windows, $old_archive_cmds uses `lib' to create static archives.

Quoting Ralf Wildenhues [EMAIL PROTECTED]: * Benoit Sigoure wrote on Sun, Apr 22, 2007 at 07:42:24PM CEST: On Windows, when compiling with Visual C++, libtool seems to figure out automagically that it has to create static archives with the `lib' command. [...] I wonder how libtool figured

Re: normal ltdl linking suggestions?

such an approach. Go stand in a corner. I'm not sure I understand why you're saying this. Did you mean s/no need/need/? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: Profiling a library built with libtool

useful to libtool. Now the answer to your question is to ask libtool to run gprof (or gdb) for you: ./libtool --mode=execute gprof ./foo Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: Profiling a library built with libtool

are used when linking with libtool and libtool will let -pg pass through. It worked for me with a non-static build so this should not be a requirement (at least on some platforms -- I've tested on OSX). -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description

Re: Profiling a library built with libtool

On Jul 13, 2007, at 5:36 PM, Joseph Wakeling wrote: Benoit SIGOURE wrote: The .la file is a piece of shell script that contains information useful to libtool. Now the answer to your question is to ask libtool to run gprof (or gdb) for you: ./libtool --mode=execute gprof ./foo Ah

Re: Profiling a library built with libtool

On Jul 13, 2007, at 6:57 PM, Joseph Wakeling wrote: Benoit SIGOURE wrote: Hmm you are right, I didn't notice during my test that I also had zeros. Build a static version of your project and it'll work. ./configure --disable-shared make clean all CFLAGS='-pg -all-static' Ahh, brilliant

Re: Using libtool for linking

been said in the above reply. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: libltdl convenience missing make targets

call this macro with AM_*. AM_PROG_LIBTOOL For this one however, the manual says this name is deprecated, you should use AC_PROG_LIBTOOL instead. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: AC_PROG_LIBTOOL sets CFLAGS

is reserved for developers. It's not a problem if the user overrides the default value of CFLAGS since CFLAGS is reserved for the user. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Migration to Git?

Hello, several GNU projects (including autoconf) have moved to Git, is there any similar plan for automake and libtool? Is anyone in charge of this? Help needed? Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally

Re: Migration to Git?

On Oct 1, 2007, at 8:59 AM, NightStrike wrote: On 9/30/07, Benoit SIGOURE [EMAIL PROTECTED] wrote: Hello, several GNU projects (including autoconf) have moved to Git, is there Just curious... why git over svn? Instead of going in lengthy threads, I think you should simply read

Re: Migration to Git?

On Oct 1, 2007, at 2:54 AM, Bob Friesenhahn wrote: On Sun, 30 Sep 2007, Benoit SIGOURE wrote: Hello, several GNU projects (including autoconf) have moved to Git, is there any similar plan for automake and libtool? Is anyone in charge of this? Help needed? I think that the current

Re: Libtool is unfatting my universal binaries

they often build the the Intel and PPC versions separately (and thus test them separately) and then `lipo' them together. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: Libtool is unfatting my universal binaries

simply warned you it's quite a common one. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Moving .la files

under /usr/lib, hence the problem (that's just an educated guess, there can be other reasons, of course). I hope I managed to make this clear :P Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Libtool doesn't set -rpath automatically when needed?

of `ldd'? But it surely isn't something standard, for instance on OSX it's `otool -L' and it requires the package odcctools...). Any suggestion would be appreciated. Thanks. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed

Re: Libtool doesn't set -rpath automatically when needed?

On Nov 2, 2007, at 11:00 PM, Roumen Petrov wrote: Usually /etc/ld.so.conf contain /usr/local/lib. Dunno why this path is not set on you host. Benoit SIGOURE wrote: Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost

Re: Libtool doesn't set -rpath automatically when needed?

On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote: Hello Benoit, * Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET: On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under / usr/ local/lib (pre-built binaries

Re: Libtool doesn't set -rpath automatically when needed?

On Nov 3, 2007, at 12:57 PM, Ralf Wildenhues wrote: * Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET: OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that does this in my own macro so I can portably figure out the -rpath/-R/ etc. options needed and then add them

Libtool uses obsolete Autoconf macros

:// repo.or.cz/w/boost.m4.git Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool

Saving the -R flags in the .la file?

Hello list, I'm wondering why libtool doesn't save the -R flags in the .la file, along with the -L and -l? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: Moving Installed Libraries built with libtool

yeah it's a bit of an issue, I guess people often come up with wrapper scripts that set the right LD_LIBRARY_PATH and then exec the binary but that's not always a viable solution. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Favoring static linking at configure time

whether a static version of a given library is available and ensure that it's used during the build? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Favoring static linking at configure time

On Dec 4, 2007, at 6:49 PM, Brian Dessent wrote: Benoit Sigoure wrote: shared libraries). The first case that comes to my mind is Windows where there used to be import libraries named in libfoo.a (whereas they are now named libfoo.dll.a or whatever). But maybe this was a long time ago so

Re: Favoring static linking at configure time

On Dec 4, 2007, at 7:20 PM, Brian Dessent wrote: Benoit Sigoure wrote: Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic Hmm I didn't know this. How portable is it? I guess a gccism, but is it even portable across versions/ports of GCC? It doesn't really have anything to do with gcc

Re: Favoring static linking at configure time

On Dec 4, 2007, at 7:24 PM, Peter O'Gorman wrote: Benoit Sigoure wrote: Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic -Bstatic and -Bdynamic are not portable. The quoting is wrong, I didn't say this :) Anyways, are you aware of another more general/portable solution to detect

Detecting that AC_PROG_LIBTOOL has been invoked

in troubles because they didn't use Libtool, so I'd like to trigger an error, somehow, to tell them that they did something wrong. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory ___ http://lists.gnu.org/mailman/listinfo

Re: Detecting that AC_PROG_LIBTOOL has been invoked

])])])])]) ... m4_provided([MY_MACRO_NAME]) I didn't count the number of closing brackets. What is the m4_provide_if? I didn't find it in the manual of autoconf and m4. Anyways, does this guarantee me that the user did INVOKE the give macros, not merely that they exist? -- Benoit Sigoure

Re: Favoring static linking at configure time

On Dec 16, 2007, at 7:56 PM, Peter Rosin wrote: On Sun, Dec 16, 2007 at 04:23:41PM +0100, Benoit Sigoure wrote: OK So finally I solved the whole thing by adding /abs/path/to/libfoo. $libext (instead of -lfoo) in $LIBS ($libext is computed by libtool, most of the time it's .a but it happens

Re: Favoring static linking at configure time

On Dec 16, 2007, at 4:23 PM, Benoit Sigoure wrote: OK So finally I solved the whole thing by adding /abs/path/to/ libfoo.$libext (instead of -lfoo) in $LIBS ($libext is computed by libtool, most of the time it's .a but it happens to be .lib at least for MSVC). This is probably fragile

Re: New substitution: top_build_prefix

Output Variables): Document it. * NEWS: Update. Report by Bob Friesenhahn. BTW, this was meant as OK to apply?. Yeah, that's fine by me. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: New substitution: top_build_prefix

. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool

distchecking without FC?

Hello, is there any reason why I can checkout, configure and make all check libtool HEAD but not distcheck it? Configure would complain (only during distcheck) that I don't have a working Fortran compiler. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Re: distchecking without FC?

Quoting Noah Misch [EMAIL PROTECTED]: On Thu, Jun 14, 2007 at 01:47:12PM +0200, Benoit Sigoure wrote: is there any reason why I can checkout, configure and make all check libtool HEAD but not distcheck it? Configure would complain (only during distcheck) that I don't have a working Fortran

Re: distchecking without FC?

could confirm that it works for him as well. Yes it Works For Me (c). Thank you very much guys. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory This message was sent using IMP, the Internet Messaging Program.