From owner-freebsd-emulation@freebsd.org Fri Oct 16 01:11:46 2015 Return-Path: Delivered-To: freebsd-emulation@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1462A16FD6 for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC631585 for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8A2D3A16FD4; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) Delivered-To: emulation@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89C0DA16FD2 for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2311580 for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 6D36E12C4; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) Delivered-To: vbox@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by freefall.freebsd.org (Postfix) with ESMTP id 5420912C3 for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3ED6A157F for ; Fri, 16 Oct 2015 01:11:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t9G1BkSC085886 for ; Fri, 16 Oct 2015 01:11:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: vbox@FreeBSD.org Subject: [Bug 201132] emulators/virtualbox-ose-additions does not link on FreeBSD10.2 r284791M Date: Fri, 16 Oct 2015 01:11:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: z7dr6ut7gs@snkmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vbox@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 16 Oct 2015 02:16:46 +0000 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 01:11:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201132 --- Comment #3 from John Hein --- Well, I tested that assertion (in comment 1) by just manually calling the failed cc line that kmk spewed out with c++. Since that's not really useful for building the port, I dipped my toe into the inscrutable pool of kBuild and found a couple ways to work around the issue. Why someone decided the world needed yet another build system to decipher is beyond me (despite having read some of the rationale), not to mention why the virtualbox people chose it. But I digress... on to the hacking... (1) hack src/VBox/Additions/x11/VBoxClient/Makefile.kmk to force the linker command to be c++: --- src/VBox/Additions/x11/VBoxClient/Makefile.kmk.orig 2015-07-10 14:27:59.000000000 +0000 +++ src/VBox/Additions/x11/VBoxClient/Makefile.kmk 2015-10-15 17:04:01.248043000 +0000 @@ -22,6 +22,7 @@ # VBoxClient - clipboard and seamless. # PROGRAMS += VBoxClient +TOOL_GCC3_LD=c++ This doesn't feel right. It doesn't work if the kbuild machinery doesn't pick tools/GCC3.kmk (why / how kBuild selects tools/GCC3.kmk is one of the inscrutable kBuild mysteries - I had to do a lot of guesswork - the kBuild/kmk docs are not very helpful). It doesn't look like the virtualbox kBuild/kmk infrastructure supports this level of granular configurability very well. (2) add -lc++ with the change that pulled in -lcxxrt. --- src/VBox/Additions/x11/VBoxClient/Makefile.kmk.orig 2015-07-10 14:27:59.000000000 +0000 +++ src/VBox/Additions/x11/VBoxClient/Makefile.kmk 2015-10-15 17:07:28.320295000 +0000 @@ -50,7 +50,8 @@ # Xtst # These are static replacements for gcc-specific parts of libstdc++ VBoxClient_LIBS += \ - supc++ \ + cxxrt \ + c++ \ gcc_eh Just let the link use cc and and -lc++. This is pretty much all that linking with c++ (vs. cc) does anyway. This modification can be directly applied to emulators/virtualbox-ose/files/extrapatch-src-VBox-Additions-x11-VBoxClient-Makefile.kmk. Between (1) & (2), both work for building this version of the port on 10.2. If I were upstream, I'd figure out a way in the kmk infrastructure to support (1) (or replace kmk with something else). Linking a c++ program with the c++ compiler (vs. cc) is just more "correct". For FreeBSD ports, I'd pick (2) at this time. It's an easy change to an existing patch, and it is required specifically _because_ of that patch (which is currently only pulled in if the selected compiler is clang). Incidentally, I think this doesn't happen with 9.x, for instance, because it links with libsupc++ rather than libcxxrt. This does not require pulling in libstdc++, so linking with c++ is not necessary. I don't remember exactly when FreeBSD switched to clang++/libc++/libcxxrt from the gnu equivalents by default, but maybe that was between 10.1 and 10.2 and that's why it builds on 10.1 - I don't have a 10.1 to test that theory, but I thought 10.1 didn't have gcc by default, so that wouldn't explain why it builds on 10.1. Maybe your 10.1 system was built with gcc for the base compiler turned on or make.conf had a setting to prefer gcc? I'm completely guessing now, so I'll stop. -- You are receiving this mail because: You are the assignee for the bug.