Am 18.12.2013 20:02 schrieb Jung-uk Kim j...@freebsd.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-12-17 05:56:01 -0500, Bernhard Fröhlich wrote:
On Tue, Dec 17, 2013 at 12:41 AM, Jung-uk Kim j...@freebsd.org
wrote:
On 2013-12-16 14:57:55 -0500, Bernhard Fröhlich 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)
___
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to freebsd-emulation-unsubscr...@freebsd.org
