[Bug binutils/28885] dlltool broke in 2.38

[martin at martin dot st]

https://sourceware.org/bugzilla/show_bug.cgi?id=28885

--- Comment #2 from Martin Storsjö <martin at martin dot st> ---
(In reply to Brendan Shanks from comment #1)
> With fdeee5d59dca41e3c70c399a939105e39a4b4282, the temporary file prefix
> will be taken from the .def file, and the .def files may not have unique
> names. For example, in mingw-w64-crt/lib64, d3dcompiler_{33,34,35,36}.def
> all have the same LIBRARY name inside: "D3DCompiler.dll" [1].

Sorry about this - I really didn't forsee that this would be an issue.

> I've also seen this bug when building Wine (on both Linux and macOS), where
> multiple dlltools may be launched at the same time to build delay-load and
> cross libraries for the same DLL (using the same .spec as input). 

In wine, what cases of multiple parallel import libraries targeting the same
DLL name?

> I'm not sure of the best fix for this: maybe add a command-line option to
> use a deterministic tmp_prefix, with the caveat that parallel builds may
> fail?

That doesn't sound very ideal to me. Ideally it would do the right thing,
deterministically, out of the box, without conflict.

If the issue is that the deterministic temp file names can clash when running
multiple dlltool invocations in parallel, should we perhaps create a separate
temp directory (where the name can be nondeterministic), where we make sure we
get a unique directory that nobody else is using, then write all temp files
within that one?

Or should we make the deterministic temp prefix based on something else, e.g.
the ouput (path+)filename? That should be unique even with multiple jobs
running in parallel, if they're running in the same directory. The temp prefix
base might end up slightly longer, so it's maybe a little less elegant, but
should be much safer against clashes.

> (As an aside, I'm not sure why one would want deterministic tmp file names.
> Maybe for reproducible builds?)

Msys2 had issues with the nondeterministic nature of dlltool. In most cases,
the temp prefix doesn't matter - but for umbrella libraries like libucrt.a,
which is merged from a number of individual import libraries like this,
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-crt/lib-common/ucrt.mri,
it matters: The temp prefix for all the individual libraries making up
libucrt.a must be unique, otherwise ld.bfd mixes up the object files for those
libraries, producing intermixed import tables for those DLLs. See
https://github.com/msys2/MINGW-packages/issues/9363#issuecomment-899100856 for
the root cause.

We worked around this with
https://github.com/mingw-w64/mingw-w64/commit/0ad299826ca14987fd53664c1047f4dfe848c3f8,
which adds the --temp-prefix option (based on the output import library name,
which should be unique) if the option is supported.

We also noticed that Debian had been using the --temp-prefix option in this way
to make their builds reproducible:
https://salsa.debian.org/mingw-w64-team/mingw-w64/-/blob/master/debian/patches/dlltool-temp-prefix.patch

Based on this, I thought it'd be good if we could make dlltool fix both of
these issues out of the box, so that users of it don't need to take extra steps
to both achieve reproducibility and avoid the intermixed import tables.

(Also, if building a newer version of mingw-w64 that contains the commit above,
which explicitly sets the --temp-prefx option, I think this bug wouldn't be
noticed at all. So, good that you've caught it at least!)

-- 
You are receiving this mail because:
You are on the CC list for the bug.