Created attachment 442024 [details, diff] Patch to libieee1284-0.2.11-r3.ebuild When building sys-libs/libieee1284 on musl libc with the current ebuild: ./.libs/libieee1284.so: undefined reference to `outb_p' collect2: error: ld returned 1 exit status Makefile:546: recipe for target 'libieee1284_test' failed make: *** [libieee1284_test] Error 1 * ERROR: sys-libs/libieee1284-0.2.11-r3::gentoo failed (compile phase): * emake failed This is because musl's sys/io.h does not define outb_p, only outb, as outb_p was deprecated some number of years ago. Passing "ac_cv_header_sys_io_h=no" to ./configure allows the build to proceed using a package-provided version of the function. Attached patch to ebuild tested working for me on musl x86 and amd64, and glibc amd64.
(In reply to A. Wilcox (awilfox) from comment #0) > Created attachment 442024 [details, diff] [details, diff] > Patch to libieee1284-0.2.11-r3.ebuild > > When building sys-libs/libieee1284 on musl libc with the current ebuild: > > ./.libs/libieee1284.so: undefined reference to `outb_p' > collect2: error: ld returned 1 exit status > Makefile:546: recipe for target 'libieee1284_test' failed > make: *** [libieee1284_test] Error 1 > * ERROR: sys-libs/libieee1284-0.2.11-r3::gentoo failed (compile phase): > * emake failed > > This is because musl's sys/io.h does not define outb_p, only outb, as outb_p > was deprecated some number of years ago. Passing "ac_cv_header_sys_io_h=no" > to ./configure allows the build to proceed using a package-provided version > of the function. > > Attached patch to ebuild tested working for me on musl x86 and amd64, and > glibc amd64. You don't want to "pass" ac_cv_header_sys_io_h=no to ./configure. Its not a switch that you pass, like --without-python or something. Rather it should go into the environment of ./configure, so you need something like use elibc_musl && export ac_cv_header_sys_io_h=no It "works" the way you did it, but adding it to myconf makes it look like a switch and its stylistically bad. Do you mind testing to see if the above line works and I'll commit it like that (to save you from reproducing a patch). @base-system: should be safe enough, may I commit with the above fix.
(In reply to Anthony Basile from comment #1) configure scripts accept env vars on the command line. that way they can be passed when re-running configure automatically (like when automake detects files are out of date and need to re-run autotools). that said, i don't see why this test needs to be forced. it's a header test for sys/io.h. if musl didn't provide that, then configure shouldn't have detected it in the first place.
(In reply to SpanKY from comment #2) > (In reply to Anthony Basile from comment #1) > > configure scripts accept env vars on the command line. that way they can be > passed when re-running configure automatically (like when automake detects > files are out of date and need to re-run autotools). i've never seen that before, so thanks for the info. i can see how its useful. > > that said, i don't see why this test needs to be forced. it's a header test > for sys/io.h. if musl didn't provide that, then configure shouldn't have > detected it in the first place. i'll try to take a look at what's going on tomorrow.
(Quoting A. Wilcox (awilfox) from comment #0) > This is because musl's sys/io.h does not define outb_p, only outb, as outb_p > was deprecated some number of years ago. Passing "ac_cv_header_sys_io_h=no" > to ./configure allows the build to proceed using a package-provided version > of the function. This is why the test must be forced; libieee1284 blindly assumes outb_p exists in sys/io.h but only outb does in musl.
looks like musl is OK with adding the _p variants: http://www.openwall.com/lists/musl/2015/11/10/1 so should go that route i think. sys/io.h is a mess of non-standard, so if musl is going to support it, should include the "full" api imo.
