[Top][All Lists]
[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