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 prove
Quoting Ralf Wildenhues <[EMAIL PROTECTED]>:
Hello Benoit,
Hi, thanks for your quick reply.
* Benoit Sigoure wrote on Tue, Nov 14, 2006 at 05:35:03PM CET:
My final questions are: is this necessary on Windows? Can't you keep the
relative path?
Not easily.
That's weir
Quoting Christopher Hulbert <[EMAIL PROTECTED]>:
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
Hello folks.
[SNIP]
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
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
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 t
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 exac
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 t
Quoting Howard Chu <[EMAIL PROTECTED]>:
Benoit Sigoure wrote:
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
I sent you an email a couple of days ago because I had a problem
with wgcc, did you receive it?)
Cheers,
Cheers, Markus
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Benoit Sigoure
Sent: Tuesday, November 28, 2006 2:14 PM
To: libtool@gnu.org
Subject: Re: Su
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
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
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 distr
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 && ma
Quoting Ralf Wildenhues <[EMAIL PROTECTED]>:
* Benoit Sigoure wrote on Tue, Dec 19, 2006 at 10:13:20AM CET:
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 binarie
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
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 abo
3.5-eldk/arm-linux/arm-linux/lib/libstdc++.la'
and then the build 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.
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 -stat
more details.
make: *** [tests/f77demo/Makefile] Error 1
I've never seen this failure before and I never had a Fortran compiler installed
although I already bootstrapped and used CVS libtool. Is it me or... is this
intended somehow?
The various config.logs are available at:
http://www.tsu
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 ... con
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 i
at it appears to work transparantly 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
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 libt
e on you
for suggesting 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
ript 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
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
PGP.sig
Description: This is a
and LDFLAGS 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
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! That
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&#x
release schedule."
which seems to confirm what's 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
tools?
AM_DISABLE_STATIC
Ghee, I didn't know we could 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 Laborat
ays empty.
AM_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
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
On Sep 30, 2007, at 5:59 PM, Ralf Wildenhues wrote:
Hello Benoit, all,
* Benoit SIGOURE wrote on Sun, Sep 30, 2007 at 04:08:46PM CEST:
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
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
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
y forget it works only on the
$host. That's why 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
mmon pitfall
and I 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
files are still referencing pango from 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
Descrip
't it? Or maybe analyzing the output 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 Developme
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
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 bin
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 to
stsuite.at:243)
Just in case, the sources of this package can be found at http://
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
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 me
paths (e.g. -DPKGDATADIR="/path/to/prefix").
So 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.
to test 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
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
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 d
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 t
le keep
running 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://
, [Libtool required by $1])])])])])
...
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 t
On Dec 4, 2007, at 9:55 PM, Ralf Wildenhues wrote:
Hello,
* Brian Dessent wrote on Tue, Dec 04, 2007 at 07:20:40PM CET:
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 a
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 happe
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 fragil
54 matches
Mail list logo
