develooper Front page | perl.perl5.porters | Postings from January 2019

[perl #133760] Please define _GNU_SOURCE unconditionally on Linux tomake memmem() available

Thread Previous
James E Keenan via RT
January 11, 2019 02:14
[perl #133760] Please define _GNU_SOURCE unconditionally on Linux tomake memmem() available
Message ID:
On Thu, 10 Jan 2019 16:24:06 GMT, wrote:
> This is a bug report for perl from,
> generated with the help of perlbug 1.40 running under perl 5.26.2.
> -----------------------------------------------------------------
> [Please describe your issue here]
> Since 5.25, Perl uses the memmem() function to implement ninstr().
> memmem() is only available from the string.h header if _GNU_SOURCE is
> defined. However, the perl build system currently only defines
> _GNU_SOURCE for threaded builds.
> On systems with the glibc libc, things appear to work regardless (I
> don't know why), but with the musl libc, this breaks ninstr(). Perl
> builds fine, but at runtime, functions using ninstr() fail:
> $ perl -e '($foo) = "abc" =~ /^(.*)$/; print index("abc", $foo)'
> -94330366722048

How can I safely test this behavior?

On Debian/Ubuntu, I see that the following packages are available via 'apt':

musl - standard C library
musl-dev - standard C library development files
musl-tools - standard C library tools

If I were to install them, would that interfere with 'libc' at all?

What arguments would I pass to perl's ./Configure to say "use musl instead of libc"?

> Please define _GNU_SOURCE unconditionally to fix this issue.

My initial reaction:  That's overkill.  We should detect 'musl' first and only then extend use of _GNU_SOURCE.

But this is not an area of expertise for me, so others should comment.

Thank you very much.

James E Keenan (

via perlbug:  queue: perl5 status: new

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About