1 |
On Saturday, April 30, 2016 01:32:54 AM Hans wrote: |
2 |
> On 30/04/16 00:28, Michael Mol wrote: |
3 |
> > On Friday, April 29, 2016 10:56:28 PM Hans wrote: |
4 |
> >> On 28/04/16 22:22, Hans wrote: |
5 |
> >> Kernel 4.4.6 as a bug. x11-drivers/xf86-video-virtualbox does not |
6 |
> >> compile. |
7 |
> >> Reason: |
8 |
> >> /usr/src/linux-4.4.6-gentoo/include/linux/string.h |
9 |
> >> 'char *strreplace(char *s, char old, char new);' causes compile failure. |
10 |
> >> "new" is a C++ keyword. |
11 |
> >> Changing tp 'char *strreplace(char *s, char oldstr, char newstr);' fixes |
12 |
> >> the problem. |
13 |
> > |
14 |
> > That's not a bug in the kernel per se, that's a bug in using that kernel |
15 |
> > header (written in C) in a compiler expecting C++ code. Which would make |
16 |
> > it a bug in xf86-video-virtualbox for not linking against a C-compiled |
17 |
> > object file. |
18 |
> > |
19 |
> > Granted, it'd be a heck of a lot more convenient if the kernel header |
20 |
> > files |
21 |
> > didn't use C++ keywords...but it *is* fundamentally a problem with |
22 |
> > compiling a source file using the wrong language. Like trying to read |
23 |
> > something in Portugese, except it was written in Spanish. It might work |
24 |
> > some of the time, but it'll catch you out eventually. |
25 |
> |
26 |
> The Virtualbox internal runtime compiler, assembler and gcc compiler to |
27 |
> build executables such as app-emulation/virtualbox-guest-additions, etc. |
28 |
> use some of the kernel sources and headers. |
29 |
|
30 |
Assuming those components are using this string.h header file, that just means |
31 |
that those components are correctly treating treating these header files as C |
32 |
header files, and not C++ header files. |
33 |
|
34 |
> |
35 |
> Kernel 4.1.12 string.h and earlier did not have this silly problem. |
36 |
|
37 |
That just means that Kernel 4.1.12 string.h and earlier weren't exposing a bug |
38 |
in xf86-video-virtualbox. |
39 |
|
40 |
The Linux kernel is written in C with a smattering of platform-specific |
41 |
assembler, and some other used languages at build time. The header files for |
42 |
Linux are written in C. It's built with a C compiler. It's expected to be |
43 |
consumed by things expecting to be consuming C. |
44 |
|
45 |
xf86-video-virtualbox is trying to build C code in a C++ environment, and |
46 |
that's not guaranteed to work. In fact, it's semantically broken, as C isn't |
47 |
simply a subset of C++, nor is C++ simply a superset of C. They're two |
48 |
distinct languages that can be made to work reliably together if you pay |
49 |
attention, and the VirtualBox developers...didn't. Linux promises a stable ABI |
50 |
for existing API calls, but the symbol name for an *argument* of an API call |
51 |
isn't part of the ABI; functions' arguments' names aren't preserved at compile |
52 |
time. Similarly, adding new API calls doesn't disrupt existing API calls or |
53 |
the ABI, so adding a new API call with an argument named 'new' doesn't violate |
54 |
that ABI promise. |
55 |
|
56 |
Now, an argument can be made that the kernel developers working in C shouldn't |
57 |
use C++ keywords, but that's a dangerous slippery slope; there are a *lot* of |
58 |
languages out there that are superficially syntactically (and even |
59 |
semantically) similar to C, but *aren't*. What makes C++ special enough that |
60 |
the kernel should respect it, but not every other language? No...userland is |
61 |
built around the kernel, not the other way around--that's what makes it the |
62 |
kernel. The kernel has a fairly well-defined set of rules in that it's written |
63 |
in a supremely common standardized language, and there exist good practices |
64 |
for interfacing code written in that language with code written in other |
65 |
languages. |
66 |
|
67 |
I get that it's frustrating. Just trying to help you understand what's going |
68 |
on a a lower level, and why. |
69 |
|
70 |
-- |
71 |
:wq |