libtool --mode=execute with -L parameter, a v2.2 regression

Hi! Here /usr/bin/libtool is debian's 1.5.26 and /usr/local/bin/libtool is hand-compiled v2.2: [EMAIL PROTECTED]:~$ /usr/bin/libtool --mode=execute echo -L . foo -L . foo [EMAIL PROTECTED]:~$ /usr/local/bin/libtool --mode=execute echo -L . foo -L / / [EMAIL PROTECTED]:~$ Is this a bug? If it

Re: libtool --mode=execute with -L parameter, a v2.2 regression

Peter Rosin [EMAIL PROTECTED] writes: Hej Simon, On Mon, Mar 10, 2008 at 02:09:50PM +0100, Simon Josefsson wrote: Hi! Here /usr/bin/libtool is debian's 1.5.26 and /usr/local/bin/libtool is hand-compiled v2.2: [EMAIL PROTECTED]:~$ /usr/bin/libtool --mode=execute echo -L . foo -L . foo

Re: Libtool fails to build working binary when -no-install is used

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

Libtool fails to build working binary when -no-install is used

Hi! I'm tracking down what I believe is a libtool bug, or possibly a libtool documentation issue. In libssh2, a shared library, we have a hello world kind of self test that just invokes the library init/done function. The self test is linked to libssh2. The Makefile.am to build it is:

Wrapper executable using wrong path for cross-compiled binaries?

Hi! I'm trying to understand why 'make check' fails for GnuTLS with automake 1.10 as follows: ... fixme:msvcrt:_spawnve only trying .exe when no extension given Wine failed with return code 127 FAIL: ... Automake 1.10 changed its behavior compared to 1.9.6 (which works fine) so that 'make

Re: strings.h in argz.c?

? ... * libltdl/argz.c: Do not include strings.h nor memory.h, include string.h unconditionally. Patch by Simon Josefsson [EMAIL PROTECTED]. I like this part. :-) Thanks, Simon ___ Bug-libtool mailing list Bug-libtool@gnu.org http

Re: strings.h in argz.c?

the discussion below. Would you consider installing the patch below in libtool? Thanks, Simon Simon Josefsson [EMAIL PROTECTED] writes: Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: #if defined(HAVE_STRING_H) # include string.h #elif defined(HAVE_STRINGS_H) # include strings.h

Re: strings.h in argz.c?

Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: #if defined(HAVE_STRING_H) # include string.h #elif defined(HAVE_STRINGS_H) # include strings.h #endif #if defined(HAVE_MEMORY_H) # include memory.h #endif Is strings.h needed on any modern platform? No. 1) string.h

Re: OBJDUMP incorrect on cross-compiles to mingw32

Ralf Wildenhues [EMAIL PROTECTED] writes: * Simon Josefsson wrote on Thu, Jun 22, 2006 at 12:28:04PM CEST: Ralf Wildenhues [EMAIL PROTECTED] writes: * Simon Josefsson wrote on Wed, Jun 21, 2006 at 03:48:08PM CEST: # Used on cygwin: object dumper. OBJDUMP=objdump This is incorrect

Re: OBJDUMP incorrect on cross-compiles to mingw32

Ralf Wildenhues [EMAIL PROTECTED] writes: Hi Simon, Thanks for the report. However, I do not think this is a bug: * Simon Josefsson wrote on Wed, Jun 21, 2006 at 03:48:08PM CEST: Hi! I'm using Debian's mingw32 packages to build native win32 DLL/EXE's with libtool. I'm configuring

OBJDUMP incorrect on cross-compiles to mingw32

Hi! I'm using Debian's mingw32 packages to build native win32 DLL/EXE's with libtool. I'm configuring with: --host=i586-mingw32msvc --build=i686-pc-linux-gnu However, when linking a shared library, I get this error: *** Warning: linker path does not have real file for library -lws2_32. *** I