[Buildroot] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS

[Buildroot] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS

[J. Neuschäfer via buildroot]

Through a build failure of LVM2 on musl-libc 1.2.5 in the Buildroot
autobuild service[1], I noticed that musl-libc's Scrt1 for microblaze
produces a relocation targeting the .text section, which subsequently
leads to a crash at run-time because musl-libc does not support
textrels[2]. Buildroot uses the "-z text" linker option to catch
textrels early, on musl-libc.

The error can be reduced to the following test case:

  $ cat hello.c
  #include <stdio.h>
  int main(void) { puts("Hello world!"); return 0; }
  $ host/bin/microblaze-buildroot-linux-musl-gcc hello.c -z text -pie -fPIC
  microblaze-buildroot-linux-musl/bin/ld: microblaze-buildroot-linux-musl/sysroot/lib/Scrt1.o:
    warning: relocation against `_start_c' in read-only section `.text'
  microblaze-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations
  collect2: error: ld returned 1 exit status

LVM2 uses -pie only after the AC_TRY_CCFLAG macro has determined that it
can be used. This is where the problem begins: AC_TRY_CCFLAG only tries
compiling, it does not try linking the resulting object file.

To catch problems like this, this patch changes AC_TRY_CCFLAG to link in
addition to compiling. By detecting correctly that -pie does not work on
musl-libc/microblaze with -ztext, the build failure in Buildroot is fixed.

[1]: http://autobuild.buildroot.net/results/dc4/dc4fc33eaeafe5d6707d26a373560402533954f6/build-end.log
[2]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: J. Neuschäfer <j.neuschaefer@gmx.net>
---
Hi, I'm cross-posting this to the LVM2, Buildroot, and musl mailing
lists to get potential feedback early on.
---
 acinclude.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/acinclude.m4 b/acinclude.m4
index 47fdd59c3..9b1d3a605 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -25,7 +25,7 @@ AC_DEFUN([AC_TRY_CCFLAG],
     ac_save_CFLAGS=$CFLAGS
     CFLAGS=$1
     AC_CACHE_CHECK([whether $CC accepts $1 flag], [ac_cv_flag_$2],
-	[AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
+	[AC_LINK_IFELSE([AC_LANG_PROGRAM()],
 			   [AS_VAR_SET([ac_cv_flag_$2], [yes])],
 			   [AS_VAR_SET([ac_cv_flag_$2], [no])])])
     CFLAGS=$ac_save_CFLAGS

---
base-commit: 90a845a7087478a7cdc7a60d89d2e7ee1366160e
change-id: 20240811-microblaze-8ff8a6217471

Best regards,
--
J. Neuschäfer <j.neuschaefer@gmx.net>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [musl] [PATCH lvm2] acinclude.m4: Link when trying CCFLAGS

[J. Neuschäfer via buildroot]

On Sun, Aug 11, 2024 at 05:52:29PM -0400, Rich Felker wrote:
> On Sun, Aug 11, 2024 at 11:04:38AM +0200, J. Neuschäfer wrote:
> > Through a build failure of LVM2 on musl-libc 1.2.5 in the Buildroot
> > autobuild service[1], I noticed that musl-libc's Scrt1 for microblaze
> > produces a relocation targeting the .text section, which subsequently
> > leads to a crash at run-time because musl-libc does not support
> > textrels[2]. Buildroot uses the "-z text" linker option to catch
> > textrels early, on musl-libc.
> >
> > The error can be reduced to the following test case:
> >
> >   $ cat hello.c
> >   #include <stdio.h>
> >   int main(void) { puts("Hello world!"); return 0; }
> >   $ host/bin/microblaze-buildroot-linux-musl-gcc hello.c -z text -pie -fPIC
> >   microblaze-buildroot-linux-musl/bin/ld: microblaze-buildroot-linux-musl/sysroot/lib/Scrt1.o:
> >     warning: relocation against `_start_c' in read-only section `.text'
> >   microblaze-buildroot-linux-musl/bin/ld: read-only segment has dynamic relocations
> >   collect2: error: ld returned 1 exit status
[...]
>
> No objection, but this is a bug in the tooling (ld) that we could also
> avoid on the musl side. So there are probably 3 places things should
> be changed here.
>
> Rich

I finally got around to testing your musl patch (http://0x0.st/XWB9.diff -
"use hidden visibility for C entry point function _start_c").
It solves the immediate problem for microblaze(el) as far as I can see.

I'm not familiar enough with linker intricacies to write a binutils/ld
bug report though.


-- jn
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot