librsvg problem in clang #21017
Comments
|
I can reproduce the issue with clang64. |
|
yeah not really sure whats going on there ??? |
|
looks like an invalid section in the bcryptprimitives export though it is not even part of the mingw-w64-abi only bcrypt. |
|
ah i smell a mingw specific linker script sec investigating. |
|
There are no linker/version scripts involved since LLD doesn't support them at all and would just error out. |
|
exactly what i was after but yeah librsvg does not use a linker script so it seems to be something else going on. |
|
ok it is rust it seems, tried reverting to a previous version and now it builds... |
|
How to reproduce this problem? and so does current nightly: |
|
so some incompatibility between our version of rust/llvm and librsvg-2.58.0 ? |
|
wait you are using the nightly version of rust ? im on 1.78 O_o EDIT: nvm i see now |
|
It does reproduce when building MSYS2 package (and with upstream code not newer than 2.58 using some special steps). As I said previous on Discord something must be wrong with generated import libraries:
EDIT: Naturally those symbols are present in prebuilt std library as they originate from there: |
|
not sure if refering to me but im not on discord so i did not know :) but its being looked at thats what matters. |
|
I'm afraid I'm not competent enough to understand what is going on here. I've tried running objdump on those files but I don't even know what to look for (most of the differences are probably related to legacy vs short import lib format).
Details
Details
Details
Details
Details
Details
EDIT: Ah, I fixated on but looks like Probably |
|
yeah it also baffled me to no end... tried searching every freaking library or object file for a reference to where this might be comming from, took me all night and im still baffled (x_x). seems to work if i use an older version of llvm/clang together with an older rust build so it seems to be something recent. i even tried making an import library for bcryptprimitives.dll to look at the section data for that spurious 0 but sadly found nothing so it does not seem to be from any imports. since it only started happening with recent rust id wager some upstream change might have caused this unintentionally but as mati points out it works in the nightly rust build so the confusion is even worse. |
|
Not really minimal but at least self contained. |
|
Thanks - I've reproduced the issue and given it an initial look. It's possible to reproduce this issue with something as simple as this: The reason for this, is that import libraries are usually treated somewhat specially. MSVC style import libraries ("short import library") have a couple regular object files, and a number of synthetic files that just tells the linker about what should exist in the DLL. (This contrary to the old style import libraries, "long import library", which GNU tools produce, where all object files are regular object files, which together build the import tables.) Normally, when linking MSVC style import libraries, LLD doesn't really look at the files that are regular object file, and instead completely synthesize these tables instead. Now when linking with So lesson 1: Don't force including import libraries with However, if generating a similar import library with MSVC tools instead, (I note that looking at the object files from that import library with Even then, if I force linking the import library from MSVC with So even if we fix the LLVM import library generation to output things in the same form as MSVC does, we practically can't link against them with So, takeaways:
|
|
Thank you so much for this. So the problem might lie within the librsvg build system because IIUC it's not Rust who added that Question to anyone who knows autotools better: Talking about this line: |
|
As a side note here - it has to be mentioned, that this probably isn't an issue with the "long import library" format produced by the GNU tools - there, all object files are relevant and work entirely as usual object files, so linking them with
Not very familiar with this case, but it's quite plausible. Using I'm not famliar with Rust's libraries though, but why does it end up with import library members in the same library as other implementation files? Overall, import libraries are special enough that it feels odd to merge them in like that. Or is that done to make linking work, without needing to separately specify which import libraries to link against, making those libraries implicitly enabled? For the record, I tried tweaking |
I don't know the reasoning behind this, but when it comes to static libs, I suppose it's either by an accident or as an attempt to make things easier for the users. We've got the proof it makes things harder, so maybe it could be changed. There are also |
|
damn seems i hit a hornets nest :) but im glad it got figured out. |
|
Upstream Rust issue: rust-lang/rust#129020. |
Biswa96
added
the
reported-upstream
|
PR rust-lang/rust#129257 resolved this for MSVC. The AFAIK, there a currently 2 workarounds for this:
|
|
After looking at rust-lang/rust#129257, I realized that there was one aspect I hadn't checked before. LLD with But MS link.exe with So with that in mind, I guess it could be reasonable to make LLD handle that case better than it does right now. Unfortunately, I think such a fix may turn out to be much more complicated than you'd expect it to, which is a bit annoying given how much of an odd corner case this is. But I think it could be reasonable to try to fix it in LLD after all. For investigating and testing things, it would be interesting to have a sample of a rust generated short import library after rust-lang/rust#129257, where it has changed one section into a comdat section, if I understand it correctly; that'd be valuable to test against MS link.exe as well. |
|
Here's an example lib you can download and use wholearchive on: https://github.com/ChrisDenton/processprng/actions/runs/11124768552. Note that Rust is not doing the comdat thing anymore. Instead it renames a single symbol. Alternatively, you can just use wholearchive on an import lib generated by llvm or msvc and it should encounter the same problem. |
Thanks!
Oh, ok, I see. (I was a bit confused by this, as the PR description in rust-lang/rust#129257 talked about renaming symbols, while the actual commits in the PR seemed to just set the comdat flag.) Yeah I've tested wholearchive on import libs generated by LLVM and MSVC with lld before - but before I sit down and try to make it work, I wanted to have a sample of the comdat case that I thought you were generating. But if you've renamed the symbol, it should be less tricky for the linker to handle. Anyway, thanks, I think I've got everything I need for being able to implement this, once I have time to sit down and work on it. |
Description / Steps to reproduce the issue
building librsvg with clang produces this error ->
Expected behavior
should produce the librsvg build like with gcc
Actual behavior
bugs out with the above error
Verification
Windows Version
MSYS_NT-10.0-26100
MINGW environments affected
Are you willing to submit a PR?
No response
The text was updated successfully, but these errors were encountered: