Opened 8 months ago
Last modified 8 months ago
#69572 assigned defect
dash @0.5.12: Undefined symbols _stpncpy
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | Mathias.Laurin+macports@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | tiger leopard snowleopard | Cc: | |
Port: | dash |
Description
dash fails to build on Mac OS X 10.6 and earlier because it uses stpncpy
:
jobs.c:434:7: warning: implicitly declaring library function 'stpncpy' with type 'char *(char *, const char *, unsigned long)' [-Wimplicit-function-declaration] s = stpncpy(s, strsignal(st), 32); ^ jobs.c:434:7: note: include the header <string.h> or explicitly provide a declaration for 'stpncpy'
Undefined symbols for architecture x86_64: "_stpncpy", referenced from: _sprint_status in jobs.o ld: symbol(s) not found for architecture x86_64
The suggestion to include <string.h> is incorrect because there is no stpncpy
anywhere on Mac OS X 10.6 or earlier.
I believed that our legacy support library implemented stpncpy
so I added legacy support to dash but in fact legacy support doesn't have stpncpy yet.
gnulib contains an implementation of stpncpy
for systems that don't have it, if dash uses or has interest in starting to use gnulib.
dash doesn't seem to have an issue tracker. They track bugs on their mailing list. I found a mailing list post from 2022 where someone submitted a bunch of portability fixes, including an implementation of stpncpy
:
https://lore.kernel.org/dash/6cacf608-326e-211a-7d37-164041710980@knaff.lu/
Unfortunately nobody appears to have responded to it. Perhaps that part of the patch could be lifted out and added to the port, or someone could post a message to the mailing list redirecting the developers' attention to this patch.
Replying to ryandesign:
https://lore.kernel.org/dash/858410A4-AFD5-4DBF-83BD-232C6F4B33AD@ryandesign.com/T/#u