Gperf fails to compile
dslm4515 opened this issue · comments
Gperf fails to compile with the final system clang [built by stage0 clang] ... g++ is a symlink to clang-15:
g++ -g -O2 -I. -I./../lib -c ./main.cc
g++ -g -O2 -o gperf version.o positions.o options.o keyword.o keyword-list.o input.o bool-array.o hash-table.o search.o output.o main.o ../lib/libgp.a
-lm
ld: error: undefined symbol: operator new[](unsigned long)
>>> referenced by keyword.cc:81 (./keyword.cc:81)
>>> keyword.o:(KeywordExt::init_selchars_low(Positions const&, unsigned int const*, unsigned int const*))
>>> referenced by input.cc:595 (./input.cc:595)
>>> input.o:(Input::read_input())
>>> referenced by input.cc:605 (./input.cc:605)
>>> input.o:(Input::read_input())
>>> referenced 31 more times
ld: error: undefined symbol: operator delete[](void*)
>>> referenced by keyword.cc:133 (./keyword.cc:133)
>>> keyword.o:(KeywordExt::delete_selchars())
>>> referenced by input.cc:601 (./input.cc:601)
>>> input.o:(Input::read_input())
>>> referenced by input.cc:611 (./input.cc:611)
>>> input.o:(Input::read_input())
>>> referenced 29 more times
ld: error: undefined symbol: __cxa_pure_virtual [13/288]
>>> referenced by keyword.cc
>>> keyword.o:(vtable for Keyword_Factory)
ld: error: undefined symbol: vtable for __cxxabiv1::__class_type_info
>>> referenced by keyword.cc
>>> keyword.o:(typeinfo for Keyword_Factory)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Constants)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Expr)
>>> referenced 1 more times
>>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction)
ld: error: undefined symbol: operator new(unsigned long)
>>> referenced by keyword-list.cc:52 (./keyword-list.cc:52)
>>> keyword-list.o:(copy_list(Keyword_List*))
>>> referenced by keyword-list.cc:52 (./keyword-list.cc:52)
>>> keyword-list.o:(copy_list(KeywordExt_List*))
>>> referenced by input.cc:977 (./input.cc:977)
>>> input.o:(Input::read_input())
>>> referenced 6 more times
ld: error: undefined symbol: operator delete(void*)
>>> referenced by keyword-list.cc:75 (./keyword-list.cc:75)
>>> keyword-list.o:(delete_list(Keyword_List*))
>>> referenced by input.cc:977 (./input.cc:977)
>>> input.o:(Input::read_input())
>>> referenced by search.cc:798 (./search.cc:798)
>>> search.o:(Search::prepare_asso_values())
>>> referenced 17 more times
ld: error: undefined symbol: __gxx_personality_v0
>>> referenced by input.cc
>>> input.o:(DW.ref.__gxx_personality_v0)
ld: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Defines)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Enum)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Expr1)
>>> referenced 4 more times
>>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction)
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:74: gperf] Error 1
make[1]: Leaving directory '/sources/gperf-3.1/src'
make: *** [Makefile:34: all] Error 2
But if I use the stage0 clang, no errors. Gperf compile fine
If I set LDFLAGS="-Wl,--verbose" for more output from LLD:
clang++ -lc++ -Wl,--verbose -o gperf version.o positions.o options.o keyword.o keyword-list.o input.o bool-array.o hash-table.o search.o output.o main.
o ../lib/libgp.a -lm
ld: /usr/bin/../lib/Scrt1.o
ld: /usr/bin/../lib/crti.o
ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/clang_rt.crtbegin.o
ld: /usr/bin/../lib/libc++.so
ld: version.o
ld: positions.o
ld: options.o
ld: keyword.o
ld: keyword-list.o
ld: input.o
ld: bool-array.o
ld: hash-table.o
ld: search.o
ld: output.o
ld: main.o
ld: ../lib/libgp.a
ld: /usr/bin/../lib/libm.a
ld: /usr/bin/../lib/libc++.so
ld: /usr/bin/../lib/libm.a
ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/libclang_rt.builtins.a
ld: /usr/bin/../lib/libunwind.so
ld: /usr/bin/../lib/libc.so
ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/libclang_rt.builtins.a
ld: /usr/bin/../lib/libunwind.so
ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/clang_rt.crtend.o
ld: /usr/bin/../lib/crtn.o
ld: error: undefined symbol: __cxa_begin_catch
>>> referenced by options.cc [43/85]
>>> options.o:(__clang_call_terminate)
ld: error: undefined symbol: std::terminate()
>>> referenced by options.cc
>>> options.o:(__clang_call_terminate)
ld: error: undefined symbol: __gxx_personality_v0
>>> referenced by options.cc
>>> options.o:(DW.ref.__gxx_personality_v0)
ld: error: undefined symbol: operator new[](unsigned long)
>>> referenced by keyword.cc
>>> keyword.o:(KeywordExt::init_selchars_low(Positions const&, unsigned int const*, unsigned int const*))
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced 26 more times
ld: error: undefined symbol: operator delete[](void*)
>>> referenced by keyword.cc
>>> keyword.o:(KeywordExt::delete_selchars())
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced 29 more times
ld: error: undefined symbol: __cxa_pure_virtual
>>> referenced by keyword.cc
>>> keyword.o:(vtable for Keyword_Factory)
>>> referenced by output.cc
>>> output.o:(vtable for Output_Expr)
>>> referenced by output.cc
>>> output.o:(vtable for Output_Constants)
>>> referenced 3 more times
ld: error: undefined symbol: vtable for __cxxabiv1::__class_type_info
>>> referenced by keyword.cc
>>> keyword.o:(typeinfo for Keyword_Factory)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Constants)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Expr)
>>> referenced 1 more times
>>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction)
ld: error: undefined symbol: operator new(unsigned long)
>>> referenced by keyword-list.cc
>>> keyword-list.o:(copy_list(Keyword_List*))
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced by search.cc
>>> search.o:(Search::prepare_asso_values())
>>> referenced 5 more times
ld: error: undefined symbol: operator delete(void*)
>>> referenced by keyword-list.cc
>>> keyword-list.o:(copy_list(Keyword_List*))
>>> referenced by keyword-list.cc
>>> keyword-list.o:(delete_list(Keyword_List*))
>>> referenced by input.cc
>>> input.o:(Input::read_input())
>>> referenced 17 more times
ld: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Defines)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Enum)
>>> referenced by output.cc
>>> output.o:(typeinfo for Output_Expr1)
>>> referenced 4 more times
>>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction)
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:74: gperf] Error 1
make[1]: Leaving directory '/sources/gperf-3.1/src'
make: *** [Makefile:34: all] Error 2
Looks like OpenSSL also fails to build with final system clang, but compiles fine with stage0 clang
Also ninja, coreutils ...
Looks like OpenSSL also fails to build with final system clang, but compiles fine with stage0 clang
I haven't studied about Clang in years (since 2021, the last time I contributed here), but maybe it's a question of linking?
I mean, by looking at the errors, it seems like that stage0 Clang may links to libraries that aren't available (visible, or in the library path) to final system Clang. Maybe I'm talking no sense, but I would check out the logs. Try to use -Wl,--verbose and -v in Clang and see if we get something more explainable. I'm working in another project here, so I can't test my hypothesis right now.
In any case, we could still be using alternatives that (may) build fine with Clang, such as LibreSSL and samurai.
By the way, talking about "alternatives", what about linking Shadow to OpenPAM (in BMLFS, in the case) instead of Linux-PAM? I didn't found many information about why most distributions link to Linux-PAM instead of OpenPAM (is it just a question of compatibility?), and it would be interesting to have OpenPAM as an alternative. I've tested it at Copacabana Linux, it compiles just fine in musl.
If I set
LDFLAGS="-Wl,--verbose"for more output from LLD:clang++ -lc++ -Wl,--verbose -o gperf version.o positions.o options.o keyword.o keyword-list.o input.o bool-array.o hash-table.o search.o output.o main. o ../lib/libgp.a -lm ld: /usr/bin/../lib/Scrt1.o ld: /usr/bin/../lib/crti.o ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/clang_rt.crtbegin.o ld: /usr/bin/../lib/libc++.so ld: version.o ld: positions.o ld: options.o ld: keyword.o ld: keyword-list.o ld: input.o ld: bool-array.o ld: hash-table.o ld: search.o ld: output.o ld: main.o ld: ../lib/libgp.a ld: /usr/bin/../lib/libm.a ld: /usr/bin/../lib/libc++.so ld: /usr/bin/../lib/libm.a ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/libclang_rt.builtins.a ld: /usr/bin/../lib/libunwind.so ld: /usr/bin/../lib/libc.so ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/libclang_rt.builtins.a ld: /usr/bin/../lib/libunwind.so ld: /usr/lib/clang/15.0.5/lib/x86_64-pc-linux-musl/clang_rt.crtend.o ld: /usr/bin/../lib/crtn.o ld: error: undefined symbol: __cxa_begin_catch >>> referenced by options.cc [43/85] >>> options.o:(__clang_call_terminate) ld: error: undefined symbol: std::terminate() >>> referenced by options.cc >>> options.o:(__clang_call_terminate) ld: error: undefined symbol: __gxx_personality_v0 >>> referenced by options.cc >>> options.o:(DW.ref.__gxx_personality_v0) ld: error: undefined symbol: operator new[](unsigned long) >>> referenced by keyword.cc >>> keyword.o:(KeywordExt::init_selchars_low(Positions const&, unsigned int const*, unsigned int const*)) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced 26 more times ld: error: undefined symbol: operator delete[](void*) >>> referenced by keyword.cc >>> keyword.o:(KeywordExt::delete_selchars()) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced 29 more times ld: error: undefined symbol: __cxa_pure_virtual >>> referenced by keyword.cc >>> keyword.o:(vtable for Keyword_Factory) >>> referenced by output.cc >>> output.o:(vtable for Output_Expr) >>> referenced by output.cc >>> output.o:(vtable for Output_Constants) >>> referenced 3 more times ld: error: undefined symbol: vtable for __cxxabiv1::__class_type_info >>> referenced by keyword.cc >>> keyword.o:(typeinfo for Keyword_Factory) >>> referenced by output.cc >>> output.o:(typeinfo for Output_Constants) >>> referenced by output.cc >>> output.o:(typeinfo for Output_Expr) >>> referenced 1 more times >>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction) ld: error: undefined symbol: operator new(unsigned long) >>> referenced by keyword-list.cc >>> keyword-list.o:(copy_list(Keyword_List*)) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced by search.cc >>> search.o:(Search::prepare_asso_values()) >>> referenced 5 more times ld: error: undefined symbol: operator delete(void*) >>> referenced by keyword-list.cc >>> keyword-list.o:(copy_list(Keyword_List*)) >>> referenced by keyword-list.cc >>> keyword-list.o:(delete_list(Keyword_List*)) >>> referenced by input.cc >>> input.o:(Input::read_input()) >>> referenced 17 more times ld: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info >>> referenced by output.cc >>> output.o:(typeinfo for Output_Defines) >>> referenced by output.cc >>> output.o:(typeinfo for Output_Enum) >>> referenced by output.cc >>> output.o:(typeinfo for Output_Expr1) >>> referenced 4 more times >>> the vtable symbol may be undefined because the class is missing its key function (see https://lld.llvm.org/missingkeyfunction) clang-15: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [Makefile:74: gperf] Error 1 make[1]: Leaving directory '/sources/gperf-3.1/src' make: *** [Makefile:34: all] Error 2
Oh, sorry, I didn't read that.
what about linking Shadow to OpenPAM
Yeah, i came across OpenPAM after discovering a blog hating on LinuxPAM. I didn't see why either.
Good to know it compiles on musl... just need to know what software is hard coded to use Linux PAM.
I've also looked into abandoning logind and dbus... For dbus, i think the alternative was dbus-broker and logind -> seatd. I use seatd. There are a few packages that are hardcoded for systemd/logind
Gperf fails to compile with the final system clang [built by stage0 clang] ... g++ is a symlink to clang-15:
I searched the error, and I found this StackOverflow question: https://stackoverflow.com/questions/27390078/gcc-compiling-c-code-undefined-reference-to-operator-newunsigned-long-lon
That gave me a clue that maybe the error is the symlink itself, take a look:
"
gccis the GCC compiler-driver for C programs,g++is the one for C++ programs.
Both will guess the language on the basis of the file-extension, unless overridden.But if you use the wrong driver, the default-options will be wrong, like leaving out the C++ standard-library for C++ programs compiled with gcc when linking."
I know this is about GCC, but the same logic applies to Clang: the clang program deals with C language files, clang++ deals with C++ language files. Maybe you need to remake the link from g++ to clang++ instead of clang-15 --- unless clang-15 have a case-switch that treats the argv[0] as an determinant to the compiler payload itself (in case, if argv[0] is equal to {g,clang}++, then compile the code as C++, if argv[0] is equal to {gcc,clang}, compile the code as standard C code, etc).
I hope this helps.
but maybe it's a question of linking?
Actually, I can't get stage1 clang to build stage2 (final system) clang... I had to use stage0 clang. It's like only stage0 clang works good while stage1 & stage2 are broken. If i try to build stage2 with stage1, stage1 cannot compile llvm-tblegen for some silly syntax error.... this issue closed by using a workaround.
Yeah, i came across OpenPAM after discovering a blog hating on LinuxPAM. I didn't see why either.
Those folks hate too much, damn it...
Free software is free software: you can use one over other only because you want to, there's no need to be hating on one or other.
Good to know it compiles on musl... just need to know what software is hard coded to use Linux PAM.
Possibly the most pre-compiled binaries for musl-based distributions link to Linux-PAM only, so we would need to recompile everything if we wanted to use "software-Χ" that links to PAM on our system.
About code itself? I don't think there's anything Linux-PAM-specific on the API, both OpenPAM and Linux-PAM seem to be compatible in this sense. I think only the configuration files aren't interchangeable. I haven't studied a lot about OpenPAM and Linux-PAM, though.
I've also looked into abandoning logind and dbus... For dbus, i think the alternative was dbus-broker and logind -> seatd. I use seatd. There are a few packages that are hardcoded for systemd/logind
Nice to know! I will take my notes for those.
but maybe it's a question of linking?
Actually, I can't get stage1 clang to build stage2 (final system) clang... I had to use stage0 clang. It's like only stage0 clang works good while stage1 & stage2 are broken. If i try to build stage2 with stage1, stage1 cannot compile llvm-tblegen for some silly syntax error.... this issue closed by using a workaround.
Modern compilers are weird, really.
I know this is about GCC, but the same logic applies to Clang: the clang program deals with C language files,
Actually clang is a link to clang-15 and clang++ is a link to clang-15 ... clang-15 is the real binary. Its annoying as if i create a cfg file (like the spec file in gcc) to configure clang, it applies to BOTH clang & clang++
I know this is about GCC, but the same logic applies to Clang: the clang program deals with C language files,
Actually
clangis a link toclang-15andclang++is a link toclang-15...clang-15is the real binary. Its annoying as if i create a cfg file (like the spec file in gcc) to configure clang, it applies to BOTH clang & clang++
So my argv[0] hypothesis applies? Cool, I haven't even looked at the code yet.
Unfortunately, it seems like the final system Clang is indeed broken, but we don't seem to know why it is broken yet.
It can't be impossible to build a musl C library-based Linux system with Clang, Chimera Linux does it just fine.
Maybe we could take a look at how its toolchain is built?
it seems like the final system Clang is indeed broken
It really pissed me off when i saw the error. Took me forever to get stage0 clang to compile w/o errors. And even more to build stage1. I know OpenMandriva uses clang as a primary compiler...[or am i reading their git repos wrong?] Hard to tell as their build recipes are terrible to read.
It can't be impossible to build a musl C library-based Linux system with Clang
I keep searching and it seems no one wants a build a system without GCC. I suppose the excuse is that LLVM's libc++ is not complete like GNU's libstdc++.
My main reason I decided to design CMLFS was that libc++ had similar goals like of musl: "Correctness as defined by the C++11 standard." ... no shortcuts or hacks like in glibc or libstdc++ or GCC [i.e. gcc extensions]
I might create another branch with a different design for CMLFS: make the system toolchain removeable.
Maybe stage0 should be the system compiler and then it can be mounted/unpacked whenever a package needs to be built. I pretty much do that for my chromebook: My desktop builds packages that i install on my chrombeook as it has less compute power than my desktop. If i need, say, firefox, I have the desktop build it and then i install it to my chromebook. Saves my chromebook from heat and stress so it can continue to have good battery life.
Chimera Linux does it just fine.
Maybe we could take a look at how its toolchain is built?
Good lead. I'll check that.
@takusuman, have you found an alternative for udisks? I can never figure out why udisksctl segfaults on some system builds and not on others. I use it to safely unplug USB storage devices by powering device off first.
it seems like the final system Clang is indeed broken
It really pissed me off when i saw the error. Took me forever to get stage0 clang to compile w/o errors. And even more to build stage1. I know OpenMandriva uses clang as a primary compiler...[or am i reading their git repos wrong?] Hard to tell as their build recipes are terrible to read.
Doesn't they use .spec-like recipes? I was reading some CentOS ones to fix bugs at Copacabana (although it's two pretty different distributions) and they were pretty readable to me.
I might create another branch with a different design for CMLFS: make the system toolchain removeable.
Maybe stage0 should be the system compiler and then it can be mounted/unpacked whenever a package needs to be built. I pretty much do that for my chromebook: My desktop builds packages that i install on my chrombeook as it has less compute power than my desktop. If i need, say, firefox, I have the desktop build it and then i install it to my chromebook. Saves my chromebook from heat and stress so it can continue to have good battery life.
I was doing something alike on Copacabana using pkgmap.txt files, which are just find . of the installed package itself. I've also separated the system between development and base system "stages", maybe this scheme could help.
@takusuman, have you found an alternative for udisks? I can never figure out why udisksctl segfaults on some system builds and not on others. I use it to safely unplug USB storage devices by powering device off first.
I haven't searched yet, but I'll be doing it.
If I find something promising, I'll come here and tell in an Issue for enhancement. Maybe FreeBSD got an alternative and we could try to port it?
I'll come here and tell in an Issue for enhancement.
Oh, no need to. I've found something called "Udevil", may it works.
https://ignorantguru.github.io/udevil/
I haven't tested it yet, though.
Coreutils [when compiled with stage2/final-system clang]:
make[2]: Entering directory '/sources/coreutils-9.1'
CCLD src/chroot
ld: error: undefined symbol: error
>>> referenced by chroot.c:361 (/sources/coreutils-9.1/src/chroot.c:361)
>>> src/chroot.o:(main)
>>> referenced by chroot.c:430 (/sources/coreutils-9.1/src/chroot.c:430)
>>> src/chroot.o:(main)
>>> referenced by chroot.c:279 (/sources/coreutils-9.1/src/chroot.c:279)
>>> src/chroot.o:(main)
>>> referenced 9 more times
>>> did you mean: ferror
>>> defined in: /usr/bin/../lib/libc.so
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:10367: src/chroot] Error 1
make[2]: Leaving directory '/sources/coreutils-9.1'
make[1]: *** [Makefile:21011: all-recursive] Error 1
make[1]: Leaving directory '/sources/coreutils-9.1'
make: *** [Makefile:8269: all] Error 2
Same error with stage0 clang
Coreutils [when compiled with stage2/final-system clang]:
make[2]: Entering directory '/sources/coreutils-9.1' CCLD src/chroot ld: error: undefined symbol: error >>> referenced by chroot.c:361 (/sources/coreutils-9.1/src/chroot.c:361) >>> src/chroot.o:(main) >>> referenced by chroot.c:430 (/sources/coreutils-9.1/src/chroot.c:430) >>> src/chroot.o:(main) >>> referenced by chroot.c:279 (/sources/coreutils-9.1/src/chroot.c:279) >>> src/chroot.o:(main) >>> referenced 9 more times >>> did you mean: ferror >>> defined in: /usr/bin/../lib/libc.so clang-15: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [Makefile:10367: src/chroot] Error 1 make[2]: Leaving directory '/sources/coreutils-9.1' make[1]: *** [Makefile:21011: all-recursive] Error 1 make[1]: Leaving directory '/sources/coreutils-9.1' make: *** [Makefile:8269: all] Error 2Same error with stage0 clang
That's caused because musl doesn't have error() --- and, for some reason, it seems like the error() function provided by Void Linux's compatibility headers is broken. The fix is to use a cache variable, ac_cv_lib_error_at_line defined as "no" when running configure.
That's caused because musl doesn't have error() --- and, for some reason, it seems like the error() function provided by Void Linux's compatibility headers is broken. The fix is to use a cache variable, ac_cv_lib_error_at_line defined as "no" when running configure.
YES! I can cross off coreutils!
YES!
The reaction that I had at first. 😄
If you want to say in the documentation, there is a clever (if I do say so myself) explanation to it:
After you install Void Linux's compatibility headers, you will have, in fact, an error() and error_at_line() function declarations at /usr/include/error.h, so when you run ./configure on any program that uses error() and/or error_at_line(), ./configure will identify that error()/error_at_line() are present on the system, so it will not use Gnulib's.
The program itself will compile just fine, because the C preprocessor had found a declaration of these functions, so there's nothing to worry. The error itself will come when linking, because the symbols for those functions don't exist at libc.so.
A way to fix it would be to include these functions directly at musl-libc via a patch, having the declaration of the functions at error.h and the code definition for them on a C file that will be compiled to an object, but that would break the principle of being a "correctness as in POSIX standards C library", since error.h is a GNU C library extension.
I haven't written about this anywhere before, not even at Copacabana's documentation --- and I haven't found an explanation for this at void-packages commits too --- so that's the first time someone explained this detailed on the Internet, I think.
After you install Void Linux's compatibility headers
Actually, I took you up on that offer from some time ago...and now i'm using those headers from https://github.com/Projeto-Pindorama/musl-compat ... it'll be easier to track any future changes. Its also on my to-do list for my other repos
After you install Void Linux's compatibility headers
Actually, I took you up on that offer from some time ago...and now i'm using those headers from https://github.com/Projeto-Pindorama/musl-compat ... it'll be easier to track any future changes. Its also on my to-do list for my other repos
Yeah, but those were derived from Void Linux ones. I have to rework on it, since a Makefile would be a lot more practical than a Korn/GNU Shell script for installing.
Glad that Musl-LFS/CMLFS is using it, though. 😄
Now that I think of it... i only used error.h to build libelf from elfutils.
I would simply copy the error.h to the elfutils source then compile and install libelf. Error.h never got installed.
I suppose installing error.h should be optional
Now that I think of it... i only used
error.hto build libelf from elfutils.I would simply copy the error.h to the elfutils source then compile and install libelf. Error.h never got installed.
I suppose installing error.h should be optional
Yeah, that's a good fix too.
groff fails to configure:
checking that C++ compiler can compile simple program... yes
checking that C++ static constructors and destructors are called... no
configure: error: a working C++ compiler is required
Check the config.log:
configure:18353: checking that C++ static constructors and destructors are called
configure:18385: clang++ -o conftest -g -O2 conftest.cpp >&5
ld: error: undefined symbol: __cxa_begin_catch
>>> referenced by conftest.cpp
>>> /tmp/conftest-0962e0.o:(__clang_call_terminate)
ld: error: undefined symbol: std::terminate()
>>> referenced by conftest.cpp
>>> /tmp/conftest-0962e0.o:(__clang_call_terminate)
ld: error: undefined symbol: __gxx_personality_v0
>>> referenced by conftest.cpp
>>> /tmp/conftest-0962e0.o:(DW.ref.__gxx_personality_v0)
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
But stage0 clang configures groff fine.
groff fails to configure:
[...]
But stage0 clang configures groff fine.
That's the same error that happened before, see:
# [...]
ld: error: undefined symbol: __cxa_begin_catch
# [...]
ld: error: undefined symbol: std::terminate()
# [...]
ld: error: undefined symbol: __gxx_personality_v0
# [...]Indeed, the error is in the compiler and/or (yes, maybe simultaneously) in the C++ standard library, that defines these symbols --- maybe I'm mistaken, but C++ is basically, talking in a superficial manner, C with some symbols and data structures/types more, at least in the original definition.
@dslm4515 Have you seen the path where libraries are installed? I've searched a little bit more today, and I found this question at StackOverflow, the problem described looks like a lot one of the "undefined symbol" errors that you had.
He/she said that the problem was fixed by inserting the path where the C++ standard library was installed --- in the case, since his/her machine was running MacOS, it was /usr/lib, where the default system libraries are installed, like in any UNIX-compatible system --- so the linker could, finally, find the symbol definition.
If I were you, I would try to install LLVM (using a DESTDIR-like definition before gmake install) to a custom directory, and then see where the libraries are in fact installed with the current configuration (find is your best friend, try find . -type f -name "*.so*"). Maybe you've been misconfiguring it (by copying the same configuration that you've used at stage0 LLVM) all this time. That could be the only explanation (I think) of why stage0 LLVM works just fine while stage2 and stage3 struggle.
I also need to develop more tests to confirm the compiler works before finishing half the final system packages to realized its broken.
I can't find any runtime configuration for LLD.... is it because clang configures LLD at runtime?
I scrapped my build and started over, using Chimera Linux's cports as a guide
I scrapped my build and started over, using Chimera Linux's cports as a guide
Great! I hope it works.
I can't go back to develop CMLFS right now because I'm working at Copacabana's build consolidation, but maybe I'll be moving it to LLVM and then contributing back with patches, like I did in Musl-LFS.
Maybe you've been misconfiguring it
For my current build, i only turned off only options to get the build to go.... i didnt turn off any extra options. Takes more space, but I'll see if stage1 clang is still broken.
So in my latest developmental branch bsd-userland, I used patches from Chimera Linux and changed the clang source to set the dynamic loader at /cgnutools/lib for stage0 clang and then to /llvmtools/lib for the stage1 clang. This removed the need to set the dynamic linker via a clang cfg (it causes static binaries to segfault).
Stage0 & stage1 clangs passed my custom tests ( header search order, atomics, C++ standard support ). Stage0 clang was built to provide libc++, libunwind, and compiler-rt that stage1 clang would build with... as it's assumed host will not have libc++ or libunwind or compiler-rt. Stage0 and stage1 clangs outputs binaries with the dynamic loader at /llvmtools/lib.
When building the final system packages, stage1 clang needs to change sysroot from /llvmtools to /usr. This is done with a cfg file:
cat >> /llvmtools/bin/$(uname -m)-pc-linux-musl.cfg << EOF
-nostdinc++
-I/llvmtools/include/c++/v1
-I/usr/include/c++/v1
-I/llvmtools/include
-I/usr/include
EOF
So far system packages are compiling. I get to Python. It wont link the openSSL libraries that I installed at /opt/openssl on the final system:
*** WARNING: renaming "_ssl" since importing it failed: Error relocating /sources/Python-3.11.1/build/lib.linux-x86_64-3.11/_ssl.cpython-311-x86_64-lin
ux-musl.so: OPENSSL_sk_num: symbol not found
The necessary bits to build these optional modules were not found:
_dbm _gdbm _hashlib
_tkinter _uuid nis
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
The following modules found by detect_modules() in setup.py have not
been built, they are *disabled* by configure:
_sqlite3
Following modules built successfully but were removed because they could not be imported:
_ssl
Could not build the ssl module!
Python requires a OpenSSL 1.1.1 or newer
Custom linker flags may require --with-openssl-rpath=auto
But if I do not use the cfg... just clang/clang++ , the ssl module can be imported.
Fixed it:
echo "-L/opt/openssl/lib" >> /llvmtools/bin/$(uname -m)-pc-linux-musl.cfg
Order matters:
cat >> /llvmtools/bin/$(uname -m)-pc-linux-musl.cfg << EOF
-nostdinc++
-I/llvmtools/include/c++/v1
-I/usr/include/c++/v1
-I/llvmtools/include
-I/usr/include
-L/usr/lib
-L/opt/openssl/lib
-L/llvmtools/lib
EOF
/opt/openssl/lib has to be searched before /llvmtools/lib as llvmtools has openSSL installed [for chimerautils]
Stage2 clang (x86_64-pc-linux-musl.cfg ) fails to compile:
builtins # 166 ............. PASS
unwind # 19 ................ PASS
cxxabi # 828 ............... PASS
cxx # 89 ................... PASS
compiler-rt # 14 ........... PASS
llvm-tblgen # 242 .......... PASS
lld # 1824 ................. FAIL
First block of error:
[1705/1824] Linking CXX shared library lib/libLLVM-15.so
ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'vtable for llvm::itanium_demangle::DotSuffix'; recompile with -fPIC
>>> defined in lib/libLLVMDemangle.a(ItaniumDemangle.cpp.o)
>>> referenced by ItaniumDemangle.cpp
>>> ItaniumDemangle.cpp.o:(llvm::itanium_demangle::AbstractManglingParser<llvm::itanium_demangle::ManglingParser<(anonymous namespace)::D
efaultAllocator>, (anonymous namespace)::DefaultAllocator>::parse()) in archive lib/libLLVMDemangle.a
But to no surprise, CC=clang CXX=clang++ builds LLD without error. Same stage1 clang, just no configuration... using built-in configuration.
Could there be a problem with x86_64-pc-linux-musl.cfg ?
I adjusted the cfg more:
--sysroot=/usr
-nostdinc++
-nostdinc
-I/usr/include/c++/v1
-I/usr/include
-I/llvmtools/include/c++/v1
-I/llvmtools/include
-I/llvmtools/lib/clang/15.0.6/include
-L/usr/lib
-L/llvmtools/lib
and disabled the following compiler-rt options:
-DCOMPILER_RT_BUILD_SANITIZERS=OFF
-DCOMPILER_RT_BUILD_XRAY=OFF
-DCOMPILER_RT_BUILD_LIBFUZZER=OFF
But build still fails:
builtins # 166 ............. PASS
unwind # 19 ................ PASS
cxxabi # 828 ............... PASS
cxx # 89 ................... PASS
compiler-rt # 149 .......... PASS
llvm-tblgen # 242 .......... PASS
lld # 1824 ................. PASS
libclang # 798 ............. PASS
clang # 336 ................ PASS
remaining targets # 693 .... FAIL:
[20/678] Building CXX object tools/sancov/CMakeFiles/sancov.dir/sancov.cpp.o
ninja: job failed: /llvmtools/bin/x86_64-pc-linux-musl-clang++ -DHAVE_POSIX_REGEX -DHAVE_STD_REGEX -DHAVE_STEADY_CLOCK -D__STDC_CONSTANT_MACROS -D__STD
C_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/sources/llvm-project-15.0.6.src/build/third-party/benchmark/src -I/sources/llvm-project-15.0.6.src/third-party
/benchmark/src -I/sources/llvm-project-15.0.6.src/build/include -I/sources/llvm-project-15.0.6.src/llvm/include -I/sources/llvm-project-15.0.6.src/thir
d-party/benchmark/include -fPIC -stdlib=libc++ -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-fi
eld-initializers -pedantic -Wno-long-long -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -fdiagnostics-color -std=
c++11 -Wall -Wextra -Wshadow -Wsuggest-override -pedantic -pedantic-errors -Wshorten-64-to-32 -fstrict-aliasing -Wno-deprecated-declarations
-fno-exceptions -Wstrict-aliasing -Wthread-safety -O3 -DNDEBUG -std=c++14 -MD -MT third-party/benchmark/src/CMakeFiles/benchmark.dir/timers.cc.o -MF
third-party/benchmark/src/CMakeFiles/benchmark.dir/timers.cc.o.d -o third-party/benchmark/src/CMakeFiles/benchmark.dir/timers.cc.o -c /sources/llvm-pro
ject-15.0.6.src/third-party/benchmark/src/timers.cc
clang-15: warning: argument unused during compilation: '-stdlib=libc++' [-Wunused-command-line-argument]
In file included from /sources/llvm-project-15.0.6.src/third-party/benchmark/src/timers.cc:25:
/usr/include/fcntl.h:170:16: error: flexible array members are a C99 feature [-Werror,-Wc99-extensions]
unsigned char f_handle[];
^