Currently doing a manual port of musl to MIPS SGI targets by basing off of a working OpenADK root. In the process of slowly overwriting the OpenADK-build packages with Gentoo ones, I've discovered that sys-libs/pam will not build against musl because pam expects a GNU-specific function 'strdupa', that is only provided by glibc. Oddly enough, I did not encounter this error under uclibc-ng. I have patches available from a 2015 mailing list post that I'll add shortly that fix the error. Build error: /bin/sh ../../libtool --tag=CC --mode=link gcc -I/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1/libpam/include -I/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1/libpamc/include -Os -pipe -march=mips3 -mtune=mips3 -mplt -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow -no-undefined -avoid-version -module -Wl,--version-script=/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1/modules/pam_exec/../modules.map -Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -o pam_exec.la -rpath /lib/security pam_exec.lo ../../libpam/libpam.la libtool: link: gcc -shared -fPIC -DPIC .libs/pam_exec.o -Wl,-rpath -Wl,/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1-abi_mips_o32.o32/libpam/.libs -Wl,--as-needed ../../libpam/.libs/libpam.so -ldl -Os -march=mips3 -mtune=mips3 -mplt -Wl,--version-script=/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1/modules/pam_exec/../modules.map -Wl,-O1 -Wl,--no-undefined -Wl,-O1 -Wl,-soname -Wl,pam_exec.so -o .libs/pam_exec.so /usr/bin/ld: .libs/pam_exec.o: in function `call_exec.part.1': pam_exec.c:(.text+0x39c): undefined reference to `strndupa' /usr/bin/ld: pam_exec.c:(.text+0x418): undefined reference to `strndupa' /usr/bin/ld: pam_exec.c:(.text+0x41c): undefined reference to `strndupa' /usr/bin/ld: pam_exec.c:(.text+0x478): undefined reference to `strndupa' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:661: pam_exec.la] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1-abi_mips_o32.o32/modules/pam_exec' make[2]: *** [Makefile:434: all-recursive] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1-abi_mips_o32.o32/modules' make[1]: *** [Makefile:482: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-libs/pam-1.3.1-r1/work/linux-pam-1.3.1-abi_mips_o32.o32' make: *** [Makefile:414: all] Error 2 * ERROR: sys-libs/pam-1.3.1-r1::gentoo failed (compile phase): * emake failed
Created attachment 578474 [details, diff] Adds a local implementation of 'strdupa' to linux-pam From: https://patchwork.openembedded.org/patch/109369/ This patch adds a local implementation of 'strdupa' to linux-pam, as sys-libs/musl does not have such a function defined (it's a glibc-specific extension).
Created attachment 578476 [details, diff] Defines _PATH_LASTLOG and adds 'logwtmp' From: https://patchwork.openembedded.org/patch/109369/ This patches appears to do three things at once: - Fixes the undefined reference to _PATH_LASTLOG by including <paths.h>. - Fixes undefined symbol 'logwtmp' by adding a local implementation. - Prevents the 'pam_rootok' module from being built (I think).
Both of the above patches were compile-tested on a mips-unknown-linux-musl big-endian target, o32 ABI, MIPS-III ISA. This allowed sys-apps/shadow to be built as well. I hope to actually have runtime testing when I attempt a catalyst build at some point, using my chroot as a seed stage.
Created attachment 578478 [details, diff] ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl Patch to the ebuild for building sys-libs/pam on a musl system. Note that I am uncertain if the patches are the //right way// to do things. But it's the only patch I've found thus far that at least lets me progress further in building out a Gentoo chroot on my MIPS SGI system.
(In reply to Joshua Kinard from comment #4) > Created attachment 578478 [details, diff] [details, diff] > ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl > > Patch to the ebuild for building sys-libs/pam on a musl system. Note that I > am uncertain if the patches are the //right way// to do things. But it's > the only patch I've found thus far that at least lets me progress further in > building out a Gentoo chroot on my MIPS SGI system. You should have started your work from musl overlay, IMO.
Created attachment 578482 [details, diff] fix pam_exec will attach the three patches we currently use in musl overlay.
Created attachment 578484 [details, diff] sys/resources.h inclusion for RLIMIT_NOFILE
Created attachment 578486 [details, diff] add portability for non glibc systems
Joshua please test the last three patches and see if you have success as well please.
(In reply to Jory A. Pratt from comment #5) > You should have started your work from musl overlay, IMO. Oops, didn't know that existed. Where is it located? Actually discovered the first patch shortly after filing the bug and was going to test it, but I'll test all three shortly and report back.
https://gitweb.gentoo.org/proj/musl.git/
(In reply to Jory A. Pratt from comment #9) > Joshua please test the last three patches and see if you have success as > well please. Yup, those three also work. Compile tested/merged, and link-tested by re-merging sys-apps/shadow afterwards. I'll obsolete the earlier patches I attached and upload a newer ebuild patch.
Created attachment 578502 [details, diff] ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl Updated diff to pam-1.3.1-r1 to use the three patches above, with the following filenames: - 578482: fix pam_exec: pam-1.3.1-musl-replace-strdupa.patch - 578484: sys/resources.h inclusion for RLIMIT_NOFILE pam-1.3.1-musl-fix-rlimit_nofile.patch - 578486: add portability for non glibc systems pam-1.3.1-musl-paths_logwtmp.patch
(In reply to Joshua Kinard from comment #13) > Created attachment 578502 [details, diff] [details, diff] > ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl > > Updated diff to pam-1.3.1-r1 to use the three patches above, with the > following filenames: > > - 578482: fix pam_exec: > pam-1.3.1-musl-replace-strdupa.patch > > - 578484: sys/resources.h inclusion for RLIMIT_NOFILE > pam-1.3.1-musl-fix-rlimit_nofile.patch > > - 578486: add portability for non glibc systems > pam-1.3.1-musl-paths_logwtmp.patch These patches do not need to be applied bassed on libc, I have tested them on glibc already.
I will take a look within the next week, thanks!
ok, I was able to compile and run it without conditional elibc_musl flag, if nothing bad happen I gonna commit it tomorrow (just in case).
(In reply to Mikle Kolyada from comment #16) > ok, I was able to compile and run it without conditional elibc_musl flag, if > nothing bad happen I gonna commit it tomorrow (just in case). Is this still a go or no go?
ping @Mikle for updates? otherwise, we're veering on "maintainer-timeout" ... ;) tia!
(In reply to Michael 'veremitz' Everitt from comment #18) > ping @Mikle for updates? > > otherwise, we're veering on "maintainer-timeout" ... ;) tia! There's a fix in the musl overlay. I just ran into this again when testing to see how many packages need fixes from the overlay. If no one has any issues, I can commit the patch from the musl overlay to the main tree this weekend.
Though I talked to upstream and now see no point to adopt a patch yet.
(In reply to Mikle Kolyada from comment #20) > Though I talked to upstream and now see no point to adopt a patch yet. So pam will remain broken in the main gentoo overlay for musl targets for the time being?
(In reply to Joshua Kinard from comment #21) > (In reply to Mikle Kolyada from comment #20) > > Though I talked to upstream and now see no point to adopt a patch yet. > > So pam will remain broken in the main gentoo overlay for musl targets for > the time being? there are two points: 1.) I fail to see why suddenly you wanted to apply these patches locally (in gentoo) if the issue is known for ages. 2.) This bug is not relivant anymore, I see upstream merged few pull requests to unbind glibc-only extensions, they are slow at releases so I will have to take a snapshot I guess.
(In reply to Mikle Kolyada from comment #22) > (In reply to Joshua Kinard from comment #21) > > (In reply to Mikle Kolyada from comment #20) > > > Though I talked to upstream and now see no point to adopt a patch yet. > > > > So pam will remain broken in the main gentoo overlay for musl targets for > > the time being? > > there are two points: > > 1.) I fail to see why suddenly you wanted to apply these patches locally (in > gentoo) if the issue is known for ages. > > 2.) This bug is not relivant anymore, I see upstream merged few pull > requests to unbind glibc-only extensions, they are slow at releases so I > will have to take a snapshot I guess. You misread me, I think. I'm not fixated on these specific patches as the solution to fixing the problem (and this bug isn't just about those patches). They're just one known way to fix the issue. Per point #2, if upstream has already addressed the problem, but is just slow at cutting new releases, then a snapshot sounds fine in-lieu of the patches. That said, I wouldn't close this bug off as WONTFIX, but instead close the bug as FIXED when the snapshot is committed and I can do a quick test compile. I'll leave the status as-is, but please take it as a suggestion.
(In reply to Joshua Kinard from comment #23) > > That said, I wouldn't close this bug off as WONTFIX, but instead close the > bug as FIXED when the snapshot is committed and I can do a quick test > compile. > > I'll leave the status as-is, but please take it as a suggestion. Re-opening per suggestion. Thanks Kumba, and Mikle, I think cutting a snapshot is the smart solution for now. TIA.
There is no point in re-opening exactly this bug as exactly 'this' bug will not closed as fixed.
Upstream snapshot is there: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07d43a193bf918249c47d14c1fe66b0139b0fe83
(In reply to Mikle Kolyada from comment #25) > There is no point in re-opening exactly this bug as exactly 'this' bug will > not closed as fixed. ACK, technically you have a point. Thanks for the snapshot all-the-same.
(In reply to Michael 'veremitz' Everitt from comment #27) > (In reply to Mikle Kolyada from comment #25) > > There is no point in re-opening exactly this bug as exactly 'this' bug will > > not closed as fixed. > > ACK, technically you have a point. > > Thanks for the snapshot all-the-same. I take that back, the problem is indeed fixed upstream, just pending release. per *this* bug and the linked URL.
