[v3] solaris c include model

[Marc Glisse]

On Thu, 12 Apr 2007, Benjamin Kosnik wrote:

> FYI I broke down and installed on x86 hardware with the solaris dev stuff, 
> after years of trying to get reliable access to sun hardware.
>
> It was an old-skool weekend for me, pushing solaris uphill and rocking out to 
> Run DMC on a boom box while wearing parachute pants. Remember when sushi was 
> this "new" kind of food? Ha.
>
> (I had a list of 15 things that bugged me about solaris in the first 30 
> minutes. For instance, will solaris coreutils always suck? Yes, apparently.)

They are planning to have a /usr/gnu/bin directory that you can just put 
at the beginning of your PATH to use the gnu tools by default. For now, 
the easiest way to go is simply configure blastwave (google for it if you 
don't know about it) and pkg-get -i all the packages you are missing from 
your usual linux box.
Also, don't hesitate to complain about all those things on the opensolaris 
fora, they keep asking for input on how to make solaris more attractive...

>>  * for qsort and bsearch, the problem comes from bug 2316. Your fix seems
>>    strange, you now declare (for recent __cplusplus) only the extern c++
>>    version of bsearch, which is defined nowhere. I would rather simply
>>    remove the extern "C++" declaration and keep the other one as is until
>>    2316 is fixed (not as violent as what I was mentionning in 30928. By
>>    the way 30928 shows an other approach that gives a more uniform result
>>    across solaris 8-11 but does not use the system headers as nicely as
>>    you are trying to do). If 2316 is fixed then an extern "C++" version of
>>    bsearch and qsort will need to be provided probably in libsupc++ or
>>    some such.
>
> Why does SunPro not complain about the clashing storage specifications here? 
> I guess I'm trying to figure out why Sun thinks this is ok (which they must, 
> as it's in the headers.) Can you parse out the logic going on here? Or, is 
> this a gcc bug?

This is gcc bug 2316. In C++, a C linkage function and a C++ linkage 
function are two completely different types. You therefore need to 
overload qsort so it can accept either one as a comparison function. g++ 
simply ignores the linkage in type comparisons. I think the same applies
to arrays as well as functions.

>>  * in math.h (for instance), you could #include <cmath> and #include_next
>>    <math.h>, not simply the second one (not sure right now why I wanted
>>    that, maybe just so cos(2) works after including math.h)
>
> This is confusing to me.
>
> When you say "math.h" you mean /usr/include/math.h, right?
>
> I was trying to not make major changes to the solaris headers, and instead do 
> as much work as possible in the C++ includes.

No, I actually meant that gcc could provide a math.h header that would 
simply do the 2 includes I was mentionning. Sorry for the confusion.

>>  * a number of things become useless in the headers since you assume
>>    solaris 7+ (like no stdlib.h or similar things)
>
> Can you give more detail here? I don't have much of an idea what changes in 
> solaris headers between 7,8,9,10 and 11. Is this documented by Sun anywhere?

I simply meant that the code in cstdlib that deals with the case when the
libc does not provide a stdlib.h header is useless for solaris.

But there are other differences.
I thought the use of namespace std appeared in solaris 8, but I don't
know. The parts protected by #if __cplusplus>=199711L appeared
progressively. They even changed in patches. For instance in solaris 9 I
can't see the overloads for qsort and bsearch. And a number of the math
function overloads were missing in solaris 8 at the beginning. I don't
have the lists available anywhere. That's why I had chosen in 30928 to
simply fixinclude-out all the overloads and rely on gcc to provide them.
But your approach is nicer and more similar to sunpro (which does not
provide everything on solaris 8).

> As this progresses, I'll update.

Thanks.

-- 
Marc Glisse