- 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 build. When building with LLVM 7 from ports, the build completes successfully. There's some more detail about the site-local configuration below this excerpt. ---- [...] kBuild: Linking iPxeBaseBin ld: error: unknown argument: --no-check-sections kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd64/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=_rom_start -u obj_config --defsym check_obj_config=obj_config --defsym pci_vendor_id=0x8086 --defsym pci_device_id=0x100E -e _rom_start -m elf_i386_fbsd -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd64/release/obj/iPxeBaseBin/iPxeBaseBin /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o [...] /usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/transitions/librm.o 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.amd64/release/obj/VBoxAPIWrap) filesplitter: Out of 79 files: 79 rewritten, 0 unchanged. (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-5.2.22/out/freebsd.amd64/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=markup&pathrev=447572 ... 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 the base system. So, using a conditional expression in /etc/make.conf I'd tried setting ld.bfd as LD in the build -- being of an impression that that might provide something closer to GNU LD semantics -- then adding that specification to MAKE_ARGS for the port, to use /usr/local/llvm70/bin/ld.bfd as LD. The build still failed, though, with that same error. 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 expression 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 builds 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". 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 LD? Considering that the port build is no longer failing when using LLVM, candidly 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 anyone else might run into it, and that there's a known workaround. Perhaps there could be anyone else using GCC in the virtualbox-ose port build, and using what may be LLD installed as /usr/bin/ld. If the workaround of using LLVM may not be sufficient, then if bintuils provides an alternate LD, perhaps 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 using 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. 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 seem 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 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 past 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 maintain, 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. Presently, I've also had to use GCC for building Perl 5.28 but certainly that 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 much 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. - Ports State I was seeing that error when building from emulators/virtualbox-ose port source code, current as of SVN revision r487272. If I'm reading the 'svn log' cmd correctly, the local ports tree is also current as of r487272.
What is the output of uname -a and ld --version ? @Ed Does this look like a bug 214864 blocker?
Any news here?
FreeBSD 11.2 was marked as deprecated, at some point. With the assistance of a thumb drive, I've updated to FreeBSD 12.1 subsequently. I've not seen any build failure for VirtualBox, since then. This, I presume, is a closed bug now. If any exposition may serve a whatsoever informative, albeit post hoc: My own build configuration may have introduced some quirks into the compiler tooclhain, from the base system build. Though I'm afraid I've not stored any exact log of the toolchain configuration I was using, at that time, it may have been after I'd stopped building binutils in the base system. I'm not certain how that may have affected the resulting toolchain, as I had not ever uninstalled the original binutils binaries, from whenever was the last time that I'd built binutils under the base system (November 2018? for GNU as, on one machine). After noticing some of the work about binutils under the FreeBSD master branch, looking forward to any subsequent updates there - will try to cherry-pick some of those changes to a local patch branch on releng/12.1, for purpose of testing. Furthermore, I'd been setting CPUTYPE in the build - using core2 such that I'd believed might have represented a common subset of functionality for the two machines that the builds were being used on. In retrospect, I'm not sure how well that may have actually worked out. It had not appeared locally, as an obvious concern, until trying to run the base system build under an earlier CPU architecture - with a core i7 CPU, namely. Possibly, it may have affected anything, in any quirky but less obvious way, up to this time. One of the machines is apparently using an ivybridge CPU, while the other has a broadwell CPU, beside this newer (older) i7 machine. Regardless, I'll try to manage my own CPUTYPE-specific builds more selectively, now, with some more hacks on the local make.conf. I'm certain it's a closed bug, by now - have been able to build virtualbox with clang 8.0.1 from the base system, using releng/12.1 src, even under what may be something of a badly hacked toolchain build.