| Summary: | >app-text/libetonyek-0.1.1 fails to build with musl | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | tt_1 <herrtimson> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blueness |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702, 546890, 559518 | ||
| Attachments: |
build log of =libetonyek-0.1.3
output of emerge --info |
||
Created attachment 410916 [details]
output of emerge --info
We should add another patch to our patches against gcc. Try building gcc with the patch from https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01084.html If you don't want to wait for that, you can also try to do the changes suggested by the patch to /usr/lib/gcc/x86_64-gentoo-linux-musl/4.8.5/include/mm_malloc.h (For some reason the patch does not seem to be in current gcc git.) I edited the mm_malloc.h by hand, and libetonyek-0.1.3 compiles fine. The post says it is a very ugly hack, what do you think about it? Should I provide a patch against the musl-overlay? By the way, is there any reason for why the gcc ebuild from the musl overlay is behind the in tree version in terms of the patchset and the pie patchset? Thanks for testing! alpine seems to use the same patch: http://git.alpinelinux.org/cgit/aports/tree/main/gcc/213-posix_memalign.patch It would be great if you could post a patch adding it to the overlay. I'm don't know whether the patchset versions are behind on purpose. (In reply to tt_1 from comment #3) > I edited the mm_malloc.h by hand, and libetonyek-0.1.3 compiles fine. The > post says it is a very ugly hack, what do you think about it? Should I > provide a patch against the musl-overlay? > > By the way, is there any reason for why the gcc ebuild from the musl overlay > is behind the in tree version in terms of the patchset and the pie patchset? I'd rather an ugly hack/workaround against libetonyek than an ugly hack against gcc. Was the patch accepted upstream? Since it fixes also Bug 559518 and maybe other breakage, we should really use the patch. It doesn't really seem a hack to rename this only on x86 and amd64 exposed symbol. Upstream has been silent on the patch. I guess it should be resent. (In reply to Felix Janda from comment #6) > Since it fixes also Bug 559518 and maybe other breakage, we should > really use the patch. It doesn't really seem a hack to rename this only > on x86 and amd64 exposed symbol. > > Upstream has been silent on the patch. I guess it should be resent. i'll add it experimentally to gcc-4.8.5-r999 and KEYWORD="~amd64 ~x86". I get what the patch is doing, but I can see the consequence in terms of the namespace. The fact that its working for alpine give me some confidence. I just found out that the patch is not needed on x86, as libetonyek compiles fine. have I got it right that the proposed maloc patch from comment #2 is included into the gcc-4.9.3-r99 ebuild, which is in the musl overlay? @tt_1: Yes, that's right. So this bug can probably be closed. |
Created attachment 410914 [details] build log of =libetonyek-0.1.3 libreoffice needs it. tried all available ebuilds, only 0.1.1 is working. which is ok for right now, but still this is a problem, right?