Ralf Wildenhues wrote:
* Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST:
They are both C++ libraries yes. I do not tell either of them to link
with libstdc++ explicitly. The linking lines for the libs are below.
Libtool gets the libstdc++ part in, for g++.
There is no mention
Hello list,
I'm posting this message here but I'm not sure whether this is really related to
libtool or to the way GCC was compiled. I am using a cross compiler for
arm-linux distributed by ELDK (Embedded Linux Development Kit --
http://www.denx.de/wiki/DULG/ELDK). With this compiler, I first
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other hand, MINGW will support the code so it may not be a big deal.
Note: The relevant hunks of
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 libkernel.la -rpath
Hello Christopher,
* Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST:
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other
Hi Simon,
* Simon Josefsson wrote on Sun, Apr 01, 2007 at 11:17:20AM CEST:
Ralf Wildenhues [EMAIL PROTECTED] writes:
I think you should be able to work around it by adding
-R ../src
to the link flags for `simple' (untested, please try it! self: also put
in testsuite), that should
On 4/3/07, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Christopher,
* Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST:
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will
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
Hello
I have just made a fresh checkout of CVS head and I failed to bootstrap it:
$ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/libtool co .
[...]
$ cd libtool ./bootstrap ./configure make distcheck
[...]
WARNING: You might want to regenerate `commit' and `libltdl/config/mailnotify'
On 4 apr 2007, at 00.21, Peter O'Gorman wrote:
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
On Apr 3, 2007, at 5:51 PM, Simon Josefsson wrote:
On 4 apr 2007, at 00.21, Peter O'Gorman wrote:
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode
library
paths (other than
On Apr 3, 2007, at 4:44 PM, Ralf Wildenhues wrote:
Hi Peter, all,
* quoting myself:
* Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:
/bin/sh ../libtool --tag=CC --mode=link gcc -DLIBSSH2_DARWIN -I/
usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/
lib
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
backport? It fixes the stresstest failure exposed by my last patch.
After some experiments and a lot of
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
backport? It fixes the stresstest failure exposed by
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other hand, MINGW will support the code so it may not be a big deal.
Note: The relevant hunks of
Hello Christopher,
* Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST:
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other
Hi Simon,
* Simon Josefsson wrote on Sun, Apr 01, 2007 at 11:17:20AM CEST:
Ralf Wildenhues [EMAIL PROTECTED] writes:
I think you should be able to work around it by adding
-R ../src
to the link flags for `simple' (untested, please try it! self: also put
in testsuite), that should
MAKE=make.itx with the new 2.61/1.10
built libtool as of 20070403 12:00 +0200 (note libobjs useability):
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... libltdl/config/install-sh -c -d
checking
On 4/3/07, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Christopher,
* Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST:
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will
Hello Martin,
* Martin Koeppe wrote on Tue, Apr 03, 2007 at 09:10:48PM CEST:
However, I now found out why 'make' is called. Interix make has some
standard build rules in /usr/share/mk/sys.mk, which also define
MAKE=make. When calling make.itx -r, then MAKE and also MAKEFLAGS
are set
Hi Peter, all,
* quoting myself:
* Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:
/bin/sh ../libtool --tag=CC --mode=link gcc -DLIBSSH2_DARWIN -I/
usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/lib
-lz -o simple simple.o ../src/libssh2.la
mkdir
On Apr 3, 2007, at 4:44 PM, Ralf Wildenhues wrote:
Hi Peter, all,
* quoting myself:
* Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:
/bin/sh ../libtool --tag=CC --mode=link gcc -DLIBSSH2_DARWIN -I/
usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/
lib
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
backport? It fixes the stresstest failure exposed by my last patch.
After some experiments and a lot of
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
backport? It fixes the stresstest failure exposed by
On 4 apr 2007, at 00.21, Peter O'Gorman wrote:
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)? OK to apply and
On Apr 3, 2007, at 5:51 PM, Simon Josefsson wrote:
On 4 apr 2007, at 00.21, Peter O'Gorman wrote:
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode
library
paths (other than
26 matches
Mail list logo
