Restore LLVM compatibility #180
Comments
|
Could you try the 0.2 release? A regression slipped into the project at some point since then regarding LLVM support. We'll likely need to git bisect the repo to figure out exactly what caused it. I would recommend building on Linux if at all possible. That's the recommended and most supported approach. There's also this: https://justine.lol/cosmopolitan/windows-compiling.html |
|
0.2 works, or at least gives the impression of working since it spat
out some kind of thing.
However, this doesn't work:
C:\py\cosmopolitan>llvm-objcopy.exe -SO binary hello.com.dbg hello.com
llvm-objcopy.exe: error: too many positional arguments
I had to do:
C:\py\cosmopolitan>llvm-objcopy.exe hello.com.dbg hello.com
But when I ran hello.com, I got:
C:\py\COSMOP~1>hello
Program too big to fit in memory
…On 6/2/21, Justine Tunney ***@***.***> wrote:
Could you try the 0.2 release? A regression slipped into the project at some
point since then regarding LLVM support. We'll likely need to git bisect the
repo to figure out exactly what caused it.
I would recommend building on Linux if at all possible. That's the
recommended and most supported approach. There's also this:
https://justine.lol/cosmopolitan/windows-compiling.html
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#180 (comment)
|
|
Try doing Note that old release might have a bug with CMD.EXE integration. If you run the binary in mintty it's guaranteed to work. Whatever might be causing that, it got fixed before the 1.0 release. Now that we know LLVM on Windows worked before, could you help us |
jart
changed the title
|
I followed your steps and I think the binary works, but I'm on a
32-bit computer and it seems that Cosmopolitan only supports 64-bit
binaries so I am unsure.
The target thing just seemed obvious to me. I guess though that I
enjoy poking around with such things. It's also easy to forget about
it because it's hard to find a good use for it, given that you need
platform-specific stuff to compile and link against for your avarage
C++ project.
Can't bisect now, but I have WSL at home and will see what I can do.
…On 6/3/21, Justine Tunney ***@***.***> wrote:
Try doing `llvm-objcopy -S -O binary hello.com.dbg hello.com`. Here's what I
did and it worked with the 0.2 release.
```
clang -g -Os -static -nostdlib -nostdinc -fno-pie -mno-red-zone
-fno-omit-frame-pointer -o hello.com.dbg hello.c -Wl,-T,ape.lds -include
cosmopolitan.h --target=x86_64-pc-linux-gnu crt.o ape.o cosmopolitan.a
-Wl,-z,max-page-size=0x1000 -Wl,--gc-sections -fuse-ld=lld
llvm-objcopy -S -O binary hello.com.dbg hello.com
```
Note that old release might have a bug with CMD.EXE integration. If you run
the binary in mintty it's guaranteed to work. Whatever might be causing
that, it got fixed before the 1.0 release.
Now that we know LLVM on Windows worked before, could you help us `git
bisect` the repo so we can fix whatever introduced the regression? By the
way, `--target=x86_64-pc-linux-gnu` is a brilliant insight I failed to
consider. That could help us greatly.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#180 (comment)
|
|
I'm having problems with WSL2 similar to issue #6 ERROR Thompson Shell Backwards Compatibility Issue Detected DETAILS Actually Portable Executable assumes stock Linux configuration. WORKAROUND sudo sh -c "echo ':APE:M::MZqFpD::/bin/sh:' >/proc/sys/fs/binfmt_misc/register" SEE ALSO https://justine.storage.googleapis.com/ape.html Terminated That workaround didn't seem to do anything even after restarting WSL. Unsupported 16-Bit Application The program or feature "??\C:\py\git\cosmopolitan\build\sanitycheck2" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available. |
|
Try running |
|
Did a bisection and found it. |
|
It turns out I am having trouble actually running the resulting binaries. They build find, but hello.com.dbg runs fine, printing 'Hi!' as expected, but if I run hello.com from Windows I get: |
|
Apparently the secret is to build Cosmopolitan with LLVM. It works now. |
Things are a little better. The LLD that comes with Linux seems to work. Old versions like LLVM 8 haven't been supported since Cosmopolitan v0.2. Running Clang on Windows with --target=x86_64-pc-linux-gnu doesn't seem to work. It has something to do with the recently added .zip section in the linker script. But even if that's removed, LLD on Windows thinks it is building an EFI application for some reason. Linker scripts are such a brittle house of cards, even for just ld.bfd alone.. We should just find a way to run our one true musl-cross-make linux gcc toolchain under Blinkenlights on non-Linux because GCC and Clang are so nondeterministic, inconsistent, and unreproducible when built for other operating systems. We need an actually portable compiler/linker that'll always behave the same way no matter what. See #180
|
Thanks for bisecting that! You've added a lot of clarity. It kind of works for me, but not Windows. It seems to have something to do with the |
|
Why would it be a windows thing? We're targeting Linux, and I think I
also got the same relocation linker error when trying to compile
Cosmopolitan 1.0 from within WSL.
…On 7/5/21, Justine Tunney ***@***.***> wrote:
Thanks for bisecting that! You've added a lot of clarity. It kind of works
for me, but not Windows. It seems to have something to do with the `.zip`
section that was added to the linker script. We do kind of a weird thing,
where we put the zip files in-between .data and .bss and we don't define
them in the program headers since we don't want it to be loaded by the
operating system. No one's probably done that before. It bewilders me why
LLD is behaving so differently on Windows.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#180 (comment)
|
|
I went and built a hello world example with Clang, using the exact same invocation: |
|
@jart |
|
Cosmopolitan: 2.2 Current error using LLD$> clang -g -Os -static -nostdlib -nostdinc -fno-pie -mno-red-zone -fno-omit-frame-pointer -o hello.com.dbg hello.c -Wl,-T,libcosmo/ape.lds -include libcosmo/cosmopolitan.h libcosmo/crt.o libcosmo/ape.o libcosmo/cosmopolitan.a -Wl,-z,max-page-size=0x1000 -Wl,--gc-sections -fuse-ld=lld -v
Ubuntu clang version 14.0.0-1ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/lib/llvm-14/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name hello.c -static-define -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -disable-red-zone -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/kassane/rust-ape-example -nostdsysteminc -nobuiltininc -resource-dir /usr/lib/llvm-14/lib/clang/14.0.0 -include libcosmo/cosmopolitan.h -Os -fdebug-compilation-dir=/home/kassane/rust-ape-example -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/hello-314d15.o -x c hello.c
clang -cc1 version 14.0.0 based upon LLVM 14.0.0 default target x86_64-pc-linux-gnu
#include "..." search starts here:
End of search list.
"/usr/bin/ld.lld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -static -o hello.com.dbg -L/usr/bin/../lib/gcc/x86_64-linux-gnu/12 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib /tmp/hello-314d15.o -T libcosmo/ape.lds libcosmo/crt.o libcosmo/ape.o libcosmo/cosmopolitan.a -z max-page-size=0x1000 --gc-sections
ld.lld: error: libcosmo/cosmopolitan.a: could not get the buffer for the member defining symbol __fmt_dtoa: truncated or malformed archive (long name offset characters after the '/' are not all decimal numbers: '10462\000' for archive member header at offset 6920446)
clang: error: linker command failed with exit code 1 (use -v to see invocation) |
Any update on how to resolve this? |
|
I'm getting a similar error with llvm 17 on debian 😕 |
|
The libc almost builds with LLVM 18 built from git and Casting it to a Removing those definitions then gives: |
|
Maybe you should try to un-archive it and archive it again with llvm-ar |
The first error I got when trying again now was this: |
|
Has this issue been solved? Since cosmo got a lot of updates lately (needless to say but awesome project!) |
|
Clang is now part of cosmocc. You can say |
|
This doesn't solve building cosmopolitan with clang though. I still get errors about missing warning flags. |
|
Why do you need to build cosmopolitan with clang? |
|
Back then, I was trying to compile Zig and link code against this libc so we could build APEs with Zig, but it kept failing (the problem was due to clang as described above) |
I downloaded cosmopolitan.zip and tried to create me a portable executable using Clang. I thought that it should work since Clang can generate code for any CPU as long as you have the correct headers and libs ETC.
C:\py\cosmopolitan>clang -g -O -o hello.com.dbg hello.c -static -fno-pie -no-pie -mno-red-zone -fno-omit-frame-pointer -nostdlib -nostdinc -Wl,--gc-sections -Wl,-z,max-page-size=0x1000 -Wl,-T,ape.lds -include cosm
opolitan.h crt.o ape.o cosmopolitan.a --target=x86_64-pc-linux-gnu
ld.lld: error: cosmopolitan.a(zip.o):(.zip.5+0x10): relocation R_X86_64_32 out o
f range: 18446744073705357312 is not in [0, 4294967295]
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
It would be nice if this was supported, because just about everyone has clang on their computer.
The text was updated successfully, but these errors were encountered: