dash @0.5.12: Undefined symbols _stpncpy

[ryandesign (Ryan Carsten Schmidt)]

dash fails to build on Mac OS X 10.6 and earlier because it uses stpncpy:

​https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/189987/steps/install-port/logs/stdio

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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Perhaps […] someone could post a message to the mailing list redirecting the developers' attention to this patch.

​https://lore.kernel.org/dash/858410A4-AFD5-4DBF-83BD-232C6F4B33AD@ryandesign.com/