FS#59562 - [m4] fails to build from source with glibc 2.28

Attached to Project: Arch Linux
Opened by zhengyi (goodmen) - Wednesday, 08 August 2018, 06:35 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 04 November 2018, 01:22 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
M4 source will not build successfully if glibc-2.28 installed.

M4 up stream is not updated for 2 years.

glibc-2.28 remove /usr/include/bits/libio.h
in M4/lib/freadahead.c, there is an ugly function which has
so many #if/endif preprocessor.

On Glibc-2.28, that code can not guess the C runtime lib type and version.
So it run into #error.

anyone can help?

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 04 November 2018, 01:22 GMT
Reason for closing:  Fixed
Additional comments about closing:  m4 1.4.18-2
Comment by loqs (loqs) - Wednesday, 08 August 2018, 09:48 GMT Comment by Eli Schwartz (eschwartz) - Wednesday, 08 August 2018, 14:01 GMT
original source here: https://lists.gnu.org/archive/html/bug-m4/2018-08/msg00000.html

Apparently it uses some manually cp'ed gnulib stuff in complete disarray.
Comment by zhengyi (goodmen) - Thursday, 09 August 2018, 02:01 GMT
fedora's patch not fixed it.

replace '_IO_ftrylockfile' with '_IO_EOF_SEEN' is not enough.
freadahead.c will not build due to '_IO_IN_BACKUP' is not a valid symbol anymore.

I feel very strange why the M4 developer use the _INTERNAL_ symbols of glibc ?!
Comment by Eli Schwartz (eschwartz) - Thursday, 09 August 2018, 02:47 GMT
The m4 developer did not do so, they just borrowed gnulib code which does. As for why: https://lists.gnu.org/r/bug-gnulib/2018-03/msg00002.html

It's interesting that the bug from https://lists.gnu.org/r/bug-gnulib/2009-01/msg00067.html and https://sourceware.org/bugzilla/show_bug.cgi?id=12799 is still unfixed :p
Comment by Nic Fogden (Nicef) - Friday, 10 August 2018, 08:56 GMT
Fromlfs-dev@lists.linuxfromscratch.org/msg03131.html"> https://www.mail-archive.com/lfs-dev@lists.linuxfromscratch.org/msg03131.html
Try echo "#define _IO_IN_BACKUP 0x100" >> lib/stdio-impl.h
Comment by Devin Cofer (Ranguvar) - Thursday, 23 August 2018, 22:01 GMT
Same bug seems to affect autoconf, automake, make, and findutils.
Comment by loqs (loqs) - Friday, 24 August 2018, 17:33 GMT
@Ranguvar at least in the case of make it is not just glibc that is causing the fail to build from source.
Does this patch work for you for make?
Edit:
autoconf perl issue http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=dfb0659b205e03af62542cd318a9f3253e28c40a
automake test suite is not compatible with python3
findutils looks to be the same issue.
Edit2:
Bison looks to be the same issue as well.
Edit3:
bison builds as is due to _IO_EOF_SEEN being defined.

Loading...