|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>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||430702, 546890, 559518|
build log of =libetonyek-0.1.3
output of emerge --info
Description tt_1 2015-09-03 12:09:09 UTC
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?
Comment 2 Felix Janda 2015-09-03 18:05:55 UTC
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.)
Comment 3 tt_1 2015-09-03 18:48:41 UTC
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?
Comment 4 Felix Janda 2015-09-03 19:07:13 UTC
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.
Comment 5 Anthony Basile 2015-09-03 20:29:08 UTC
(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?
Comment 6 Felix Janda 2015-09-03 21:12:03 UTC
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.
Comment 7 Anthony Basile 2015-09-06 22:38:23 UTC
(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.
Comment 8 tt_1 2015-09-07 07:52:34 UTC
I just found out that the patch is not needed on x86, as libetonyek compiles fine.
Comment 9 tt_1 2015-10-25 14:44:27 UTC
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?
Comment 10 Felix Janda 2015-10-25 18:59:05 UTC
@tt_1: Yes, that's right. So this bug can probably be closed.