GNU bug report logs - #16259
when cross-compiling with LT_INIT([win32-dll]) wrappers are installed instead of real programs

Previous Next

Package: libtool;

Reported by: Marcin Wojdyr <wojdyr <at> gmail.com>

Date: Thu, 26 Dec 2013 14:01:02 UTC

Severity: normal

To reply to this bug, email your comments to 16259 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Thu, 26 Dec 2013 14:01:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marcin Wojdyr <wojdyr <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Thu, 26 Dec 2013 14:01:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Marcin Wojdyr <wojdyr <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: when cross-compiling with LT_INIT([win32-dll]) wrappers are installed
 instead of real programs
Date: Thu, 26 Dec 2013 14:00:20 +0000
Hello,
1.5 years ago I reported this as a bug for automake.
Stefano Lattarini just replied that it
looks like a libtool bug rather than an Automake one.
The details are here:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11155

Marcin




Information forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Tue, 07 Jan 2014 14:09:02 GMT) Full text and rfc822 format available.

Message #8 received at 16259 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Marcin Wojdyr <wojdyr <at> gmail.com>, 16259 <at> debbugs.gnu.org
Subject: Re: bug#16259: when cross-compiling with LT_INIT([win32-dll]) wrappers
 are installed instead of real programs
Date: Tue, 07 Jan 2014 15:08:27 +0100
On 2013-12-26 15:00, Marcin Wojdyr wrote:
> Hello,
> 1.5 years ago I reported this as a bug for automake.
> Stefano Lattarini just replied that it
> looks like a libtool bug rather than an Automake one.
> The details are here:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11155

Hi Marcin!

I fail to reproduce. What is your $host and $build? Can you provide a
stripped down example?

Cheers,
Peter

$ uname -a
CYGWIN_NT-6.1-WOW64 PEDA-PC 1.7.25(0.270/5/3) 2013-08-31 20:39 i686 Cygwin
$ libtool --version
libtool (GNU libtool) 2.4
Written by Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat lttest.c
int foo(void)
{
  return 1;
}
$ cat ltexe.c
int foo(void);
int main(void)
{
  foo();
  return 0;
}
$ libtool --mode=compile gcc -o lttest.lo -c lttest.c
libtool: compile:  gcc -c lttest.c  -DDLL_EXPORT -DPIC -o .libs/lttest.o
libtool: compile:  gcc -c lttest.c -o lttest.o >/dev/null 2>&1
$ libtool --mode=compile gcc -o ltexe.lo -c ltexe.c
libtool: compile:  gcc -c ltexe.c  -DDLL_EXPORT -DPIC -o .libs/ltexe.o
libtool: compile:  gcc -c ltexe.c -o ltexe.o >/dev/null 2>&1
$ libtool --mode=link gcc -o liblttest.la lttest.lo -shared -no-undefined -rpath /home/peda/src/junk/lib
libtool: link: gcc -shared  .libs/lttest.o      -o .libs/cyglttest-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/liblttest.dll.a
libtool: link: ( cd ".libs" && rm -f "liblttest.la" && ln -s "../liblttest.la" "liblttest.la" )
$ libtool --mode=link gcc -o ltexe ltexe.lo ./liblttest.la
libtool: link: gcc -o .libs/ltexe .libs/ltexe.o  ./.libs/liblttest.dll.a  -L/home/peda/src/junk/lib
$ mkdir -p /home/peda/src/junk/lib
$ mkdir -p /home/peda/src/junk/bin
$ libtool --mode=install /usr/bin/install -c liblttest.la /home/peda/src/junk/lib
libtool: install: /usr/bin/install -c .libs/liblttest.dll.a /home/peda/src/junk/lib/liblttest.dll.a
libtool: install: base_file=`basename liblttest.la`
libtool: install:  dlpath=`/bin/sh 2>&1 -c '. .libs/'liblttest.la'i; echo cyglttest-0.dll'`
libtool: install:  dldir=/home/peda/src/junk/lib/`dirname ../bin/cyglttest-0.dll`
libtool: install:  test -d /home/peda/src/junk/lib/../bin || mkdir -p /home/peda/src/junk/lib/../bin
libtool: install:  /usr/bin/install -c .libs/cyglttest-0.dll /home/peda/src/junk/lib/../bin/cyglttest-0.dll
libtool: install:  chmod a+x /home/peda/src/junk/lib/../bin/cyglttest-0.dll
libtool: install:  if test -n '' && test -n 'strip --strip-unneeded'; then eval 'strip --strip-unneeded /home/peda/src/junk/lib/../bin/cyglttest-0.dll' || exit 0; fi
libtool: install: /usr/bin/install -c .libs/liblttest.lai /home/peda/src/junk/lib/liblttest.la
$ libtool --mode=install /usr/bin/install -c ltexe.exe /home/peda/src/junk/bin
libtool: install: /usr/bin/install -c .libs/ltexe.exe /home/peda/src/junk/bin/ltexe.exe
$ 


Cheers,
Peter





Information forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Tue, 07 Jan 2014 16:49:01 GMT) Full text and rfc822 format available.

Message #11 received at 16259 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Marcin Wojdyr <wojdyr <at> gmail.com>, 16259 <at> debbugs.gnu.org
Subject: Re: bug#16259: when cross-compiling with LT_INIT([win32-dll]) wrappers
 are installed instead of real programs
Date: Tue, 07 Jan 2014 17:48:33 +0100
On 2014-01-07 15:08, Peter Rosin wrote:
> On 2013-12-26 15:00, Marcin Wojdyr wrote:
>> Hello,
>> 1.5 years ago I reported this as a bug for automake.
>> Stefano Lattarini just replied that it
>> looks like a libtool bug rather than an Automake one.
>> The details are here:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11155
> 
> Hi Marcin!
> 
> I fail to reproduce. What is your $host and $build? Can you provide a
> stripped down example?

I just realized that I didn't cross-compile. Oops. But I still cannot
reproduce (when crossing from Cygwin to MinGW), so the question still
holds: What is your $host and $build?

Cheers,
Peter

$ cat lttest.c
int foo(void)
{
  return 1;
}
$ cat ltexe.c
int foo(void);
int main(void)
{
  foo();
  return 0;
}
$ cat configure.ac
AC_INIT([lttest], [0.1], [bugme <at> example.com])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE
AC_PROG_CC
LT_INIT([win32-dll])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
$ cat Makefile.am
AUTOMAKE_OPTIONS = subdir-objects foreign
ACLOCAL_AMFLAGS = -I m4
lib_LTLIBRARIES = liblttest.la
liblttest_la_SOURCES = lttest.c
liblttest_la_LDFLAGS = -shared -no-undefined
bin_PROGRAMS = ltexe
ltexe_SOURCES = ltexe.c
ltexe_LDADD = liblttest.la
$ mkdir -p build-aux m4
$ autoreconf -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:5: installing 'build-aux/compile'
configure.ac:6: installing 'build-aux/config.guess'
configure.ac:6: installing 'build-aux/config.sub'
configure.ac:4: installing 'build-aux/install-sh'
configure.ac:4: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
$ ./configure --host=i686-pc-mingw32 --prefix=/home/peda/src/junk
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
.
. *snip*
.
checking whether to build static libraries... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
$ ./libtool --version
libtool (GNU libtool) 2.4
Written by Gordon Matzigkeit <gord <at> gnu.ai.mit.edu>, 1996

Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make V=0
  CC       lttest.lo
  CCLD     liblttest.la
  CC       ltexe.o
  CCLD     ltexe.exe
$ make install
make[1]: Entering directory '/home/peda/src/junk'
 /usr/bin/mkdir -p '/home/peda/src/junk/lib'
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   liblttest.la '/home/peda/src/junk/lib'
libtool: install: /usr/bin/install -c .libs/liblttest.dll.a /home/peda/src/junk/lib/liblttest.dll.a
libtool: install: base_file=`basename liblttest.la`
libtool: install:  dlpath=`/bin/sh 2>&1 -c '. .libs/'liblttest.la'i; echo liblttest-0.dll'`
libtool: install:  dldir=/home/peda/src/junk/lib/`dirname ../bin/liblttest-0.dll`
libtool: install:  test -d /home/peda/src/junk/lib/../bin || mkdir -p /home/peda/src/junk/lib/../bin
libtool: install:  /usr/bin/install -c .libs/liblttest-0.dll /home/peda/src/junk/lib/../bin/liblttest-0.dll
libtool: install:  chmod a+x /home/peda/src/junk/lib/../bin/liblttest-0.dll
libtool: install:  if test -n '' && test -n 'i686-pc-mingw32-strip --strip-unneeded'; then eval 'i686-pc-mingw32-strip --strip-unneeded /home/peda/src/junk/lib/../bin/liblttest-0.dll' || exit 0; fi
libtool: install: /usr/bin/install -c .libs/liblttest.lai /home/peda/src/junk/lib/liblttest.la
 /usr/bin/mkdir -p '/home/peda/src/junk/bin'
  /bin/sh ./libtool   --mode=install /usr/bin/install -c ltexe.exe '/home/peda/src/junk/bin'
libtool: install: /usr/bin/install -c .libs/ltexe.exe /home/peda/src/junk/bin/ltexe.exe
make[1]: Nothing to be done for 'install-data-am'.
make[1]: Leaving directory '/home/peda/src/junk'





Information forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Tue, 14 Jan 2014 02:09:01 GMT) Full text and rfc822 format available.

Message #14 received at 16259 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Wojdyr <wojdyr <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 16259 <at> debbugs.gnu.org
Subject: Re: bug#16259: when cross-compiling with LT_INIT([win32-dll])
 wrappers are installed instead of real programs
Date: Tue, 14 Jan 2014 02:07:41 +0000
I've found the reason. In my case the problem was caused by env. variable:
GREP_OPTIONS='-I'
(libtool greps for magic string in binary file; I rarely search
strings in binaries so I have it switched off by default).

Thanks for looking into it

Marcin




Information forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Tue, 14 Jan 2014 02:37:01 GMT) Full text and rfc822 format available.

Message #17 received at 16259 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Marcin Wojdyr <wojdyr <at> gmail.com>
Cc: 16259 <at> debbugs.gnu.org, Peter Rosin <peda <at> lysator.liu.se>
Subject: Re: bug#16259: when cross-compiling with LT_INIT([win32-dll])
 wrappers are installed instead of real programs
Date: Tue, 14 Jan 2014 15:36:01 +1300
[Message part 1 (text/plain, inline)]
On Jan 14, 2014, at 3:07 PM, Marcin Wojdyr <wojdyr <at> gmail.com> wrote:
> I've found the reason. In my case the problem was caused by env. variable:
> GREP_OPTIONS='-I'
> (libtool greps for magic string in binary file; I rarely search
> strings in binaries so I have it switched off by default).

Perhaps in our shell-normalization preamble in ltmain and libtoolize we
ought to `export GREP_OPTIONS=` or similar to prevent future issues?  Or
maybe that's a whole can of worms...

Thoughts?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)
[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-libtool <at> gnu.org:
bug#16259; Package libtool. (Thu, 30 Jan 2014 14:46:01 GMT) Full text and rfc822 format available.

Message #20 received at 16259 <at> debbugs.gnu.org (full text, mbox):

From: Marcin Wojdyr <wojdyr <at> gmail.com>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: 16259 <16259 <at> debbugs.gnu.org>, Peter Rosin <peda <at> lysator.liu.se>
Subject: Re: bug#16259: when cross-compiling with LT_INIT([win32-dll])
 wrappers are installed instead of real programs
Date: Thu, 30 Jan 2014 14:44:55 +0000
> Perhaps in our shell-normalization preamble in ltmain and libtoolize we
> ought to `export GREP_OPTIONS=` or similar to prevent future issues?  Or
> maybe that's a whole can of worms...

I'd bet that clearing GREP_OPTIONS won't do any harm.
It seems to be the easiest way to fix this issue.
(just my two cents, to not let this issue be forgotten)

Marcin




This bug report was last modified 11 years and 137 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.