5054 2013-08-27 16:22:16 +0000 syslinux-native depends on i386 libc headers on amd64 (gcc-4.7 works, gcc-4.8 needs gcc-multilib) 2015-02-09 23:36:41 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.4.1 x86 x86_64 RESOLVED FIXED 23 December 2013: Doc flag reset to "Done" Low normal Future 1 olof.johansson srifenbark dvhart jessica.zhang meta.mr.watcher meta.watcher msvilans richard.purdie srifenbark tf+bugs.yocto --- --- Done (doc changes complete) oldest_to_newest 35950 0 olof.johansson 2013-08-27 16:22:16 +0000 Syslinux is built with -march=i386 (set by the syslinux build system), but without the build host having installed libc6-dev-i386 (debian package containing i386 libc headers) or similar, the build fails, sometimes with strange errors like gcc not recognizing -malign-labels=0 or "CPU you selected does not support x86-64 instruction set". The root cause being: gcc -isystem/mnt/builds/olof/poky/master/build/galileo/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -std=gnu99 -m32 In file included from <command-line>:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include <bits/predefs.h> Syslinux tries to compile a dummy.c to determine if a flag is accepted by gcc or not, and seeing any failure, it assumes it doesn't (the failures mentioned above is caused by failing tests for -m32 and -malign-labels=0). That's an oddity of the syslinux buildsystem, but the issue for the oe metadata is the it makes the build host depend on libc headers for i386. Any ideas how this can be solved in an appropriate way? I've been seeing this on Debian Sid (Unstable) with GCC 4.8, but I'm not sure if that's relevant. This issue exists on both dylan and master. 35957 1 dvhart 2013-08-27 21:26:01 +0000 Does this happen when building syslinux-native for a 32 bit machine using bitbake? Such as qemux86 or genericx86? $ bitbake syslinux-native I do not have libc6-dev-i386 on my Ubuntu 12.04 system and can successfully build syslinux-native for genericx86. 35958 2 dvhart 2013-08-27 22:06:03 +0000 I'm not seeing march=i386, malign, not -m32 in the compile log for syslinux-native. I do see those when building syslinux for qemux86 (-m32 -march=i586, but still no malign - although it is clearly in the various .mk files).... but that is built using the cross compiler, which should not be depending on your host libc. Can you provide details on the build environment and target. Typically the initial output of bitbake provides this in a tabular format. I think I'm missing something about your setup.... 35959 3 olof.johansson 2013-08-27 23:05:52 +0000 I had this issue for both meta-intel's nuc as well as qemux86. But nuc is x86_64 so I don't know... The build machine is x86_64. lp on IRC had the same issue, but not sure what he built for. This is what the bitbake output looks like now. I was able to reproduce the issue without any layers outside poky (for qemux86). Build Configuration: BB_VERSION = "1.19.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Debian-unstable" TARGET_SYS = "x86_64-poky-linux" MACHINE = "nuc" DISTRO = "poky" DISTRO_VERSION = "1.4+snapshot-20130827" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto = "(detachedfromb2ff1ad):325ee9b5fcebe902dfea78750502d8f6667d0a97" meta-oe = "master:72e23c12296fbc77193898c38426add58d0c2d71" meta-intel meta-nuc = "master:164067980e18e8ba60b317677ced2d75c3725dbe" meta-galileo = "master:9f2fd127bc9b119391d37e28a6944328e44b872e" 35960 4 olof.johansson 2013-08-27 23:08:11 +0000 Note also that the errors show up in do_install, since com32/ isn't built until then it seems... :/ 35961 5 olof.johansson 2013-08-27 23:13:39 +0000 Uhrm, that should be tf on IRC, not lp. I'll get some sleep now. :-) 35977 6 tf+bugs.yocto 2013-08-28 08:37:29 +0000 (In reply to comment #1) > Does this happen when building syslinux-native for a 32 bit machine using > bitbake? Such as qemux86 or genericx86? > > $ bitbake syslinux-native > Yes, this fails for me for genericx86 with pristine Poky master with host gcc 4.8.1 and libc 2.17. As Olaf mentioned in the absence of the devfiles all the syslinux gcc flag tests fail, so various fallbacks are used, including -malign-lables (in place of -falign-labels) which causes the build failure (the -malign substitution is a syslinux bug, -malign-labels is available on FVR only). I suspect this is either specifict to the compiler version or the libc version (worked fine until recent system update) and I think is ultimately a host misconfiguration issue rather than a Yocto bug. 37033 7 dvhart 2013-09-21 00:12:49 +0000 I was able to reproduce at long last on a newly deployed debian sid 64 when building syslinux-native (MACHINE=qemux86). Now I can start looking into it. Thanks for the details on reproduction. 37089 8 dvhart 2013-09-23 22:45:45 +0000 This appears to be compiler specific. On my Debian Sid x86_64 VM host if I build with /usr/bin/gcc->/usr/bin/gcc-4.8, the build fails as described here. If I change the symlink so /usr/bin/gcc->/usr/bin/gcc-4.7, it builds and installs successfully. BAD: gcc-4.8 (Debian 4.8.1-10) 4.8.1 GOOD: gcc (Debian 4.7.3-7) 4.7.3 37090 9 dvhart 2013-09-23 23:46:24 +0000 Discussed with HPA and he replied in part: --- This is odd in a number of ways. dummy.c doesn't include any headers at all (on purpose) so this is a header file gcc itself decides it needs. In other words, it might be that gcc -m32 is broken in your setup unless at least this header is available. This is disturbing; this seems to be a pretty drastic departure in typical gcc behavior. --- So, we need a toolchain expert in here to start digging into what is different about gcc 4.8 in this regard. I wouldn't mind seeing a reproduction on something other than Debian Sid as well to make sure it isn't just gcc4.8 on that installation. 37120 10 olof.johansson 2013-09-24 14:05:54 +0000 Thanks for looking into this issue! I can reproduce that changing the /usr/bin/gcc symlink to gcc-4.7 makes it build. 38667 11 dvhart 2013-11-07 18:48:15 +0000 *** Bug 5440 has been marked as a duplicate of this bug. *** 38668 12 dvhart 2013-11-07 18:50:04 +0000 Someone else reported this in Bug 5440 and installing gcc-multilib resolved the issue for them. Olof, is this sufficient to address this for you? 38692 13 olof.johansson 2013-11-08 19:51:22 +0000 Sure. Like I said, installing the libc-i686 package (bringing in gcc-multilib as a dependency) solves the issue indeed. And if the solution is to document this dependency, I don't have any issues with that. Again, thanks for your work investigating this issue :-). Did you got any more hints on why this works with gcc-4.7 but not gcc-4.8 though? 38693 14 dvhart 2013-11-08 22:46:58 +0000 Ah right, that is still outstanding, and worth understanding. I'll leave this open for that reason. I won't be able to dig into that myself for a while. Since there is a workaround, I'm going to move this to Future. 39334 15 richard.purdie 2013-12-11 10:36:37 +0000 The autobuilders are now falling over with the error, e.g.: http://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/40/steps/Building%20Images_1/logs/stdio so at the very least we need to update the documentation to include the requirement on gcc-multilib on things like Ubuntu 13.10 which appears to have the issue. 39575 16 srifenbark 2013-12-23 20:15:42 +0000 The inclusion of gcc_multilib as an essential package is already documented. I am resetting the doc flag here to "Done". I am not messing with the status of the bug because it is not assigned to me. Scott 39576 17 dvhart 2013-12-23 20:28:51 +0000 Thanks Scott. Yes, we should still try and sort out what changed with the gcc version to require this additional package - but at least for now people shouldn't trip over it when following the docs. 48664 18 jessica.zhang 2015-02-09 23:36:41 +0000 Close this since our doc will prevent people on hitting the issue