[PATCH] D63109: lld-link: Reject more than one resource .obj file

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In D63109#1621146 <https://reviews.llvm.org/D63109#1621146>, @thakis wrote:

> In D63109#1558181 <https://reviews.llvm.org/D63109#1558181>, @mstorsjo wrote:
>
> > In D63109#1557242 <https://reviews.llvm.org/D63109#1557242>, @thakis wrote:
> >
> > > I think all four combinations of {llvm-cvtres,cvtres.exe} x {llvm-link,link.exe} should have the same behavior. What does link.exe say to two windres outputs? What does GNU ld do with two cvtres.exe inputs?
> >
> >
> > After a bit more testing, I have the following result matrix:
> >
> >              windres .o    cvtres .obj      llvm-cvtres.obj     .res
> >   GNU ld     Both          First            First               not supported
> >   link.exe   First         Error            Error               Both
> >   lld-link   None          Error            Error               Both
> >
> >
> > Noted oddities:
> >
> > - When lld-link produces an error in these cases (faced with two resource obj files), the output exe file is still present on disk though, contrary to link.exe
> > - lld-link seems to fail to use resources packaged by windres into object files. Will look into why.
> > - lld-link also seems to have issues with object files produces by cvtres (tested with cvtres from both MSVC 2019 and MSVC2015), the resources aren't located at runtime - even when only given one single file, while files from llvm-cvtres works fine. Will also look into why for this case.
> >
> >   Thus, for lld-link, neither windres nor cvtres object files work at the moment, only llvm-cvtres (and plain .res files).
>
>
> Did this ever get sorted out? I saw D63837 <https://reviews.llvm.org/D63837> go by a while ago which from a distance looks related. Did that fix everything? Do all tools agree now?


Sorry for not following up on this thread earlier.

The immediate issue I had in VLC turned out to be easy to fix after all (you know automake, it's hard to determine if something is "almost trivial but I haven't figured it out yet" or "near impossible" :P), so sorry for raising this as such a big issue before.

The commit you saw above fixed the fact that lld failed to pick up resource objs from both windres and MS cvtres, fixing most of what I was surprised by above.

Lld still doesn't error out if you pass it two resource objects produced by GNU windres. I'm planning on fixing this, but I'm conveniently postponing it a little (to keep this case accidentally working), I hope that is ok with you. (MS cvtres and llvm-cvtres produce sections called `.rsrc$01` and `.rsrc$02`, while GNU windres just produces one, `.rsrc`.)

Namely: I found out that there are cases in mingw where one often will have two resource objects in each link, namely if linking using lld, in msys2, with certain packages installed, with GCC as the driver calling the linker. Since some time, GCC got the concept of a "default manifest" resource object. If such a file exists on disk (the default-manifest package is installed), it will be automatically added to each link command. Since the advent of this concept (a couple years ago), GNU ld has support for merging resource trees from multiple resource objects, with logic kind of like what lld has, to warn if there are duplicates, but with special logic for silently dropping the default manifest if the user actually provided one.

I'm considering implementing this, but until then, accidentally accepting this situation (where only the user provided resource object ends up visible and the later default manifest one is ignored) feels ok.

The issue where lld errors out due to multiple resource objects, but the output file is left on disk, is something I haven't looked at (or tried to reproduce) yet.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63109/new/

https://reviews.llvm.org/D63109