[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
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Thu Dec 13 04:22:27 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233971
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 at FreeBSD.org
Reporter: sean.p.champ at 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 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 at 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.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ports-bugs
mailing list