Date: Thu, 13 Dec 2018 04:22:24 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 233971] emuators/virtualbox-ose (5.2.22) - Builds with LLVM 7; Error encountered during some of linking when building with GCC7, base system LD being LLD Message-ID: <bug-233971-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233971 Bug ID: 233971 Summary: emuators/virtualbox-ose (5.2.22) - Builds with LLVM 7; Error encountered during some of linking when building with GCC7, base system LD being LLD Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: sean.p.champ@gmail.com - Summary When building the port emulators/virtualbox-ose with GCC and with local LD = -- such that I believe may be installed as LLD from LLVM 6 in the FreeBSD 11.2 base system -- I was seeing the following error, and the port failed to bui= ld. When building with LLVM 7 from ports, the build completes successfully. There's some more detail about the site-local configuration below this exce= rpt.=20 ---- [...] kBuild: Linking iPxeBaseBin ld: error: unknown argument: --no-check-sections kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd= 64/release/obj/iPxeBaseBin/iPxeBaseBin] Error 1 The failing command: @ld -N --no-check-sections --gc-sections -T /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/src/VBox/Devices= /PC/ipxe/src/arch/i386/scripts/i386.lds -u _rom_start --defsym check__rom_start=3D_rom_start -u obj_config --defs= ym check_obj_config=3Dobj_config --defsym pci_vendor_id=3D0x8086 --defsym pci_device_id=3D0x100E -e _rom_start -m elf_i386_fbsd -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd6= 4/release/obj/iPxeBaseBin/iPxeBaseBin /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd6= 4/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o [...] /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd6= 4/release/obj/iPxeBaseBin/src/arch/i386/transitions/librm.o=20 kmk: *** Waiting for unfinished jobs.... filesplitter: Out of 79 files: 79 rewritten, 0 unchanged. (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd= 64/release/obj/VBoxAPIWrap) filesplitter: Out of 79 files: 79 rewritten, 0 unchanged. (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd= 64/release/obj/VBoxAPIWrap) kmk: *** Exiting with status 2 *** Error code 2 Stop. make[1]: stopped in /usr/ports/emulators/virtualbox-ose ---- After some searching along in the QA web, this seems that this error may resemble an issue that was addressed in the net/ipxe port at revision 447572 https://svnweb.freebsd.org/ports/head/net/ipxe/Makefile?view=3Dmarkup&pathr= ev=3D447572 ... with the change, "When ld is lld net/ipxe fails to build [...]" Guessing from the similarity in the error output, it seems that the local LD installed at the pathname /usr/bin/ld may happen to be LLD from LLVM 6 in t= he base system. So, using a conditional expression in /etc/make.conf I'd tried setting ld.b= fd as LD in the build -- being of an impression that that might provide someth= ing closer to GNU LD semantics -- then adding that specification to MAKE_ARGS f= or the port, to use /usr/local/llvm70/bin/ld.bfd as LD. The build still failed, though, with that same error.=20 I've not tried using an LD from the binutils port, as I've found a configuration that works out, without using GCC. Such that works out locally at least: I've disabled the conditional express= ion in site-local make.conf such that had been selecting GCC as the compiler toolchain when building */emulators/virtualbox-ose. After removing that conditional expression, LLVM 7 will now be used in the site-local build for virtualbox-ose. Subsequent of this local change, the build now successfully reaches the "kBuild: Linking ..." phase ... and completes successfully. So, it also bui= lds and links successfully with LLVM 7. I believe this may represent either or both of a bug and a workaround. The workaround, so far as at least in my own site-local configuration, appears = to be: Don't use GCC in the port build. Perhaps that might seem -- in effect -= - to overshadow the error of the build failure when using GCC (GCC7) and the base system LD. Concerning toolchain support, for the port build, so far as for supporting = GCC builds with base system LD (LLD?) in 11.2 for instance -- not to speculate, though I've not yet tried any such configuration successfully -- maybe there could be a way to adapt the port for using the binutils distribution of an = LD (??) when building with a toolchain-kind that fulfills "GCC".=20 Considering the change in net/ipxe it seems that there may be a workaround = for it when using GCC. Maybe that workaround could be found in using binutils L= D? Considering that the port build is no longer failing when using LLVM, candi= dly I'm not sure of how much of a bug it might seem to represent, as such. I thought it might be useful to mention this build failure anyway, in case an= yone else might run into it, and that there's a known workaround.=20 Perhaps there could be anyone else using GCC in the virtualbox-ose port bui= ld, and using what may be LLD installed as /usr/bin/ld. If the workaround of u= sing LLVM may not be sufficient, then if bintuils provides an alternate LD, perh= aps the build with GCC may succeed when using bintuils' LD. As my builds are not being run on a very fast machine, candidly I'm a little skeptical of whether or not I should try out the binutils LD workaround locally. The LLVM workaround is "Known good to go" afaict. Candidly, I look forward to trying out the DRM and KMS support for my Intel notebook's HW us= ing 11.2 now. More information about the site-local build: - Port Build Configuration I'm not sure of how much site-local configuration data may serve to provide= any relevant detail, here, as it seems that the error may not be specific to any one set of port build configuration options -- that is, except for the site-local selection of the compiler toolchain.=20 Of course, the normal port built configuration I've used it's stored under /var/ - could share the config here but perhaps in so much text it might se= em like, so to speak, "Line noise" - Local System Configuration Uname: FreeBSD riparian 11.2-RELEASE-p5 FreeBSD 11.2-RELEASE-p5 #0: Tue Nov= 27 09:33:52 UTC 2018=20=20=20=20 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Base system was built locally, using releng/11.2 branch src (originally retrieved via Github). Kernel is from FreeBSD-update for 11.2 as of this pa= st weekend. The details of this particular configuration may not be relevant in this issue, I assume, though I understand it might seem peculiar. Maybe my = own site-local config has sometimes seemed like something of of a till to maint= ain, candidly, but it's working out right now though. I believe the host was built with LLD as LD. Although I'm not longer setting that in /etc/src.conf but perhaps it might be a default setting in the base system builds with 11.2. As of some time not too long ago, I've been using GCC whenever building VirtualBox OSE and the kMod port. Those port builds had been completing successfully, when using the GCC toolchain.=20 Presently, I've also had to use GCC for building Perl 5.28 but certainly th= at should be addressed in a separate issue though. The kMod port build still completes successfully, under this configuration using GCC (GCC7). I haven't yet tried the kMod build with LLVM 7. I'd be happy to share my local make.conf without its annotations from so mu= ch site-local QA. Insofar as the conditional expression I've used in make.conf= for setting CC, CXX, and LD to a local default (LLVM 7 from ports), and then overriding that for some individual ports (GCC 7 from ports), perhaps the syntax of it may seem a little other than succinct.=20 - Ports State I was seeing that error when building from emulators/virtualbox-ose port so= urce code, current as of SVN revision r487272.=20 If I'm reading the 'svn log' cmd correctly, the local ports tree is also current as of r487272. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233971-7788>