9

The building of tarball releases of GNU m4 1.4.10 to 1.4.18 (didn't test all hotfix versions, but I assume the error is consistent among this range) with ./configure && make -j1 and git git repository http://git.savannah.gnu.org/r/m4.git with ./bootstrap && ./configure && make -j1 (commit cvs-readonly-359-gd69fa528 i.e. HEAD of master) fails due to

freadahead.c: In function 'freadahead':
freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
  #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
   ^~~~~
make[3]: *** [Makefile:1910: freadahead.o] Error 1
make[3]: Leaving directory '/mnt/data/sources/m4-1.4.18/lib'

I'm very confused by this error and according to a superficial google search the problem is the consequence of an overly long ignored upstream update, see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1573342 with the genius documentation of the fix "Thanks for the bug report, fixed!" - if that doesn't help others...

I tried to build glibc from source and install it into a custom prefix[1]. 2.28 and 2.27 exhibit the same issue and 2.26 fails due to

make[2]: Verzeichnis „/mnt/data/sources/glibc-2.26/inet“ wird betreten
gcc ../sysdeps/unix/sysv/linux/if_index.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -fno-stack-protector -frounding-math -g -Wstrict-prototypes -Wold-style-definition     -ftls-model=initial-exec   -U_FORTIFY_SOURCE   -I../include -I/mnt/data/sources/glibc-2.26-build/inet  -I/mnt/data/sources/glibc-2.26-build  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT -include /mnt/data/sources/glibc-2.26-build/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -o /mnt/data/sources/glibc-2.26-build/inet/if_index.o -MD -MP -MF /mnt/data/sources/glibc-2.26-build/inet/if_index.o.dt -MT /mnt/data/sources/glibc-2.26-build/inet/if_index.o
../sysdeps/unix/sysv/linux/if_index.c: In function ‘__if_nametoindex’:
../sysdeps/unix/sysv/linux/if_index.c:46:3: error: ‘strncpy’ specified bound 16 equals destination size [-Werror=stringop-truncation]
   strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name));
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [/mnt/data/sources/glibc-2.26-build/sysd-rules:213: /mnt/data/sources/glibc-2.26-build/inet/if_index.o] Fehler 1
make[2]: Verzeichnis „/mnt/data/sources/glibc-2.26/inet“ wird verlassen
make[1]: *** [Makefile:215: inet/subdir_lib] Fehler 2
make[1]: Verzeichnis „/mnt/data/sources/glibc-2.26“ wird verlassen
make: *** [Makefile:9: all] Fehler 2

and 2.25 due to

strftime_l.c: In function ‘__strftime_internal’:
strftime_l.c:719:4: error: macro expands to multiple statements [-Werror=multistatement-macros]
    digits = d > width ? d : width;          \
    ^~~~~~
strftime_l.c:1260:6: note: in expansion of macro ‘DO_NUMBER’
      DO_NUMBER (1, tp->tm_year + TM_YEAR_BASE);
      ^~~~~~~~~
strftime_l.c:1259:4: note: some parts of macro expansion are not guarded by this ‘else’ clause
    else
    ^~~~
In file included from wcsftime_l.c:23:
strftime_l.c: In function ‘__strftime_internal’:
strftime_l.c:719:4: error: macro expands to multiple statements [-Werror=multistatement-macros]
    digits = d > width ? d : width;          \
    ^~~~~~
strftime_l.c:1260:6: note: in expansion of macro ‘DO_NUMBER’
      DO_NUMBER (1, tp->tm_year + TM_YEAR_BASE);
      ^~~~~~~~~
strftime_l.c:1259:4: note: some parts of macro expansion are not guarded by this ‘else’ clause
    else
    ^~~~
cc1: all warnings being treated as errors
make[2]: *** [../o-iterator.mk:9: /mnt/data/sources/glibc-2.25-build/time/strftime_l.os] Fehler 1

which made me decide to not try out further version.

[The discussion on a report about a similar issue in findutils] suggests to overwrite freadahead.{c,h} from an up-to-date gnulib source root. This causes a chain of problems which is unnecessary to document here as I don't know what I'm doing.

How to get started with fixing, reporting and/or working around this issue?

I'm building m4 from source for a bootstrap script for systems where a user doesn't have privileges to use the package manager. I'm really just interested in building the original GNU m4 from release source tarballs.

An overview of build results on other similarily bare systems is provided at https://gitlab.com/krichter/m4/pipelines/36977411.


[1] In case you're investigating this always install glibc into a custom prefix because an installation in the default prefix /usr/local will most certainly ruine your system. Consider using checkinstall to be sure.

2
  • What was wrong with m4 package from the official repository? Why do you think that sudo apt install m4 does not suite your needs? Also if you want to successfully compile it from sources - start with sudo apt-get build-dep m4...
    – N0rbert
    Dec 8, 2018 at 15:30
  • @N0rbert good point, question updated Dec 8, 2018 at 15:32

2 Answers 2

5

Try applying this patch. It is an OpenEmbedded-generated backport of upstream patch.

3
  • 1
    I am trying to build an old toolchain and this was the right solution for me, thanks!
    – kR105
    May 24, 2020 at 5:41
  • This worked for me with with m4-1.4.18 and glibc-2.32. Thanks!
    – peachykeen
    Jan 5, 2021 at 13:44
  • How do I install this patch? Sorry about the naive question. I'm on WSL2 and I can't compile a software due to the same issue as OP.
    – C. Crt
    Nov 16, 2022 at 14:52
4

If you want to build m4 from source then start by getting its build dependencies from the repository:

  1. enable Source code in the Software & Updates (software-properties-gtk)
  2. install needed build tools

    sudo apt-get install build-essential
    
  3. get necessary build dependencies for current m4 binary package

    sudo apt-get build-dep m4
    
  4. get source code of the current m4 binary package (with all needed patches provided by Debian and/or Ubuntu):

    apt-get source m4
    cd m4-*
    
  5. then compile it as usual

1
  • 1
    This is a good idea, however it introduces a specific handling of Ubuntu in my bootstrap script which is a larger technical dept. Think of the question as one about running third-party application (GNU m4 vs. the version patched by Ubuntu). Dec 8, 2018 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.