Luke Dunstan wrote:
>
>> From: Mo DeJong <mdejong@...>
>> To: mingw-msys@...
>> Subject: [Mingw-msys] Problem execing as executable from inside
>> dlltool.exe
>> Date: Thu, 06 Feb 2003 00:50:36 -0800
>>
>> Hi all
>>
>> Here is a rather strange problem that I ran into when attempting to build
>> libiconv under Msys (1.0.8) + Mingw (2.0).
>>
>> % make
>> ...
>> dlltool --as=as --dllname libcharset-1.dll --exclude-symbols
>> DllMain@...
>> --def .libs/libcharset-1.dll-def --base-file
>> .libs/libcharset-1.dll-base --output-exp .libs/libcharset-1.dll-exp
>> D:\MINGW\MSYS\mingw\bin\dlltool.exe: installation problem, cannot exec
>> `as'
>>
>>
>> You can try this out for yourself by downloading:
>>
>> ftp://mirrors.kernel.org/gnu/libiconv/libiconv-1.8.tar.gz
>>
>> And then building with --enable-shared so that libtool tries to build
>> a dll.
>>
>> The really strange thing is that this does not seem like a problem
>> with the PATH. I passed a fully qualified path name as the argument
>> to the --as option and it still claimed that it could not exec the
>> program.
>> One can "fix" this problem by removing the "--as=as" argument in each
>> location that it appears in the generated libtool script, but that is
>> a bit
>> of a hack.
>>
>> Could this have something to do with execing a 16 bit application from
>> inside a 32 bit one? I have no idea, I am just grasping at straws here.
>>
>> cheers
>> Mo DeJong
>
>
> Are you using Windows 9x/ME? If so then it would be this MSYS bug:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=646577&group_id=2435&atid=102435
>
>
> It's not fixed yet and the only workaround is the hack you did.
>
Although this is still broken, what Mo really needs to do is replace the
libtool.m4, ltmain.sh and any other libtool parts in the source with the
CVS versions of libtool and execute the aclocal, automake, autoconf,
autoheader, etc. The msysDTK-1.0.1.exe has the needed tools, including
an almost uptodate CVS version of libtool.
Earnie.
|
