#222 dlltool --as broken on Me: can't exec as

component_package
closed-fixed
nobody
binutils (105)
2004-02-15
2002-12-01
Kevin Kofler
No

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.

Discussion

  • Danny Smith
    Danny Smith
    2002-12-01

    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

     
  • Kevin Kofler
    Kevin Kofler
    2002-12-01

    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

     
  • Luke Dunstan
    Luke Dunstan
    2002-12-02

    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?

     
  • Kevin Kofler
    Kevin Kofler
    2002-12-02

    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.

     
  • Kevin Kofler
    Kevin Kofler
    2002-12-02

    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.

     
  • Danny Smith
    Danny Smith
    2002-12-02

    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

     
  • 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.

     
  • Earnie Boyd
    Earnie Boyd
    2003-01-04

    Logged In: YES
    user_id=15438

    Kevin, is this still a problem with MSYS-1.0.8.exe?

    Earnie.

     
  • Earnie Boyd
    Earnie Boyd
    2003-01-04

    • milestone: --> component_package
    • assigned_to: dannysmith --> earnie
    • labels: 103947 --> 380073
     
  • 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.

     
  • Earnie Boyd
    Earnie Boyd
    2003-01-05

    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.

     
  • Kevin Kofler
    Kevin Kofler
    2003-01-05

    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).

     
  • Luke Dunstan
    Luke Dunstan
    2003-01-05

    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.

     
  • Paul Garceau
    Paul Garceau
    2003-02-19

    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

     
  • Earnie Boyd
    Earnie Boyd
    2003-02-19

    Logged In: YES
    user_id=15438

    mingw-Bugs-689160 is being tracked here.

     
  • Earnie Boyd
    Earnie Boyd
    2004-02-14

    • priority: 5 --> 9
    • labels: 380073 --> binutils
    • assigned_to: earnie --> nobody
     
  • Earnie Boyd
    Earnie Boyd
    2004-02-14

    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.

     
  • Danny Smith
    Danny Smith
    2004-02-14

    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
    <dannysmith@users.sourceforge.net>

    \* pex-win32.c \(fix\_argv\): Ensure that the
    

    executable pathname
    uses Win32 backslashes.

     
  • Paul Garceau
    Paul Garceau
    2004-02-14

    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

     
  • Earnie Boyd
    Earnie Boyd
    2004-02-15

    • status: open --> closed-fixed