Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 687234 - sys-libs/pam-1.3.1-r1: Fails to build against sys-libs/musl due to undefined 'strdupa' (glibc-specific extension)
Summary: sys-libs/pam-1.3.1-r1: Fails to build against sys-libs/musl due to undefined ...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mikle Kolyada
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: musl-porting
  Show dependency tree
 
Reported: 2019-06-02 22:55 UTC by Joshua Kinard
Modified: 2020-01-28 13:45 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Adds a local implementation of 'strdupa' to linux-pam (pam-1.3.1-musl-add-add-strdupa.patch,2.33 KB, patch)
2019-06-02 23:15 UTC, Joshua Kinard
Details | Diff
Defines _PATH_LASTLOG and adds 'logwtmp' (pam-1.3.1-musl-include-paths-header.patch,1.98 KB, patch)
2019-06-02 23:21 UTC, Joshua Kinard
Details | Diff
ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl (pam-1.3.1-r1_ebuild-musl-patches.diff,629 bytes, patch)
2019-06-02 23:27 UTC, Joshua Kinard
Details | Diff
fix pam_exec (pam-1.3.1-fix-pam-exec.patch,1.29 KB, patch)
2019-06-03 00:27 UTC, Jory A. Pratt
Details | Diff
sys/resources.h inclusion for RLIMIT_NOFILE (pam-1.3.1-include-sys_resource_h.patch,645 bytes, patch)
2019-06-03 00:28 UTC, Jory A. Pratt
Details | Diff
add portability for non glibc systems (pam-1.3.1-portability-fixes.patch,1.72 KB, patch)
2019-06-03 00:29 UTC, Jory A. Pratt
Details | Diff
ebuild patch for pam-1.3.1-r1 to enable building against sys-libs/musl (pam-1.3.1-r1_ebuild-musl-patches.diff,627 bytes, patch)
2019-06-03 08:36 UTC, Joshua Kinard
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard gentoo-dev 2019-06-02 22:55:35 UTC
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
Comment 1 Joshua Kinard gentoo-dev 2019-06-02 23:15:00 UTC
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).
Comment 2 Joshua Kinard gentoo-dev 2019-06-02 23:21:18 UTC
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).
Comment 3 Joshua Kinard gentoo-dev 2019-06-02 23:25:37 UTC
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.
Comment 4 Joshua Kinard gentoo-dev 2019-06-02 23:27:47 UTC
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.
Comment 5 Jory A. Pratt gentoo-dev 2019-06-02 23:54:38 UTC
(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.
Comment 6 Jory A. Pratt gentoo-dev 2019-06-03 00:27:12 UTC
Created attachment 578482 [details, diff]
fix pam_exec

will attach the three patches we currently use in musl overlay.
Comment 7 Jory A. Pratt gentoo-dev 2019-06-03 00:28:34 UTC
Created attachment 578484 [details, diff]
sys/resources.h inclusion for RLIMIT_NOFILE
Comment 8 Jory A. Pratt gentoo-dev 2019-06-03 00:29:13 UTC
Created attachment 578486 [details, diff]
add portability for non glibc systems
Comment 9 Jory A. Pratt gentoo-dev 2019-06-03 00:29:45 UTC
Joshua please test the last three patches and see if you have success as well please.
Comment 10 Joshua Kinard gentoo-dev 2019-06-03 00:52:31 UTC
(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.
Comment 11 Jory A. Pratt gentoo-dev 2019-06-03 01:59:45 UTC
https://gitweb.gentoo.org/proj/musl.git/
Comment 12 Joshua Kinard gentoo-dev 2019-06-03 08:32:53 UTC
(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.
Comment 13 Joshua Kinard gentoo-dev 2019-06-03 08:36:55 UTC
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
Comment 14 Jory A. Pratt gentoo-dev 2019-06-13 00:39:48 UTC
(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.
Comment 15 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2019-06-23 11:06:07 UTC
I will take a look within the next week, thanks!
Comment 16 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2019-06-24 19:05:06 UTC
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).
Comment 17 Jory A. Pratt gentoo-dev 2019-07-11 22:32:55 UTC
(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?
Comment 18 Michael 'veremitz' Everitt 2019-10-20 15:00:43 UTC
ping @Mikle for updates?

otherwise, we're veering on "maintainer-timeout" ... ;) tia!
Comment 19 Joshua Kinard gentoo-dev 2020-01-28 03:13:20 UTC
(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.
Comment 20 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-01-28 06:29:41 UTC
Though I talked to upstream and now see no point to adopt a patch yet.
Comment 21 Joshua Kinard gentoo-dev 2020-01-28 07:11:46 UTC
(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?
Comment 22 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-01-28 07:27:15 UTC
(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.
Comment 23 Joshua Kinard gentoo-dev 2020-01-28 08:20:00 UTC
(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.
Comment 24 Michael 'veremitz' Everitt 2020-01-28 13:00:22 UTC
(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.
Comment 25 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-01-28 13:01:57 UTC
There is no point in re-opening exactly this bug as exactly 'this' bug will not closed as fixed.
Comment 26 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-01-28 13:15:50 UTC
Upstream snapshot is there:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07d43a193bf918249c47d14c1fe66b0139b0fe83
Comment 27 Michael 'veremitz' Everitt 2020-01-28 13:43:48 UTC
(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.
Comment 28 Michael 'veremitz' Everitt 2020-01-28 13:45:56 UTC
(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.