On 02/05/16 22:59, Michael Mol wrote:
On Saturday, April 30, 2016 01:32:54 AM Hans wrote:
On 30/04/16 00:28, Michael Mol wrote:
On Friday, April 29, 2016 10:56:28 PM Hans wrote:
On 28/04/16 22:22, Hans wrote:
Kernel 4.4.6 as a bug. x11-drivers/xf86-video-virtualbox does not
compile.
Reason:
/usr/src/linux-4.4.6-gentoo/include/linux/string.h
'char *strreplace(char *s, char old, char new);' causes compile failure.
"new" is a C++ keyword.
Changing tp 'char *strreplace(char *s, char oldstr, char newstr);' fixes
the problem.
That's not a bug in the kernel per se, that's a bug in using that kernel
header (written in C) in a compiler expecting C++ code. Which would make
it a bug in xf86-video-virtualbox for not linking against a C-compiled
object file.
Granted, it'd be a heck of a lot more convenient if the kernel header
files
didn't use C++ keywords...but it *is* fundamentally a problem with
compiling a source file using the wrong language. Like trying to read
something in Portugese, except it was written in Spanish. It might work
some of the time, but it'll catch you out eventually.
The Virtualbox internal runtime compiler, assembler and gcc compiler to
build executables such as app-emulation/virtualbox-guest-additions, etc.
use some of the kernel sources and headers.
Assuming those components are using this string.h header file, that just means
that those components are correctly treating treating these header files as C
header files, and not C++ header files.
Kernel 4.1.12 string.h and earlier did not have this silly problem.
That just means that Kernel 4.1.12 string.h and earlier weren't exposing a bug
in xf86-video-virtualbox.
The Linux kernel is written in C with a smattering of platform-specific
assembler, and some other used languages at build time. The header files for
Linux are written in C. It's built with a C compiler. It's expected to be
consumed by things expecting to be consuming C.
xf86-video-virtualbox is trying to build C code in a C++ environment, and
that's not guaranteed to work. In fact, it's semantically broken, as C isn't
simply a subset of C++, nor is C++ simply a superset of C. They're two
distinct languages that can be made to work reliably together if you pay
attention, and the VirtualBox developers...didn't. Linux promises a stable ABI
for existing API calls, but the symbol name for an *argument* of an API call
isn't part of the ABI; functions' arguments' names aren't preserved at compile
time. Similarly, adding new API calls doesn't disrupt existing API calls or
the ABI, so adding a new API call with an argument named 'new' doesn't violate
that ABI promise.
Now, an argument can be made that the kernel developers working in C shouldn't
use C++ keywords, but that's a dangerous slippery slope; there are a *lot* of
languages out there that are superficially syntactically (and even
semantically) similar to C, but *aren't*. What makes C++ special enough that
the kernel should respect it, but not every other language? No...userland is
built around the kernel, not the other way around--that's what makes it the
kernel. The kernel has a fairly well-defined set of rules in that it's written
in a supremely common standardized language, and there exist good practices
for interfacing code written in that language with code written in other
languages.
I get that it's frustrating. Just trying to help you understand what's going
on a a lower level, and why.
Just checked Kernel-4.1.12 string.h.
The function declaration 'char *strreplace(char *s, char old, char
new);' does not exist at all.
The style of functions declarations used is
'char * strcpy(char *,const char *);'
except for 'char *strreplace(char *s, char old, char new);'
