x86_64-gentoo-linux-musl-gcc -O2 -pipe -march=native -fno-strict-aliasing -fwrapv -fPIC -c fpoll.c fpoll.c: In function fpoll: fpoll.c:70:9: error: dereferencing pointer to incomplete type FILE {aka struct _IO_FILE} 70 | if (f->_cnt > 0) | ^~ make[3]: *** [Makefile:15: fpoll.o] Error 1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl-20200328-141627 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-gentoo-linux-musl-9.3.0 * clang version 10.0.0 Target: x86_64-gentoo-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.7 [3] python3.6 [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-1.42.0 * The following VMs are available for generation-2: timestamp of HEAD at this tinderbox image: /var/db/repos/gentoo Sat Apr 4 17:07:58 UTC 2020 /var/db/repos/musl Sat Apr 4 03:02:24 UTC 2020 emerge -qpvO dev-lang/icon [ebuild N ] dev-lang/icon-9.5.1-r2 USE="-X -iplsrc"
Created attachment 630068 [details] emerge-info.txt
Created attachment 630070 [details] dev-lang:icon-9.5.1-r2:20200404-173717.log
Created attachment 630072 [details] emerge-history.txt
Created attachment 630074 [details] environment
Created attachment 630076 [details] etc.portage.tbz2
Created attachment 630078 [details] temp.tbz2
I will need to discuss this problem with upstream owner of Icon to see if we can come up with a solution. Question. Is there a way to detect if the sys-libs/musl library is being used? The code that is failing is sensitive to the internal layout of the FILE structure, so there is a possibility that the particular function may not be supported with building with sys-libs/musl. One possible solution which would be Gentoo specific patch where a build time flag is defined. I think I see what needs to be done within the code to handle musl's implementation of FILE, it's just figuring out how to detect that musl is being used. The function (fpoll) is part of the Icon Program Library and can be viewed as an optional function (i.e. it's not part of the core language), so the other alternative is to detect the use of sys-libs/musl and just skip building that one function.
(In reply to Cheyenne Wills from comment #7) > I will need to discuss this problem with upstream owner of Icon to see if we > can come up with a solution. > > Question. Is there a way to detect if the sys-libs/musl library is being > used? > > The code that is failing is sensitive to the internal layout of the FILE > structure, so there is a possibility that the particular function may not be > supported with building with sys-libs/musl. > > One possible solution which would be Gentoo specific patch where a build > time flag is defined. I think I see what needs to be done within the code > to handle musl's implementation of FILE, it's just figuring out how to > detect that musl is being used. > > > The function (fpoll) is part of the Icon Program Library and can be viewed > as an optional function (i.e. it's not part of the core language), so the > other alternative is to detect the use of sys-libs/musl and just skip > building that one function. The musl developers have an objection on principle to a macro specifically for musl: https://wiki.musl-libc.org/faq.html#Q:_Why_is_there_no_%3Ccode%3E__MUSL__%3C/code%3E_macro? So, the usual approach is to look specifically whether or not the feature/macro/whatever you need exists. Sometimes it does exist in Musl but in a different header, and sometimes not at all - here you will need to either disable the functionality or copy in the relevant parts yourself, or make use of some of the 'standalone' libraries that we've got in Gentoo for these situations: https://wiki.gentoo.org/wiki/User:Sam_c/Musl_porting_notes#Standalone_packages Hope that helps a bit. I haven't investigated FILE here though so maybe there is something obvious I haven't commented on.
(In reply to Sam James (sec padawan) from comment #8) > The musl developers have an objection on principle to a macro specifically > for musl: > https://wiki.musl-libc.org/faq.html#Q:_Why_is_there_no_%3Ccode%3E__MUSL__%3C/ > code%3E_macro? Yeah.. I saw that... > > So, the usual approach is to look specifically whether or not the > feature/macro/whatever > you need exists. Sometimes it does exist in Musl but in a different header, > and sometimes not at all - here you will need to either disable the > functionality or copy in the relevant parts yourself, or make use of some of > the 'standalone' libraries that we've got in Gentoo for these situations: > > https://wiki.gentoo.org/wiki/User:Sam_c/ > Musl_porting_notes#Standalone_packages > > Hope that helps a bit. I haven't investigated FILE here though so maybe > there is something > obvious I haven't commented on. The problem isn't a missing macro. The code is looking at some members within the FILE structure itself (which I guess is technically a "no-no") to determine if there is data "waiting". Probably the best bet is for a Gentoo specific patch and update the ebuild to pass a build parameter that can be tested. I'll try to work on it this weekend
I have a possible update, but it needs to be tested with a system where sys-libs/musl is installed. (which I currently don't have). The update is currently in my github clone of the gentoo repo. I'm just wondering how I should proceed. Thanks.
(In reply to Cheyenne Wills from comment #10) > I have a possible update, but it needs to be tested with a system where > sys-libs/musl is installed. (which I currently don't have). > > The update is currently in my github clone of the gentoo repo. I'm just > wondering > how I should proceed. > > Thanks. If you don't mind sharing the URL, I'm happy to do some testing on my systems.
(In reply to Michael 'veremitz' Everitt from comment #11) > (In reply to Cheyenne Wills from comment #10) > > I have a possible update, but it needs to be tested with a system where > > sys-libs/musl is installed. (which I currently don't have). > > > > The update is currently in my github clone of the gentoo repo. I'm just > > wondering > > how I should proceed. > > > > Thanks. > > If you don't mind sharing the URL, I'm happy to do some testing on my > systems. Thanks for the offer. With the help from some folks on IRC I was able to set up a chroot with the musl stage3 and was able to test the fix. I've created the pull request (that is now referenced in the ticket). Turned out that the way musl works, the internals of the FILE structure are "hidden", however there is a function (__freadahead) that musl makes available that performs the check that was needed. PS.. sorry about the couple of misfired commits in the PR. I needed to gpg sign the commit and then I needed to add additional fields to the commit message. The pull request contains an additional update to the ebuild that fixes a problem where the CFLAGS set by the ebuild were not being used by the actual build (thus the -r3 on the ebuild).
Also cleaned up whitespace/indentation
Upstream has accepted adding the test and code to support the musl library in fpoll.c. Will probably be a while before the change shows up in a published release so the patch file will be needed until then.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee19109f17c12e97eea26c8506538eb246de32ee commit ee19109f17c12e97eea26c8506538eb246de32ee Author: Cheyenne Wills <cwills@witznd.net> AuthorDate: 2020-05-18 04:48:10 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-06-04 13:34:37 +0000 dev-lang/icon: fix for building with sys-libs/musl The Icon Programming Library function fpoll.c fails to build when the sys-libs/musl is being used. fpoll.c is sensitive to the internal layout of the FILE structure. Patch fpoll.c so it will build when sys-libs/musl is used. Since the musl library does not provide a way to detect that the musl library is being used. Update the ebuild to update CFLAGS to include a define that indicates musl is being used. In addition, CFLAGS were being overridden within the build process. Update the ebuild to ensure that the ebuild's CFLAGS are used. Closes: https://bugs.gentoo.org/716212 Signed-off-by: Cheyenne Wills <cwills@witznd.net> Signed-off-by: Joonas Niilola <juippis@gentoo.org> dev-lang/icon/files/icon-9.5.1-musl.patch | 24 ++++++++++++++++++++++++ dev-lang/icon/icon-9.5.1-r2.ebuild | 12 +++++++++++- 2 files changed, 35 insertions(+), 1 deletion(-)
