-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wget, wget2] /usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25 #11698
Comments
@DavidKorczynski @AdamKorcz do you have ideas here? |
The dwarf error seems to be a symptom, but not the cause of the build failure. I think the build failure is
See #11839 |
This is to resolve * https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68175 * https://issues.apache.org/jira/browse/PROTON-2819 ## Note to self When trying this out locally, I noticed symptoms of #11698, so I also tried adding ``` # Use lld for linking as it is drop-in replacement more compatible with Clang # #11698 RUN apt-get install -y lld && \ ln --force -s /usr/bin/lld /usr/local/bin/ld ``` In the end I noticed the following, which made me realize I am running out of disk space for docker. After redownloading docker images, the local build started working for me both with and without the above change, so for now I am not including that one ``` ld: error: /usr/local/lib/clang/15.0.0/lib/linux/libclang_rt.msan-x86_64.a: failed to parse archive: truncated or malformed archive (terminator characters in archive member "\000\000" not the correct "`\n" values for the archive member header for ) clang-15: error: linker command failed with exit code 1 (use -v to see invocation) ```
I think that this has something to do with this stuff here:
the if check only passes when we use memory sanitizer. I tried to compile nettle with the
and it seems to compile nettle all fine. |
After compiling nettle it tries to compile gnulib (I think) and I get these errors:
but maybe that should be opened in another issue? |
I fixed the build.sh script such that it now atleast compiles. Definitely not pretty, but atleast it compiles I have documented my fixes here in a blog post (I wrote these notes while I was debugging): https://personnumber3377.github.io/projects/improving_wget_options_fuzzer.html#final-thoughts and here is the final diff patch to the root of oss-fuzz as a file: https://personnumber3377.github.io/projects/patch.diff . I had to modify the helper.py script to have the -detect_leaks=0 option always enabled, because I didn't know how to enable it through the helper. |
@personnumber3377 Thanks for the detailed write-up! I'll go through it and try to figure out why some things failed for you (e.g. the gnulib failure come quite unexpected to me). |
@rockdaboot yeah, I couldn't find anything on the internet on why it failed for mean. It may be because of the different versions of autotools or something like that. I don't really know that much about how to actually use autotools, so I am quite clueless in that. Also about adding my code to the wget project: Is there any easier way to do it other than through FSF? I don't really feel like going through all of the paperwork. Is it possible to contribute to the wget project, but I still reserve copyright of those changes which I did? (I assume that is either not possible or quite complex to do.) In FSF do I just send the email to assign@gnu.org with the information which you listed? I have never before contributed to open source, so I don't really know how this works. Also does FSF also include future changes which I may make? I have heard of copyright disclaimers, where I just sign it and after that I no-longer have copyright over it: https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html . |
@personnumber3377 After testing, I opened https://gitlab.com/gnutls/gnutls/-/issues/1552. But I also found a work-around for wget2. Let's talk about code contributions either on a private channel or on the public mailing list bug-wget@gnu.org, it's slightly OT here. |
Fixed the wget build in #11998. Indeed, the message "/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25" was misleading and seems to be plain wrong. Closing. |
The builds for wget and wget2 fail since a while because of this error.
My guess is that
clang
emits dwarf5 data whileld
(version 2.34) can't handle it.Maybe either update
ld
in the docker image or letclang
emit dwarf4!?Any other suggestion?
The text was updated successfully, but these errors were encountered: