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
Opened by zhengyi (goodmen) - Wednesday, 08 August 2018, 06:35 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 04 November 2018, 01:22 GMT
|
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
Sunday, 04 November 2018, 01:22 GMT
Reason for closing: Fixed
Additional comments about closing: m4 1.4.18-2
Apparently it uses some manually cp'ed gnulib stuff in complete disarray.
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 ?!
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
Try echo "#define _IO_IN_BACKUP 0x100" >> lib/stdio-impl.h
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.