Bug 14374

Summary: libxml2-2.9.10-r0 do_compile: oe_runmake failed
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Yves LHUILLIER <yves.lhuillier>
Component: meta-yoctoAssignee: Unassigned <unassigned>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Medium+ CC: poky.bs.watcher, poky.watcher, randy.macleod, richard.purdie, steve
Version: 3.1.7   
Target Milestone: 3.1.11   
Hardware: x86   
OS: x86_64   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
config file
none
Attaching the config.log found in tmp/work/aarch64-poky-linux/libxml2/2.9.10-r0/build/config.log
none
config.log of python3-native none

Description Yves LHUILLIER 2021-05-03 09:31:30 UTC
Created attachment 4794 [details]
config file

When trying to build core-image-minimal with `bitbake core-image-minimal`, the execution of do_compile in libxml2-2.9.10-r0 fails.

Link stage complains about complains about
```
aarch64-poky-linux-libtool: link: aarch64-poky-linux-gcc  -march=armv8-a+crc -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/opt/yocto/usvp4armv8/tmp/work/aarch64-poky-linux/libxml2/2.9.10-r0/recipe-sysroot -shared  -fPIC -DPIC  .libs/libxml.o .libs/libxml2-py.o .libs/types.o   ../.libs/libxml2.so -lz -lcrypt -lintl -lpthread -ldl -lutil -lm  -march=armv8-a+crc -fstack-protector-strong --sysroot=/opt/yocto/usvp4armv8/tmp/work/aarch64-poky-linux/libxml2/2.9.10-r0/recipe-sysroot -O2 -g -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -Wl,-soname -Wl,libxml2mod.so -o .libs/libxml2mod.so                                                                                
/opt/yocto/usvp4armv8/tmp/work/aarch64-poky-linux/libxml2/2.9.10-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/9.3.0/ld: cannot find -lintl
```
Comment 1 Randy MacLeod 2021-05-06 14:46:08 UTC
Is this reproducible? If not how frequently is the failure seen?
Can you provide more info about the host machine and the initial output that shows what layers are being used.
Comment 2 Randy MacLeod 2021-05-06 14:46:29 UTC
Does it happen with oe-core/master?
Comment 3 Randy MacLeod 2021-05-06 14:47:47 UTC
Can you provide the configlog for libxml2 as well?
Comment 4 Yves LHUILLIER 2021-05-07 09:09:48 UTC
Created attachment 4796 [details]
Attaching the config.log found in  tmp/work/aarch64-poky-linux/libxml2/2.9.10-r0/build/config.log
Comment 5 Yves LHUILLIER 2021-05-07 09:11:51 UTC
Because I had to make quick progress I moved to gatesgarth, where everything is ok.

Nevertheless I kept a maximum of build files to answer possible questions.

 Reproducibility => I did 3 full builds from scractch (rm -Rf tmp cache sstate-cache) which ended up with the same error.

My host machine:
- Linux localhost 5.10.33-desktop-1.mga8 #1 SMP Wed Apr 28 15:59:24 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
- Of course, the yocto warning says it all "WARNING: Host distribution "mageia-8" has not been validated with this version of the build system;"

Don't know if it happens with core-oe/master
Comment 6 Richard Purdie 2021-05-13 15:44:22 UTC
Somehow, -lintl is coming in through PYTHON_LIBS. I haven't looked too closely at a build yet to understand where that comes from but it appears to be how the issue is creeping in. I suspect some kind of confusion between python3-native and the host's python3
Comment 7 Richard Purdie 2021-05-13 15:48:46 UTC
Appears that PYTHON_LIBS comes from running python3.8-config --ldflags and that comes from python3-native. This raises the question about where/how python3 is finding a libintl when another part of the build can't. The config/logs from the python3-native build may shed more light...
Comment 8 Yves LHUILLIER 2021-05-27 21:25:05 UTC
Created attachment 4802 [details]
config.log of python3-native

config.log found in tmp/work/x86_64-linux/python3-native/3.8.2-r0/build
Comment 9 Randy MacLeod 2021-06-03 15:15:16 UTC
Thanks for the info Yves. We don't have anyone signed up to work on this unfortunately so it's currently unassigned.
Comment 10 Richard Purdie 2021-06-03 15:48:03 UTC
Seems to come from configure:18204: checking for textdomain in -lintl
which says "yes". I don't know enough about mageia-8 to know why libintl exists and why it is finding this and preferring it when there probably is a glibc version too.

You could try disabling that test when building python? Comparing with another build on a working machine may also shed some light. On mine, that test does see "no" as the return value.

Adding:

ac_cv_lib_intl_textdomain=no

to CACHED_CONFIGUREVARS in the recipe would test what happens if you disable it.
Comment 11 Yves LHUILLIER 2021-06-04 11:51:26 UTC
for the sake of completeness, "checking for textdomain in -lintl" also says "yes" in gatesgarth where everything goes fine up to the end.  I'm comparing the logs to see where discrepancies appear.
Comment 12 Steve Sakoman 2021-09-23 15:16:14 UTC
Closing since we can't reproduce on supported distros and there have been no other reports of this issue