From: SourceForge.net <no...@so...> - 2004-02-14 07:41:38
|
Bugs item #646577, was opened at 2002-12-01 11:36 Message generated for change (Comment added) made by pgarceau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=646577&group_id=2435 Category: binutils Group: component package Status: Open Resolution: None Priority: 9 Submitted By: Kevin Kofler (kevinkofler) Assigned to: Nobody/Anonymous (nobody) Summary: dlltool --as broken on Me: can't exec as Initial Comment: The --as option of dlltool.exe in the binutils-2.13.90- 20021006-2 release does not seem to work correctly on Windows Me. I get the following error: e:\mingw32\bin\dlltool.exe: installation problem, cannot exec `E:/MINGW32/BIN/AS.EXE' and I get an error of that form no matter what I pass as --as, even when I just pass "--as=as" or "-- as=as.exe". This is a problem because libtool always passes an -- as switch to dlltool. I can just change the parameter by setting $AS, but I cannot remove the --as switch without hand-editing autogenerated files like configure or libtool. I guess E:\MINGW32\BIN\AS.EXE would work, but something (MSYS? dlltool itself?) always seems to translate it to E:/MINGW32/BIN/AS.EXE, which doesn't work. ---------------------------------------------------------------------- Comment By: Paul Garceau (pgarceau) Date: 2004-02-13 23:38 Message: Logged In: YES user_id=1762 Checked under Win98 (plain vanilla Mingw) using latest binutils. Problem is gone. output now: D:\mingw>dlltool -v D:\MINGW\BIN\DLLTOOL.EXE: Using file: D:\MINGW\BIN\as D:\MINGW\BIN\DLLTOOL.EXE: Processing definitions D:\MINGW\BIN\DLLTOOL.EXE: Processed definitions ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2004-02-13 18:28 Message: Logged In: YES user_id=11494 This should have been fixed by libiberty changes. Can some one test on w9x with recent binutils. 2003-07-02 Danny Smith <dan...@us...> * pex-win32.c (fix_argv): Ensure that the executable pathname uses Win32 backslashes. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2004-02-13 16:41 Message: Logged In: YES user_id=15438 I don't think this has been resolved. The fix will need to be resolved in dlltool to insure that the exec'ed process contains \ instead of /. Earnie. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-02-19 04:20 Message: Logged In: YES user_id=15438 mingw-Bugs-689160 is being tracked here. ---------------------------------------------------------------------- Comment By: Paul Garceau (pgarceau) Date: 2003-02-18 16:14 Message: Logged In: YES user_id=1762 A similar pathing error occurs using dllwrap.exe for Win9x/Me. In this case, however, it is caused when dllwrap.exe attempts to run g++.exe. Details: g++ -v Reading specs from d:/msys/1.0/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.2 (mingw special 20030208-1) dllwrap -vers GNU d:\msys\1.0\mingw\bin\dllwrap.exe 2.13 sh --version GNU bash, version 2.04.0(1)-release (i686-pc-msys) OS: Win98 Error: dllwrap --driver-name=g++ ... -q --def= foo_out.def --no-export-all-symbols --dllname foo.dll yields: d:\msys\1.0\mingw\bin\dllwrap.exe: installation problem, cannot exec `g++': No such file or directory ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2003-01-04 21:59 Message: Logged In: YES user_id=30442 Yes, Kevin was right originally when he said that MSYS translates the PATH variable to forward slashes. I can reproduce this error on Win98 but apparently it works fine on Win2K, which is not surprising. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2003-01-04 21:39 Message: Logged In: YES user_id=573515 >Kevin, is this still a problem with MSYS-1.0.8.exe? Unfortunately, it is. :-( I have installed the production MSYS-1.0.8.exe and I still get (using --as=as): e:\mingw32\bin\dlltool.exe: run: as -o .libs/libticables- 3.dll-exp dc.s e:\mingw32\bin\dlltool.exe: No such file or directory e:\mingw32\bin\dlltool.exe: installation problem, cannot exec `as' whereas running: as -o .libs/libticables-3.dll-exp dc.s directly from the (MSYS bash) command line works just fine. Just as before, using --as=as.exe, --as=/mingw/bin/as, -- as=/mingw/bin/as.exe, or even --as=E:\mingw32 \bin\as.exe does not work either, whereas omitting --as entirely does work (but as I said, libtool won't let me do that within the libtoolized build without patching auto- generated files). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-01-04 19:17 Message: Logged In: YES user_id=15438 Are you Kevin, the OP? I think not. Your problem is that your command line ``dlltool --as /mingw/bin/as.exe --output-lib libd3d8.a --input-def d3d8.def --dllname d3d8.dll -k'' uses /mingw/bin/as.exe as a path argument to the --as switch and you're not using the MSYS shell. Earnie. ---------------------------------------------------------------------- Comment By: Rupesh Srivastava (uhap078) Date: 2003-01-04 12:04 Message: Logged In: YES user_id=663829 hi - I still don't know where the problem is - which is frustrating - but I've got a workaround to my specific problem of tying to run reimp. As I mentioned before, I can generate .a files manually. So I've knocked up a C++ app which does the following: - search current directory for libs - generate batch file with the necessary params for reimp and dlltool - execute batch file and remove it afterwards It's not that elegant - but it works. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2003-01-04 09:26 Message: Logged In: YES user_id=15438 Kevin, is this still a problem with MSYS-1.0.8.exe? Earnie. ---------------------------------------------------------------------- Comment By: Rupesh Srivastava (uhap078) Date: 2002-12-06 13:30 Message: Logged In: YES user_id=663829 hi everyone. I stumbled across this post - as I'm having similar problems - but on XP Pro. I'm running MinGW and downloaded the utils so that I could run reimp on some directx 8 libs. The def files get generated but the error "Invalid argument" occurs for dlltool. On closer inspection, I got the following error msg: dlltool: installation problem, cannot exec `as'. So I tried the following for the d3d8.lib file (manually): dlltool --as /mingw/bin/as.exe --output-lib libd3d8.a --input-def d3d8.def --dllname d3d8.dll -k and that works fine :-) However the reimp stuff still bombs (after generating the def file) - but I guess I'll eventually get to the bottom of it. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-12-02 11:52 Message: Logged In: YES user_id=11494 My experience: Passing forward-slashed commandline args to W95,W98,or WinME versions of CreateProcess (or any of the spawn CRT functions that wrapt CreateProcess) cause problems _iff_ the command-line arg is quoted. Now libiberty;s pexecute which dlltool (and many other GCC tools) uses to run commands takes great pain to ensure that the args are quoted to sort out problems with embedded blanks in filenames. You can't win. This is not problem on NT lineage of CreateProcess Danny ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2002-12-02 03:53 Message: Logged In: YES user_id=573515 And I can confirm my supposition: running "/c/command.com //c set" or "/c/command.com //c echo %PATH%" from MSYS shows that the inherited PATH uses forward slashes as path separators. ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2002-12-02 03:47 Message: Logged In: YES user_id=573515 It is, but the path gets translated to POSIX and back to Win32 by MSYS as well, so it probably has the same problem. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2002-12-02 03:22 Message: Logged In: YES user_id=30442 If you pass --as=/mingw/bin/as.exe, MSYS would translate it to --as=e:/mingw32/bin/as.exe, but I wasn't aware that the forward slashes would be a problem on WinME. However, MSYS will not translate --as=as or --as=as.exe, so there is probably another problem. Is as.exe in your PATH? ---------------------------------------------------------------------- Comment By: Kevin Kofler (kevinkofler) Date: 2002-12-01 15:39 Message: Logged In: YES user_id=573515 I should add that I am currently using MSYS 1.08-rc4. What's strange is that "dlltool --as=as" or "dlltool -- as=as.exe" does not work either, whereas omitting --as works. The output from "dlltool -v --as=as.exe ..." is: ... e:\mingw32\bin\dlltool.exe: run: as.exe - o .libs/libticables-3.dll-exp dc.s e:\mingw32\bin\dlltool.exe: No such file or directory e:\mingw32\bin\dlltool.exe: installation problem, cannot exec `as.exe' The output from "dlltool -v --as=as ..." is: ... e:\mingw32\bin\dlltool.exe: run: as -o .libs/libticables- 3.dll-exp dc.s e:\mingw32\bin\dlltool.exe: No such file or directory e:\mingw32\bin\dlltool.exe: installation problem, cannot exec `as' When I omit --as, I get: ... e:\mingw32\bin\dlltool.exe: run: e:\mingw32\bin\as - o .libs/libticables-3.dll-exp dc.s e:\mingw32\bin\dlltool.exe: Generated exports file ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2002-12-01 15:28 Message: Logged In: YES user_id=11494 AFAICT, dlltool use the name of as exactly as entered on the command line. I cannot reproduce the error when running dlltool from a DOS box on W98. Earnie, is this a msys bug? Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=646577&group_id=2435 |