016-M4: "undefined reference to `error'"

[takusuman]

I'm trying to build GNU m4 (version 1.4.19) at the chroot stage, and it returns, when CCLD'ng the final m4 binary, linking errors related to undefined functions being referenced --- interesting enough, these functions serve to the purpose of reporting errors, such as "error_at_line" or just "error".

Attached, there is my config.log (which ran fine, by the way) and below there's the error itself.
config.log
Complete gmake log (errorm4.log)

copacabana_chroot% gmake -j$(grep -c 'processor' /proc/cpuinfo)
[...]
  CCLD     m4
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(clean-temp.o): in function `create_temp_dir':
/usr/src/cmp/m4-1.4.19/lib/clean-temp.c:234: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: /usr/src/cmp/m4-1.4.19/lib/clean-temp.c:249: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(clean-temp.o): in function `do_rmdir':
/usr/src/cmp/m4-1.4.19/lib/clean-temp.c:370: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: /usr/src/cmp/m4-1.4.19/lib/clean-temp.c:370: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: /usr/src/cmp/m4-1.4.19/lib/clean-temp.c:370: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(execute.o):/usr/src/cmp/m4-1.4.19/lib/execute.c:347: more undefined references to `error' follow
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(verror.o): in function `verror_at_line':
/usr/src/cmp/m4-1.4.19/lib/verror.c:68: undefined reference to `error_at_line'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: /usr/src/cmp/m4-1.4.19/lib/verror.c:70: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: /usr/src/cmp/m4-1.4.19/lib/verror.c:76: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(xalloc-die.o): in function `xalloc_die':
/usr/src/cmp/m4-1.4.19/lib/xalloc-die.c:34: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(xprintf.o): in function `xvprintf':
/usr/src/cmp/m4-1.4.19/lib/xprintf.c:50: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(xprintf.o): in function `xvfprintf':
/usr/src/cmp/m4-1.4.19/lib/xprintf.c:76: undefined reference to `error'
/tools/lib/gcc/x86_64-pindoramaCOPACABANA-linux-musl/10.3.1/../../../../x86_64-pindoramaCOPACABANA-linux-musl/bin/ld: ../lib/libm4.a(xprintf.o):/usr/src/cmp/m4-1.4.19/lib/xprintf.c:76: more undefined references to `error' follow
collect2: error: ld returned 1 exit status
gmake[2]: *** [m4] Error 1
gmake[2]: Leaving directory `/usr/src/cmp/m4-1.4.19/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/src/cmp/m4-1.4.19'
gmake: *** [all] Error 2

Just a quick note: I have not compiled argp-standalone nor GNU readline, since these were not specified as dependencies of GNU m4 in LFS' Dependencies appendix (https://www.linuxfromscratch.org/lfs/view/9.1-systemd/appendices/dependencies.html).
I do not think this is a problem, but...

Funny enough, before a third attempt to build it, I have got "undefined reference" errors related to rpl_* functions, which, at least based on my little research, it was related to Gnulib; but, after I restarted the chroot environment, this error just disappeared and the "undefined reference to `error'" errors stayed.
Yes, this is confusing, I know.

[takusuman]

Ok, researching a little bit more, I came to the conclusion that, for some reason, it's trying to link everything as if it were on GNU's C library — for instance, `error_at_line' is considered a GNU extension (as seen here https://linux.die.net/man/3/error_at_line
and here https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html).
Yet this is a relevant discovery, I still do not knowing how could I fix that right now. 🤔

[takusuman]

Any guesses, @dslm4515? (I know you have built Musl-LFS and variations of it many times, that's why I'm bothering you 🤣)

[takusuman]

Ok, I have some updates here: apparently, this "bug" was caused because of the musl legacy compatibility headers being installed before m4. After moving /usr/include/error.h to /usr/include/_error.h, it compiled without any problem.
This is, of couse, a temporary fix (as we would call it here in Brazil, a "gambiarra"). This shall be fixed, maybe forcing configure options.
Well, GNU as always.

[takusuman]

... And, of course, Void Linux had made a fix for that some time ago.
https://github.com/void-linux/void-packages/blob/master/srcpkgs/m4/template#L16-L19

In fact, just force (using the cache variables) the configure script to "believe" that the C library does not have error_at_line() nor sys/cdefs.h, so it will use the Gnulib to provide them.
So, summarizing it: just add ac_cv_lib_error_at_line=no and ac_cv_header_sys_cdefs_h=no at configure command, like this:

copacabana_chroot% ac_cv_lib_error_at_line=no \
ac_cv_header_sys_cdefs_h=no \
./configure --prefix=/usr/ccs

[takusuman]

I think I could close this as fixed, but anyway it is a interesting bug. 😆

[takusuman]

... And, of course, Void Linux had made a fix for that some time ago. https://github.com/void-linux/void-packages/blob/master/srcpkgs/m4/template#L16-L19

In fact, just force (using the cache variables) the configure script to "believe" that the C library does not have error_at_line() nor sys/cdefs.h, so it will use the Gnulib to provide them. So, summarizing it: just add ac_cv_lib_error_at_line=no and ac_cv_header_sys_cdefs_h=no at configure command, like this:

copacabana_chroot% ac_cv_lib_error_at_line=no \
ac_cv_header_sys_cdefs_h=no \
./configure --prefix=/usr/ccs

Now this can be fixed just by using -legacy-compat on LDFLAGS when building GNU m4, since now these functions are available as link-editable libraries.
For reference: Projeto-Pindorama/musl-compat@b1795ea