VirtualBox build problem
Hi, The other Larry and I are struggling with a build problem for VirtualBox v7.0.2. When Oracle released 7.0.0_BETA3 on 28-Sep, it built correctly, but when 7.0.0 was released on 10-Oct, it failed with the following output: [ 1668s] kBuild: Linking VMMR0 [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: warning: setjmp.o: missing .note.GNU-stack section implies executable stack [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/VirtualBox-7.0.2/out/linux.amd64/release/lib/RuntimeR0.a(timesup.o): warning: relocation against `g_SUPGlobalInfoPage' in read-only section `.text' [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/VirtualBox-7.0.2/out/linux.amd64/release/obj/VMMR0/VMMAll/IEMAllAImpl.o: relocation R_X86_64_PC32 against symbol `g_afParity' can not be used when making a shared object; recompile with -fPIC [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: final link failed: bad value All the C and C++ parts have been compiled with -fPIC, and the assembler code uses the lea instruction to reference the global, which I think is relocatable. One additional fact is that doing the build using exactly the same parameters and make files from a console terminal works while the osc chroot or OBS builds fail. I checked that the same linker (/usr/bin/ld.bfd) is used in both cases. Any idea what changed the behavior of osc in early October, or what would be different in a chroot build than in a direct build? Thanks, Larry
On Friday 2022-11-04 19:13, Larry Finger wrote:
[ 1668s] kBuild: Linking VMMR0 [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: warning: setjmp.o: missing .note.GNU-stack section implies executable stack
All the C and C++ parts have been compiled with -fPIC, and the assembler code uses the lea instruction to reference the global, which I think is relocatable. [...] Any idea what changed the behavior of osc in early October, or what would be different in a chroot build than in a direct build?
When gcc is given a C/C++ source file and asked to produce assembly, it also generally emits the RO-stack request. But when you already have an assembly .S files (usually hand-crafted), it may be absent in error because $developer. See for example https://github.com/Adenilson/folly/commit/ccb905da2814484d942b3b06d288084dee...
On 11/4/22 14:52, Jan Engelhardt wrote:
When gcc is given a C/C++ source file and asked to produce assembly, it also generally emits the RO-stack request.
But when you already have an assembly .S files (usually hand-crafted), it may be absent in error because $developer.
See for example https://github.com/Adenilson/folly/commit/ccb905da2814484d942b3b06d288084dee...
Jan, Thanks for pointing me to solutions for the problem. After several tries to get the syntax correct. I discovered that the standard yasm, needed because some of the files are .asm and not .{S,s}, does not handle the .note.GNU-stack section. I found a patch published by RedHat and modified our version. That change is progressing through the system. So far, the builds are not yet fixed. One complication is that the build runs for 1400-1500 seconds before crashing, even with a 8-processor system, thus turnaround on changes takes a while. At least it is better than the old days with one run per day! Larry
Am Freitag, 4. November 2022, 19:13:42 CET schrieb Larry Finger:
Hi,
The other Larry and I are struggling with a build problem for VirtualBox v7.0.2.
When Oracle released 7.0.0_BETA3 on 28-Sep, it built correctly, but when 7.0.0 was released on 10-Oct, it failed with the following output:
[ 1668s] kBuild: Linking VMMR0 [ 1668s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: warning: setjmp.o: missing .note.GNU-stack section implies executable stack [ 1668s]
and rpmlint will raise badness above 10000 resulting in a failed build. Here's, how I fixed a similar issue in powermanga, where it failed the i586 builds only?!?: https://build.opensuse.org/package/view_file/games/powermanga/fix-exec-stack... Same solution as Jan provided, but hopefully a bit less obfuscated... Best, Pete -- Life without chameleons is possible, but pointless.
On 11/6/22 05:23, Hans-Peter Jansen wrote:
and rpmlint will raise badness above 10000 resulting in a failed build.
Here's, how I fixed a similar issue in powermanga, where it failed the i586 builds only?!?:
https://build.opensuse.org/package/view_file/games/powermanga/fix-exec-stack...
Same solution as Jan provided, but hopefully a bit less obfuscated...
Pete, Thanks for the link that shows the correct syntax for .{S,s} files. As you have likely seen in my response to Jan's E-mail, our version of yasm needed to be updated. Larry
participants (3)
-
Hans-Peter Jansen -
Jan Engelhardt -
Larry Finger