automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: crosscompiled .exe (Re: crosscompiling dll linux->mingw32)


From: Gary V . Vaughan
Subject: Re: crosscompiled .exe (Re: crosscompiling dll linux->mingw32)
Date: Sat, 28 Apr 2001 12:51:24 +0100

On Thursday 26 April 2001  7:21 pm, Guido Draheim wrote:
> Guido Draheim wrote:
> > from that I'd say libtool knows that CC has created a pfe.exe but
> > the automake-rules/vardefs expect a builddir/pfe.exe too. A copy
> > of builddir' pfe to pfe.exe does indeed work. Who's to blame,
> > libtool or automake?
>
> It is libtool's fault - even that the final link-line gets really
> called with a "-o pfe.exe" for program pfe, the libtool will create
> builddir/pfe and builddir/.libs/pfe.exe. Does the native-build
> libtool do sth. different here? I don't have a win32-environment
> here at the moment, but I think not (but how do people make
> dependent rules on these platforms?).

Nope - it has to behave that way even with a native Windows build due to 
limitations of the Windows kernel.

> /bin/sh ./libtool --mode=link i386-mingw32msvc-gcc  -D_export=__dllexport
> -Wall  -W,-E -W,--warn-common -o pfe.exe -export-dynamic main-stdc.o
> libpfe.la -lkernel32  -L.libs -lpfe
> generating import library for `libpfe-0-30-97.dll'
> i386-mingw32msvc-dlltool --as=i386-mingw32msvc-as --dllname
> libpfe-0-30-97.dll --def .libs/libpfe-0-30-97.dll-def --output-lib
> .libs/libimp-pfe-0-30-97.a
> i386-mingw32msvc-gcc -D_export=__dllexport -Wall -W,-E -W,--warn-common -o
> .libs/pfe.exe main-stdc.o -Wl,--export-dynamic -lkernel32
> -L/usr/src/cvs/pfe-30/Release/i386-mingw32msvc/.libs
> .libs/libimp-pfe-0-30-97.a -Wl,--rpath -Wl,/programs/pfe creating pfe.exe
>
> Any argument why that is how it is?

See my last mail.

I can think of two ways around this.  Either Automake would have to be 
lenient about the existence of .exe extensions when it asks libtool to 
install a binary, or libtool would need to build a wrapper program on Windows 
which would call the wrapper script to set the environment up to load the 
correct DLLs and then call the actual program in the .libs subdirectory.

The first option seems to be the easiest, and I believe Edward's patch 
addresses this problem.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]