Comments (14)
takusuman
commented on June 12, 2024
1
May we should make LLVM developers aware of this?
I think this may be a LLVM bug, not our fault.
from cmlfs.
dslm4515
commented on June 12, 2024
If libc++ does not have localization, then ncurses built in llvmtools, fails to build:
In file included from ../c++/cursesmain.cc:50:
/mnt/cmlfs/cgnutools/bin/../include/c++/v1/locale.h:39:5: error: "<locale.h> is not supported since libc++ has been configured without support for localization."
# error "<locale.h> is not supported since libc++ has been configured without support for localization."
^
1 error generated.
make[1]: *** [Makefile:454: ../obj_s/cursesmain.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/mnt/cmlfs/sources/ncurses-6.3/c++'
make: *** [Makefile:140: all] Error 2
from cmlfs.
dslm4515
commented on June 12, 2024
ncurses now compiles if --without-cxx is added to configure.
Let's see if this feature will be required elsewhere.
from cmlfs.
dslm4515
commented on June 12, 2024
Out of curiosity, I tried to compile libc++ under a glibc host: same error as when compiling libc++ with Alpine Linux's patch and under a musl host:
/mnt/cmlfs/sources/llvm-project-15.0.5.src/build/include/c++/v1/__locale:545:3: error: #error unknown rune table for this platform -- do you mean to de
fine _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE?
545 | # error unknown rune table for this platform -- do you mean to define _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE?
| ^~~~~
So Alpine's patch for libc++ works, just another issue with libc++-15.0.5
from cmlfs.
dslm4515
commented on June 12, 2024
Arch Linux has libc++ at version 14.0.6 ... there might be a reason why Arch has not upgraded to 15.x.x yet.
OpenMandriva has libc++ at 15.0.6 .... but i dont see any patches. The build recipe is an eyesore to read.
from cmlfs.
dslm4515
commented on June 12, 2024
@takusuman Looks like someone may have reported it:
llvm/llvm-project#59540
No solution posted
from cmlfs.
dslm4515
commented on June 12, 2024
If these options are disabled:
-DLIBCXX_ENABLE_FILESYSTEM=OFF
-DLIBCXX_ENABLE_LOCALIZATION=OFF
Then libc++ builds fine... without any patches. There are no errors for error unknown rune table for this platform
This applies to 14.0.6, 15.0.5, and 15.0.6
from cmlfs.
dslm4515
commented on June 12, 2024
If I enable localization of libc++, this error comes up:
In file included from /mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__locale:44:
/mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__support/musl/xlocale.h:28:68: error: 'abi_tag' attribute applied to extern "C" declaration 'long long int strtoll_l(const char*, char**, int, locale_t)'
28 | strtoll_l(const char *__nptr, char **__endptr, int __base, locale_t) {
| ^
/mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__support/musl/xlocale.h:33:69: error: 'abi_tag' attribute applied to extern "C" declaration 'long long unsigned int strtoull_l(const char*, char**, int, locale_t)'
33 | strtoull_l(const char *__nptr, char **__endptr, int __base, locale_t) {
| ^
/mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__support/musl/xlocale.h:38:74: error: 'abi_tag' attribute applied to extern "C" declaration 'long long int wcstoll_l(const wchar_t*, wchar_t**, int, locale_t)'
38 | wcstoll_l(const wchar_t *__nptr, wchar_t **__endptr, int __base, locale_t) {
| ^
/mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__support/musl/xlocale.h:43:75: error: 'abi_tag' attribute applied to extern "C" declaration 'long long int wcstoull_l(const wchar_t*, wchar_t**, int, locale_t)'
43 | wcstoull_l(const wchar_t *__nptr, wchar_t **__endptr, int __base, locale_t) {
| ^
/mnt/cmlfs/sources/llvm-rl/build/include/c++/v1/__support/musl/xlocale.h:48:62: error: 'abi_tag' attribute applied to extern "C" declaration 'long double wcstold_l(const wchar_t*, wchar_t**, locale_t)'
48 | wcstold_l(const wchar_t *__nptr, wchar_t **__endptr, locale_t) {
| ^
ninja: build stopped: subcommand failed.
If i manually edit ` build/include/c++/v1/__support/musl/xlocale.h' [in the build directory] and comment the following:
#ifndef _LIBCPP_SUPPORT_MUSL_XLOCALE_H
#define _LIBCPP_SUPPORT_MUSL_XLOCALE_H
#include <cstdlib>
#include <cwchar>
#ifdef __cplusplus
extern "C" {
#endif
//inline _LIBCPP_HIDE_FROM_ABI long long
//strtoll_l(const char *__nptr, char **__endptr, int __base, locale_t) {
// return ::strtoll(__nptr, __endptr, __base);
//}
//inline _LIBCPP_HIDE_FROM_ABI unsigned long long
//strtoull_l(const char *__nptr, char **__endptr, int __base, locale_t) {
// return ::strtoull(__nptr, __endptr, __base);
//}
//inline _LIBCPP_HIDE_FROM_ABI long long
//wcstoll_l(const wchar_t *__nptr, wchar_t **__endptr, int __base, locale_t) {
// return ::wcstoll(__nptr, __endptr, __base);
//}
//inline _LIBCPP_HIDE_FROM_ABI long long
//wcstoull_l(const wchar_t *__nptr, wchar_t **__endptr, int __base, locale_t) {
// return ::wcstoull(__nptr, __endptr, __base);
//}
//inline _LIBCPP_HIDE_FROM_ABI long double
//wcstold_l(const wchar_t *__nptr, wchar_t **__endptr, locale_t) {
// return ::wcstold(__nptr, __endptr);
//}
#ifdef __cplusplus
then libc++ builds with out error!
The question is ... how to prevent/apply this BEFORE compiling?
from cmlfs.
dslm4515
commented on June 12, 2024
This looks like "name mangling" is in use (reference)
Perhaps cgnutools' GCC does not support 'name mangling' ?
from cmlfs.
dslm4515
commented on June 12, 2024
Issue fixed with commit c0022b0
Let's see if this will cause any issues
from cmlfs.
dslm4515
commented on June 12, 2024
For the error of 'rune table':
/mnt/cmlfs/sources/llvm-project-15.0.5.src/build/include/c++/v1/__locale:545:3: error: #error unknown rune table for this platform -- do you mean to de
fine _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE?
545 | # error unknown rune table for this platform -- do you mean to define _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE?
| ^~~~~
Perhaps, there should be a patch to use libcxx's default rune table with the Musl C library:
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151123/143770.html
from cmlfs.
dslm4515
commented on June 12, 2024
Looks like when building libcxx, the cxx headers were not configured correctly at ${BUILD}/include/x86_64-pc-linux-musl/c++/v1/__config_site :
#define _LIBCPP_ABI_VERSION 1
#define _LIBCPP_ABI_NAMESPACE __1
/* #undef _LIBCPP_ABI_FORCE_ITANIUM */
/* #undef _LIBCPP_ABI_FORCE_MICROSOFT */
/* #undef _LIBCPP_HAS_NO_THREADS */
/* #undef _LIBCPP_HAS_NO_MONOTONIC_CLOCK */
/* #undef _LIBCPP_HAS_MUSL_LIBC */
#undef _LIBCPP_HAS_MUSL_LIBC should be changed to this:
#define _LIBCPP_HAS_MUSL_LIBC
from cmlfs.
dslm4515
commented on June 12, 2024
No, looks like i forgot to set -DLIBCXX_HAS_MUSL_LIBC=ON ... setting option eliminates rune table error
from cmlfs.
dslm4515
commented on June 12, 2024
So far as of commit 5a13253 , no more localization issues so far. Patch from commit c0022b0 works for building LLVM for both cgnutools & llvmtools
from cmlfs.
Related Issues (20)
- References to `systemctl` during boot HOT 2
- utmps utmpx.h already includes utmps/utmpx.h HOT 4
- i686 (cross-compile on amd64): Python3 Build stalls under Chroot HOT 10
- Could we also have Heirloom NG as an alternative to GNU Coreutils in the future? HOT 63
- Python3 need to be rebuilt after final system clang is built HOT 8
- Clarity on CMLFS_TARGET at 1-cgnutools/4-musl HOT 2
- Compiler Warning: "-fuse-ld=' taking a path is deprecated"
- LLVM Compilation Failed HOT 1
- Unable to Compile Kernel HOT 25
- What are the packages that cannot be build without GCC? HOT 4
- Fail at Stage-0 (1-Mussel) HOT 6
- What is the state of CMLFS methods for cross-compiling? HOT 34
- Patch for musl's utmp.h is incomplete HOT 5
- OpenSSL needs certificates HOT 1
- LLVM-17.0.5: Stage 2 Clang has sysroot set as /llvmtools HOT 11
- Udev [from systemd] wont configure for final system; expects util-linux installed HOT 2
- Mention of `systemd-hwdb` when executing `udevadm` HOT 1
- Drop GNU's cpio for bsdcpio [provided by libarchive] HOT 14
- Autotools Broken -- `autoreconf` runs but exits with errors HOT 1
- Binutils: libctf fails to compile HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmlfs.