[gentoo-user] Re: Kernel upgrade from 4.1.12 to 4.4.6 hangs without writing logs.

[Hans]

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);'