Date: Wed, 18 Dec 2013 21:38:36 +0100 From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= <decke@FreeBSD.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: vbox@freebsd.org, Jason bacon <jwbacon@tds.net> Subject: Re: Problem with compat9x Message-ID: <CAE-m3X3k-C153bP1wT3xSALyiw4GxO6tEVM8JrijK0Fi3d%2BThg@mail.gmail.com> In-Reply-To: <52B1F157.7090009@FreeBSD.org> References: <52AF4676.3020102@tds.net> <CAE-m3X2RJQRr0BAPuvhCOsCXLyTYegO9REctWf8AP9yasUFnTw@mail.gmail.com> <52AF8F8D.7070103@FreeBSD.org> <CAE-m3X1Qr0L2c3w_enrB=i5M7rPxxjUX342qKKdNsE8bP%2BoB0g@mail.gmail.com> <52B1F157.7090009@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 18.12.2013 20:02 schrieb "Jung-uk Kim" <jkim@freebsd.org>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-12-17 05:56:01 -0500, Bernhard Fr=F6hlich wrote: > > On Tue, Dec 17, 2013 at 12:41 AM, Jung-uk Kim <jkim@freebsd.org> > > wrote: > >> On 2013-12-16 14:57:55 -0500, Bernhard Fr=F6hlich wrote: > >>> > >>> Yes I am aware of that and if you look at the commit history > >>> you will see that I have tried to fix that issue with the last > >>> commit. It has fixed the issue for a couple of vbox binaries > >>> (VBoxSVC, VBoxManage) but some are still broken. (VBoxHeadless, > >>> VirtualBox) > >>> > >>> The conflicts entry for compat9x was there already and I will > >>> need to add it again as it seems. > >> > >> BTW, I have a real fix for the problem, i.e., build with Clang > >> (well, as much as possible). In fact, only couple of files > >> (under src/recompiler) are absolutely needed to be compiled with > >> GCC in 4.3.x. Therefore, there is no need for libstdc++.so > >> dependency at all. > >> > >> Here are my experimental ports (based on official vbox@ ports, > >> i.e., https://redports.org/browser/virtualbox/emulators) > >> > >> http://redports.org/browser/jkim/emulators > > > > Probably I don't understand what you want to archive but I don't > > think patching virtualbox to compile 95% of it with clang and still > > having to compile the remaining 5% with gcc is of any benefit. > > % find VirtualBox-4.3.4 -type f \( -name "*.c" -or -name "*.cpp" \) | > wc -l > 6187 > % find VirtualBox-4.3.4/src/recompiler -type f \( -name "*.c" -or > - -name "*.cpp" \) | wc -l > 28 > > It's at least 99%. ;-) > > Seriously, my point is we need to reduce libstdc++.so dependency from > ports tree at all cost because '-rpath' is really asking for serious > trouble in the long run (*unless* the binary is completely > self-contained, of course), IMHO. I had very unpleasant experience > with LibreOffice and I learned it the hard way. Whatever I do with > the port, people always complained that something is broken in a weird > way. Almost every time, I found some *.so from its dependencies are > built with different C++ headers and runtime. Imagine you have foo.so > built with g++48 and bar.so built with g++46 and an executable built > with libc++.so and requiring them both, directly or indirectly, for > example. No fun at all. :-( Yes, I agree that it is a problem if we start mixing compilers. But wait we are already way past that point because we introduced clang as default compiler. There are quite a few more ports that break in strange ways because of that mix. > > We need to carry all the clang patches in our port which makes it a > > big beast and have likely no chance to get those workarounds > > included upstream because they won't accept patches for a compiler > > that can't fully build vbox. > > Patches are not too big. In fact, many patches are also beneficial to > GCC build because most of them fix compiler warnings with GCC, too. I > don't see any problem of submitting those patches. I have no problem to send patches which fix real problems but I don't want us to be like debian where people push boatloads of questionable patches on top of a 3rd party project. > Actually, the recompiler (based on ancient QEMU) must be updated to > remove GCC dependency in the first place, i.e., the infamous global > register, IMHO. FYI, recent QEMU can be built with Clang just fine. Yes I know about that and seriously the only way to get that done is by talking to upstream. If someone provides patches for that I would like to see them committed upstream first. The recompiler is a core part of vbox so I don't think we should be the testbed for such experiments just because we like to build stuff with clang. > > The issue that this thread talks about can be fixed in a much > > simpler way. In fact the VBoxHeadless and VirtualBox binaries do > > not have a RPATH at all - so all we need to do is fix the vbox > > buildsystem to add the RPATH to those binaries too like they > > already do for VBoxSVC and VBoxManage. > > Obviously, I do not agree with the "simpler" fix. ;-) It was the only fix I could provide in time for 10.0. Yes, rpath is not the magic bullet but it gives us time to work on better fixes. Please don't get me wrong. I am actually very happy with clang as a compiler and I use it also for some of my own code. But I still think it is the wrong choice for ports and we have created a lot of problems with that which will need a lot of our attention and time in the future. We are still depending very strong on the base compiler which we shouldn't. We are now adding hacks and crap like that rpath stuff or even heavily patch ports - for nothing! IMHO using a gcc48 as ports compiler would be the way to go. (this mail is my personal opinion)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-m3X3k-C153bP1wT3xSALyiw4GxO6tEVM8JrijK0Fi3d%2BThg>