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.
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.
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....
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"
Note also that the errors show up in do_install, since com32/ isn't built until then it seems... :/
Uhrm, that should be tf on IRC, not lp. I'll get some sleep now. :-)
(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.
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.
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
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.
Thanks for looking into this issue! I can reproduce that changing the /usr/bin/gcc symlink to gcc-4.7 makes it build.
*** Bug 5440 has been marked as a duplicate of this bug. ***
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?
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?
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.
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.
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
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.
Close this since our doc will prevent people on hitting the issue