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
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 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
, [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
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://
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
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 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
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
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.
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
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
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
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 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
'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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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 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
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 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
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 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
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 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
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
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
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
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
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 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 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 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 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 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
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
54 matches
Mail list logo
