Bug 15306

Summary: glibc build fails in Docker container
Product: buildroot Reporter: Russ <russelljbrennan>
Component: OtherAssignee: unassigned
Status: RESOLVED WORKSFORME    
Severity: blocker CC: buildroot, russelljbrennan, yann.morin.1998
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: Macintosh   
OS: Linux   
Host: Target:
Build:

Description Russ 2023-01-31 22:41:33 UTC 
I'm trying to build glibc in a [Docker Container](https://github.com/batocera-linux/batocera.linux/blob/master/Dockerfile) and I'm getting two error.

The first happens on a clean build, and it *looks like* a path is being munged. The file `tdgppitrmssgwsgadebug/backtrace.os` is specified and doesn't exist, although `debug/backtrace.os` does exist:

```
...
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ar: tdgppitrmssgwsgadebug/backtrace.os: No such file or directory
make[3]: *** [../o-iterator.mk:9: /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/libc_nonshared.a] Error 1
make[3]: *** Waiting for unfinished jobs....
sed -e 's@ /bcm2837/build/glibc-2\.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/@ $(common-objpfx)@g' -e 's@^/bcm2837/build/glibc-2\.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/@$(common-objpfx)@g' -e 's@  *\.\.\/\([^     \]*\)@ $(..)\1@g' -e 's@^\.\.\/\([^     \]*\)@$(..)\1@g' \
    /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h.dT > /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h.dT2
rm -f /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h.dT
mv -f /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h.dT2 /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h.d
mv -f /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.hT /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/dl-link.h
make[3]: Leaving directory '/bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/elf'
make[2]: *** [Makefile:484: elf/subdir_lib] Error 2
make[2]: Leaving directory '/bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca'
make[1]: *** [Makefile:9: all] Error 2
make[1]: Leaving directory '/bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build'
make: *** [package/pkg-generic.mk:293: /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/.stamp_built] Error 2
make: Leaving directory '/build/buildroot'
make: *** [bcm2837-build] Error 2
```

If I resume the build after that error, building progresses but I get a second error which I guess might be caused by the first:

```
builder@92c3583543fb:/bcm2837/build$ /bcm2837/host/bin/aarch64-buildroot-linux-gnu-gcc   -nostdlib -nostartfiles -shared -o /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/ld.so.new -Wl,-z,relro -Wl,-z,defs /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os -Wl,--version-script=/bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/ld.map -Wl,-soname=ld-linux-aarch64.so.1
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os: in function `_dl_make_stacks_executable':
(.text+0x24b0): undefined reference to `__lll_lock_wake_private'
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: (.text+0x24c0): undefined reference to `__lll_lock_wait_private'
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os: in function `__thread_gscope_wait':
(.text+0xe500): undefined reference to `__lll_lock_wake_private'
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: (.text+0xe508): undefined reference to `__lll_lock_wait_private'
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: /bcm2837/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os: in function `_dl_init_static_tls':
(.text+0xf594): undefined reference to `__lll_lock_wait_private'
/bcm2837/host/lib/gcc/aarch64-buildroot-linux-gnu/12.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: (.text+0xf5b0): undefined reference to `__lll_lock_wake_private'
```


I have tried (with the same result):
- An older version of glibc
- An older version of ubuntu (20.04)

I also see the exact same symptom reported here https://homematic-forum.de/forum/viewtopic.php?f=65&t=71547
Comment 1 Yann E. MORIN 2023-02-12 19:57:07 UTC 
Russ, All,

I have been unable to reproduce such an error with the current master
branch, running Ubuntu 22.04 in a docker container, with this defconfig:
   BR2_aarch64=y

Please provide a *minimalist* defconfig that exhibits the issue.

Regards,
Yann E. MORIN.
Comment 2 Russ 2023-02-13 00:43:08 UTC 
Yann,

Can you provide comprehensive instruction on how I can reproduce your success? I'm happy to see if I can reproduce in my environment, and if your setup works for me as well I'll look for what's different when building the reported target.

I'm not super familiar with batocera nor buildroot, so it'd be hard for me to pare it down to a minimal example.
Comment 3 Peter Korsgaard 2023-02-13 11:44:55 UTC 
> I'm not super familiar with batocera nor buildroot, so it'd be hard for me to pare

Ahh, so you are not using upstream Buildroot? Possibly your issue is in one of the buildroot modifications done by the batocera project, so perhaps check there?
Comment 4 Peter Korsgaard 2023-03-12 15:17:47 UTC 
Unable to reproduce with upstream Buildroot
Comment 5 Russ 2023-03-12 17:36:14 UTC 
Yep sorry I didn't close the loop on this -- I was able to repro with upstream, *but* I found that I could only repro when using a bind mount. I'm not sure what the root cause is, but I assume it's an issue with the Docker bind mounting mechanism.
Comment 6 Yann E. MORIN 2023-03-12 19:38:51 UTC 
Russ, All,

> I could only repro when using a bind mount

That would be very strang if that were the issue. We have utils/docker-run
in Buildroot, that allows running a container using the same Docker image
we use in the CI, and that script does use a bind mount to make the Buildroot
available in the container. And surely this works (I just tested).

Regards,
Yann E. MORIN.