Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 560826 - sys-libs/libcxx fails to build under musl
Summary: sys-libs/libcxx fails to build under musl
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo musl team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: musl-porting
  Show dependency tree
 
Reported: 2015-09-19 09:07 UTC by toast+misc
Modified: 2017-05-09 15:01 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Fix LibC++ Under Musl (0001-Fix-LibC-Under-Musl.patch,14.91 KB, patch)
2015-09-19 09:07 UTC, toast+misc
Details | Diff
build log (includes test phase) (build.log,512.13 KB, application/octet-stream)
2015-09-21 16:36 UTC, toast+misc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description toast+misc 2015-09-19 09:07:35 UTC
Created attachment 412254 [details, diff]
Fix LibC++ Under Musl

Musl does not define locale-specific functions (e.g strtoll_l), as it only supports one locale.
According to an openwall thread , it is safe to use non _l functions instead of those.

Moreover, libc++ checks against GLIBC versions for important functionality.

This patch fixes the first issue and imports changes from vvavrychuk's patch for 3.4.2 (link at bottom) to fix runtime issues (classic_table() not implemented).

Patch made against musl tree, resulting ebuild passes most tests (passes 4669/4925 (256 failed), 1074/1174 categories without failures (87 with, 13 not tested)) and appears to be functional (basic functionality is definitely present).

TODO: consider potential implications of some of the changes on LIBCs that do not define things the same way as musl, but are not musl, and not compliant.
Comment 1 Alexis Ballier gentoo-dev 2015-09-21 07:41:08 UTC
your attached patch is weird, but could you please try to work on musl support with upstream ? it'd be a lot much easier and saner for me to backport a fix from upstream
Comment 2 toast+misc 2015-09-21 08:15:00 UTC
This is a patch against the musl overlay, mostly waiting for blueness to notice this (I can't change the assignee).
Comment 3 Anthony Basile gentoo-dev 2015-09-21 08:49:52 UTC
(In reply to Chloe Kudryavtsev from comment #2)
> This is a patch against the musl overlay, mostly waiting for blueness to
> notice this (I can't change the assignee).

I think you can add me to the cc list when opening such bugs.

I've applied the patch to the musl overlay.  Can you try to get it upstream.  I'm not sure how it will be received given that you remove the __GLIBC_PREREQ stuff, but let's see.
Comment 4 Felix Janda 2015-09-21 12:41:26 UTC
I think that some people on musl@lists.openwall.com would be interested
in seeing the test failures and might be able to give some guidance on
how to improve the patch.
Comment 5 toast+misc 2015-09-21 16:36:53 UTC
Created attachment 412470 [details]
build log (includes test phase)

(In reply to Anthony Basile from comment #3)
> (In reply to Chloe Kudryavtsev from comment #2)
> > This is a patch against the musl overlay, mostly waiting for blueness to
> > notice this (I can't change the assignee).
> 
> I think you can add me to the cc list when opening such bugs.
> 
> I've applied the patch to the musl overlay.  Can you try to get it upstream.
> I'm not sure how it will be received given that you remove the
> __GLIBC_PREREQ stuff, but let's see.

I'll contact upstream and try to work with them on what the "proper" solution would be. After all, they're an alternate libc++, they should understand musl's point of view. Made easier by the fact that it seems to work for what I used it for.

(In reply to Felix Janda from comment #4)
> I think that some people on musl@lists.openwall.com would be interested
> in seeing the test failures and might be able to give some guidance on
> how to improve the patch.

I'm not part of that right now, and being rather sick I'm not sure I'll join in in the near future.
I'll upload the testing build log here in case anyone wants to go through it.
Comment 6 toast+misc 2015-09-27 02:22:11 UTC
That bug already exists here: https://llvm.org/bugs/show_bug.cgi?id=20211
Their primary problem is that different locales should be supported (which isn't a thing on musl).

It seems that we need to find a way to identify musl, or at least identify everything that isn't musl for them to be content with the solution, which is understandable.

I'll try going over everything musl defines and trying to see what other libcs (glibc, uclibc, newlib, etc) do; but it looks like this is going to have to be a patch musl projects apply.

Will think on potential other solutions.
Comment 7 Felix Janda 2015-09-29 04:22:06 UTC
(In reply to Chloe Kudryavtsev from comment #6)
> That bug already exists here: https://llvm.org/bugs/show_bug.cgi?id=20211
> Their primary problem is that different locales should be supported (which
> isn't a thing on musl).

The patch there seems less hacky than the one in this bug report.
Note that musl-1.1.11 has two locales. An utf8 locale and an abstract C locale.

> It seems that we need to find a way to identify musl, or at least identify
> everything that isn't musl for them to be content with the solution, which
> is understandable.
> 
> I'll try going over everything musl defines and trying to see what other
> libcs (glibc, uclibc, newlib, etc) do; but it looks like this is going to
> have to be a patch musl projects apply.

Please do not waste your time on this. The symbols that musl exposes might change over time. It might also support the *_l functions in the future.

> Will think on potential other solutions.

It should for example be easy to use a configure test to check for the non-standard *_l functions. Maybe it is also possible to test for the other features (and simplify the ifdef mess).

If you don't want to join the musl list, you can also ask the devs on #musl at freenode.
Comment 8 Felix Janda 2016-01-20 15:02:31 UTC
musl support seems to have landed upstream. For this, it will be
necessary to pass "-DLIBCXX_HAS_MUSL_LIBC" to cmake. See
https://llvm.org/bugs/show_bug.cgi?id=20211#c7
Comment 9 toast+misc 2016-01-20 15:19:55 UTC
This seems like a perfect use case for USE elibc_musl (ala line 132 of sys-libs/libcxx-3.7.0's ebuild). Is it defined as of now, however? Couldn't find references to it in my make.defaults.
Comment 10 Felix Janda 2016-07-26 05:59:24 UTC
This bug is now a subset of bug 589352.

https://github.com/gentoo/gentoo/pull/1930

contains a libcxx ebuild working with musl.