GCC has internal multilib handling code but it assumes a very specific rigid directory layout. The build system implementation of multilib layout is very generic and allows complete customisation of the library directories. 64bithack.patch is a partial solution to allow any custom directories to be passed into gcc and handled correctly. It forces gcc to use the base_libdir (which is the current +directory, "."). We need to do this for each multilib that is configured as we don't know which compiler options may be being passed into the compiler. Since we have a compiler per mulitlib at this point that isn't an issue. The one problem is the target compiler is only going to work for the default multlilib at this point. Ideally we'd figure out which multilibs were being enabled with which paths and be able to patch these entries with a complete set of correct paths but this we don't have such code at this point. This is something the target gcc recipe should do and override these platform defaults in its build config.
I am looking into this now.
*** Bug 1549 has been marked as a duplicate of this bug. ***
Here are my commits for this feature which I did for 1.2 release. I have ported the commits it to 1.3 in this branch, but they may not be working yet. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=nitin/gcc-multilib-1.3
Bogdan, You can also work with Richard for this feature.
Bogdan, Radu, So what is the current status of this work now? The last I heard is that Bogdan rebased the previous code to gcc 4.7. but I did not see any code, or update after it.
(In reply to comment #5) > Bogdan, Radu, > So what is the current status of this work now? The last I heard is that > Bogdan rebased the previous code to gcc 4.7. but I did not see any code, or > update after it. Bogdan switched to some other work, I'll be taking care of this, but for now I didn't had time to look over. I'll post updates soon as I'll start investigation (I'll probably need to gather some info anyway to get started with it).
Agreed with Richard to move this to 1.4
I will be takink care of this as soon as I finish with with systemd. My initial estimation is 10 days but this will probably change once I get into it and clean up my view over this feature.
Patch merged. (commit 703b70c98a86771a891b46382f3ee20c4ef93f39) Cheers, Constantin
Hello, What should I add in local.conf in order to get a core-image-sato-sdk to test this? I added the following but got a "-sh: gcc: command not found" message: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = " lib32-gcc" NOTE: By adding the above lines in local.conf without the last one, I could not create 32 bit binaries on the x86-64 machine. Awaiting for input from Radu or Nitin.
Constantin is the right person to ask.
Build Configuration: BB_VERSION = "1.17.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Unknown" TARGET_SYS = "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "1.3+snapshot-20130409" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "master:02ae9b357676c904721d92a9c6f74ecc6b7a4476" Shell commands: root@qemux86-64:~# cat test.c #include <stdio.h> int main () { printf ("Hello World!\n"); } root@qemux86-64:~# gcc test.c -o test root@qemux86-64:~# file test test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=af4a65fde9035710493b8dad3212f4095e660b9a, not stripped root@qemux86-64:~# gcc -m64 test.c -o test root@qemux86-64:~# file test test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=af4a65fde9035710493b8dad3212f4095e660b9a, not stripped root@qemux86-64:~# gcc -m32 test.c -o test root@qemux86-64:~# file test test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=60066bf9f2ff17efcb7cb324df4c601bea0a57d1, not stripped
Hi, I tried the above suggestion for multilib support on current head release of yocto for machine x86-64. But it only create lib64 folder. Also while compiling for m32 i am getting mention below: sysroots/i686-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64 -poky-linux/gcc/x86_64-poky-linux/4.9.0/ld: skipping incompatible /home/atulk/X86_multilib/sysroots /core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.0//libgcc.a when searching for -lgcc /home/atulk/X86_multilib/sysroots/i686-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64 -poky-linux/gcc/x86_64-poky-linux/4.9.0/ld: skipping incompatible /home/atulk/X86_multilib/sysroots /core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.0/libgcc.a when searching for -lgcc /home/atulk/X86_multilib/sysroots/i686-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64 -poky-linux/gcc/x86_64-poky-linux/4.9.0/ld: cannot find -lgcc Please help me with your valuable suggestion on the same. Thanks and regards, Atul