[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/29497] `x86_64-w64-mingw32-dlltool -m i386` doesn't produc
From: |
nickc at redhat dot com |
Subject: |
[Bug binutils/29497] `x86_64-w64-mingw32-dlltool -m i386` doesn't produce a fully i386 importlib |
Date: |
Mon, 22 Aug 2022 13:54:35 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=29497
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed| |2022-08-22
CC| |nickc at redhat dot com
Assignee|unassigned at sourceware dot org |nickc at redhat dot com
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Mike,
I think that this is more of a documentation problem than anything.
Would you be happy with a rewording of the description of the -m option
so that it said:
-m <machine>
Specifies the type of machine for which the library file
should be built. dlltool has a built in default type,
depending upon how it was created, but this option can be
used to override that. This is normally only useful when
creating DLLs for an ARM processor, when the contents of
the DLL are actually encode using Thumb instructions, or
DLLs for the x86 architecture when dlltool is built for
the x86_64 architecture.
Note - it may be necessary to use the "-f <option>" command
line option to instruct whichever assembler is being used to
create binaries appropriate for the <machine> targeted by
the -m option. So for example when using "-m i386" it may
also be necessary to specify "-f --32".
The point being that there is no guarantee that the assembler being
used is the GNU assembler, and so some option other than --32 might
needed in order to generate 32-bit binaries. Hence -m cannot safely
infer which -f option should be used.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.