Your message dated Sun, 15 Apr 2018 22:26:33 +0300
with message-id <20180415192633.GA23777@estella.local.invalid>
and subject line Re: Bug#893469: perl FTCBFS: error: unknown type name
'_LIB_VERSION_TYPE'
has caused the Debian Bug report #893469,
regarding perl FTCBFS: error: unknown type name '_LIB_VERSION_TYPE'
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
893469: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: perl
Version: 5.26.1-5
User: helm...@debian.org
Usertags: rebootstrap
Hi perl maintainers,
I see that you keep updating those cross files in the debian folder.
Thus it seems like you would still be interested in learning when cross
building perl stops working even when I tell you without attaching a
patch. (Sorry) As it happens, perl does presently fail to cross build:
| powerpc-linux-gnu-gcc -c -DPERL_CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/perl-NAqo_f/perl-5.26.1=. -fstack-protector-strong
-Wformat -Werror=format-security -fwrapv -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -g
-Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings
pp.c
| pp.c:47:5: error: unknown type name '_LIB_VERSION_TYPE'; did you mean
'__VERSION__'?
| _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
| ^~~~~~~~~~~~~~~~~
| __VERSION__
| pp.c:47:38: error: '_IEEE_' undeclared here (not in a function); did you mean
'_SIZET_'?
| _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
| ^~~~~~
| _SIZET_
| make[1]: *** [Makefile:250: pp.o] Error 1
| make[1]: Leaving directory '/<<PKGBUILDDIR>>'
| make: *** [debian/rules:153: perl.static] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
The host architecture being used seems to be irrelevant. I looked and
couldn't figure out what is wrong here. Could it be that some configure
result is cached wrongly somehow?
My quest on removing the need to have those cross files at all is still
ongoing and I cannot report much progress here.
I hope this bug report helps. In case it doesn't, please tell.
Helmut
--- End Message ---
--- Begin Message ---
Version: 5.26.2-1
On Mon, Mar 19, 2018 at 06:13:54PM +0200, Niko Tyni wrote:
> Looks like regen-configure/U/perl/d_libm_lib_version.U probes for
> _LIB_VERSION and stores the result in config.sh as 'd_libm_lib_version'.
> Now that it's gone from libm and math.h, the stored config.sh files
> need to be updated. I'll do that for the next upload; should be just a
> matter of
>
> sed -i "s/d_libm_lib_version='define'/d_libm_lib_version='undef'/"
> debian/cross/*/config.sh.static
I've done this with 5.26.2-1 in experimental, but had a wrong bug number
in the changelog. I'll fix that in a next upload. Closing manually now.
(Unfortunately I expect the new upstream release invalidated the stashed
config.sh.* files. So they won't be useful as-is until I've updated them
with the build results from experimental...)
--
Niko
--- End Message ---
