SRI-CSL/gllvm

gllvm not compatible with musl-clang

MuhammadAbuBakar95 opened this issue · 11 comments

Hi.
I have run into an issue while building applications against musl-libc instead of glibc. Apparently, gllvm does not support the following flags:
"-fuse-ld=musl-clang".
" -static-libgcc".
These are necessary if we are to use the "musl-clang" wrapper (generated after building musl-libc with clang) .
An example invocation:

gclang -B/home/muhammad/musllvm/obj -fuse-ld=musl-clang -static-libgcc -nostdinc --sysroot /usr/local/musl -isystem /usr/local/musl/include -L-user-start program.c -L/usr/local/musl/lib -L-user-end

leads to

WARNING:Did not recognize the compiler flag: -static-libgcc
WARNING:Did not recognize the compiler flag: --sysroot
WARNING:Did not recognize the compiler flag: /usr/local/musl
clang: warning: argument unused during compilation: '-fuse-ld=musl-clang' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-static-libgcc' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-fuse-ld=musl-clang' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-static-libgcc' [-Wunused-command-line-argument]
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x12): undefined reference to `__libc_csu_fini'
(.text+0x19): undefined reference to `__libc_csu_init'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ERROR:clang [.program.o -B/home/muhammad/musllvm/obj -L-user-start -L/usr/local/musl/lib -L-user-end -o a.out] failed to link: exit status 1.

The above command works fine if I use clang instead of gclang so I am assuming the warnings are actually generated from the gclang source.

So it is xmas here, and so I don’t have my laptop at hand, but this is a quick fix. Especially if you help me by pointing out for each unknown flag whether it is compile time, link time, or both.

Sure. I did not expect a quick response.
The arguments that are not being recognized are
"-fuse-ld=musl-clang",
" -static-libgcc"
These are link time options.
"--sysroot"
is both compile and link time.

My gllvm-fu is quite stale. I think I have addressed these issues, but it would be nice if you could check for me, and let me know if I screwed up.

Thanks for the fix.
The "--sysroot dirname" is not being recognized at the moment but "--sysroot=dirname" is.
There is something weird going on with the "-fuse-ld=musl-clang" flag. On some runs it works fine and the resulting binary executes correctly. On other occasions, I get:

clang: warning: argument unused during compilation: '-fuse-ld=musl-clang' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-fuse-ld=musl-clang' [-Wunused-command-line-argument]

and the binary outputs:

error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header

It is possible that there might be something wrong with my own headers/libraries/system, but I highly doubt that since using clang instead of gclang works correctly every time.

Not surprised about --sysroot dirname that is something I did not add. But I will.
I will stare at the code and see if I can figure out the -fuse-ld=musl-clang mystery.

I added the binary variant of the --sysroot flag. I do not see why there is a problem with the use-ld incantation. Maybe you could switch on the logging and see when it happens? See if we can get some more context?

Sorry for the late reply. I think the problem is this line. The pattern "-f.+$", will also be present in "-fuse-ld=musl-clang".
Removing this line allows me to compile cleanly.

Excellent. I agree. It would be good to keep both, since there are a lot of -f flags that we should handle.
But I think that makes using a map not so convenient, so it will need to be a list. I shall play with this for a day or so.

OK wanna try the latest? I try the -fuse-ld pattern before the -f pattern so we use the right
callback.

This version works for me. Thanks for the fix.

Thanks for reporting this.