Bug#875921: perl: Perl cross-build does not search correct paths for errno.h

[Helmut Grohne]

Control: block 798955 by 875921

Hi,

I ran into the very same problem in a different setting now. Presently
Debian's glibc ships errno.h as /usr/include/errno.h. However, glibc
headers are slightly different for kfreebsd and hurd and cannot be
coinstalled despite being marked Multi-Arch: same. The obvious solution
(#798955) is to move them to multiarch locations. In a similar vein,
non-glibc libcs will not provide /usr/include/errno.h. Before too long,
Debian systems won't have /usr/include/errno.h. And that's when perl
will FTBFS natively unless this bug is fixed.

Wookey's patch looks like it'd solve the issue, but I didn't verify
that. Rather I came up with my own patch before I found this bug. My
patch follows a quite different approach and might be easier to
upstream.

The thing that is presently bad is the 'die "Cannot find errno.h"' part.
My patch changes the logic and makes the script continue branching until
it lands in the final else. There, the C preprocesor is used to look up
errno.h on its standard search path (no searching on behalf of perl).

So what are the implications of the patch?

Whenever the current Errno_pm.PL would work, the behaviour would be
identical. In particular, cross building will continue to use
/usr/include/errno.h. However, that file presently resides in a
Multi-Arch: same package, so it cannot differ from other archs.
(Admittedly, that's only true for Linux/glibc architectures, but others
will fail to coinstall anyway.) Once, glibc fixes #798955, the file will
be missing and the correct logic via the C preprocessor is invoked. That
will finally fully fix Wookey's issue.

What do you think?

Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiarch-libc.patch
Type: text/x-diff
Size: 1282 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/perl-maintainers/attachments/20181031/39a763a1/attachment.patch>