Linux Kernel include files

Linux Kernel include files

[Joerg Schilling]

Hi all,

you might know that since ~ 2 years, the Sun Studio compilers
are available for Linux. Given the fact that they typically produce
faster code than GCC and that they offer more debug/optimizing features,
they are worth testing.

While it is no problem to use Sun Studio for non-Linux-specific programs,
it is impossible to compile programs using Sun Studio if these programs offer
Linux specific features.

Star ftp://ftp.berlios.de/pub/star/alpha/ offers support for archiving ext2
file flags. If star is compiled using Sun Studio, star's autoconfiguration will 
disable support for the Linux specific features because it detects "broken" 
include files.

Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS 
dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI 
transport, so it is impossible to use Sun Studio to compile cdrtools.

Why does this happen?

Well, the reason is that in order to support Linux specific features, you need 
to include Linux specific include files (the Linux kernel include files). As 
these include files are currently not written in vanilla (ANSI) C but in a 
GCC-C-variant, other compilers do not like these include files.

Is there some hope that at least the Linux kernel interface definition files and
everything recursively included from these files will be rewritten in vanilla 
ANSI C?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[david]

On Fri, 22 Jun 2007, Joerg Schilling wrote:

> Is there some hope that at least the Linux kernel interface definition files and
> everything recursively included from these files will be rewritten in vanilla
> ANSI C?

this has been discussed many times and the answer is that the kernel is 
not gong to change it's side of things to ANSI C.

that doesn't mean that one of the many projects out there to create 
seperate interface headers won't do this.

however, there is another interesting thing going on at the moment. The 
standards commity is currently deciding what will be in the next rev of 
the C specs (tentitivly labels C1x for discussions, they are hopeing to 
release them in '09 or '10)

some of the things that are GCC extentions are going to be added to the 
spec (ahtough possibly with a change to the syntax)

so now is the time to talk to your local reps who go to these meetings and 
make your suggestions for what should be added to the standard and what 
should not be.

remember that anything to be added must be implemented somehwere, 
preferrably by multiple seperate compilers.

David Lang

Re: Linux Kernel include files

[Joerg Schilling]

david@lang.hm wrote:

> On Fri, 22 Jun 2007, Joerg Schilling wrote:
>
> > Is there some hope that at least the Linux kernel interface definition files and
> > everything recursively included from these files will be rewritten in vanilla
> > ANSI C?
>
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.
>
> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.

The main problems are not really hard to fix......

-	Most problems eem to be related to the fact that Linux does not
	use C-99 based types in the kernel and the related type definitions 
	are not written in plain C. This is something that should be fixed
	with a source consolidation program or by defining aliases to 
	C-99 types in case the compiler is not GCC.

-	Other problems are caused by additional tag definitions that could
	be disabled in case of a non-GCC compile.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Arjan van de Ven]

> Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS 
> dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI 
> transport, so it is impossible to use Sun Studio to compile cdrtools.
> 
> Why does this happen?
> 
> Well, the reason is that in order to support Linux specific features, you need 
> to include Linux specific include files (the Linux kernel include files).


I assume you typoed and meant "cleaned up kernel include files as
installed by make headers_install" instead.

>  As 
> these include files are currently not written in vanilla (ANSI) C but in a 
> GCC-C-variant, other compilers do not like these include files.

can you give a specific example of a header installed by make
headers_install that breaks this way and is hurting you? Because it may
well be possible to fix the problems, now that we have this special
cleanup phase since several releases....

Re: Linux Kernel include files

[Arnd Bergmann]

On Friday 22 June 2007, david@lang.hm wrote:
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.

I don't think that's entirely true with regard to the include files.
We have always tried not to step on anyone's toes there, e.g. regarding
the use of __u32 vs. uint32_t style types. It's certainly desirable
to make the kernel headers that are _meant_ for inclusion compatible
with standard compilers.

Mike Frysinger has posted a few patches that make the installed headers
friendlier to strict C99 users. While there was some negative feedback
about these patches, it was not about the idea of making the installed
headers C99 clean, but rather about the question whether those non-clean
parts should be exported in the first place.

Now whether a specific header file should be installed and potentially
included in user space is certainly debatable in many cases, but at
least it's now clearly defined through the include/*/Kbuild files.
If someone has a good reason to change which files are exported, he
should simply submit a patch against the list of exported files.

> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.

Those projects are all practically dead, since we have the
'make headers_install' target in the Linux source.

	Arnd <><

Re: Linux Kernel include files

[David Woodhouse]

On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> The main problems are not really hard to fix......
> 
> -	Most problems eem to be related to the fact that Linux does not
> 	use C-99 based types in the kernel and the related type definitions 
> 	are not written in plain C. This is something that should be fixed
> 	with a source consolidation program or by defining aliases to 
> 	C-99 types in case the compiler is not GCC.


The argument has been made that the standard C99 types are _optional_,
and anything included from a C library's headers without _explicitly_
being included by the user shouldn't define those types.

Personally, I think that's a load of bollocks. And it certainly doesn't
apply to Linux-specific files like <linux/cdrom.h>, which are perfectly
entitled to use a C standard from last millennium, regardless of
namespace 'pollution' issues. That's why we continue to use the crappy
__u32 types. Can you be more specific about why this is a problem? Don't
we mostly define those crappy types using arch-specific knowledge, as
'int', 'long', etc?

> -	Other problems are caused by additional tag definitions that could
> 	be disabled in case of a non-GCC compile.

We mostly try to remove this from user-visible parts of exported
headers. Sometimes we just remove it altogether; other bits are stripped
at export time when you run 'make headers_install'. Again, can you be
more specific about the problem?

-- 
dwmw2

Re: Linux Kernel include files

[H. Peter Anvin]

David Woodhouse wrote:
>> The main problems are not really hard to fix......
>>
>> -	Most problems eem to be related to the fact that Linux does not
>> 	use C-99 based types in the kernel and the related type definitions 
>> 	are not written in plain C. This is something that should be fixed
>> 	with a source consolidation program or by defining aliases to 
>> 	C-99 types in case the compiler is not GCC.
> 
> 
> The argument has been made that the standard C99 types are _optional_,
> and anything included from a C library's headers without _explicitly_
> being included by the user shouldn't define those types.
> 
> Personally, I think that's a load of bollocks. And it certainly doesn't
> apply to Linux-specific files like <linux/cdrom.h>, which are perfectly
> entitled to use a C standard from last millennium, regardless of
> namespace 'pollution' issues. That's why we continue to use the crappy
> __u32 types. Can you be more specific about why this is a problem? Don't
> we mostly define those crappy types using arch-specific knowledge, as
> 'int', 'long', etc?
> 

It definitely does hurt when using those types in files that may want to
be used by the C library (as opposed to the end user.)

However, there is no reason why there should be anything funny about the
declaration of those types.

	-hpa

Re: Linux Kernel include files

[Adrian Bunk]

On Fri, Jun 22, 2007 at 11:38:47AM +0800, David Woodhouse wrote:
> On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> > The main problems are not really hard to fix......
> > 
> > -	Most problems eem to be related to the fact that Linux does not
> > 	use C-99 based types in the kernel and the related type definitions 
> > 	are not written in plain C. This is something that should be fixed
> > 	with a source consolidation program or by defining aliases to 
> > 	C-99 types in case the compiler is not GCC.
> 
> 
> The argument has been made that the standard C99 types are _optional_,
> and anything included from a C library's headers without _explicitly_
> being included by the user shouldn't define those types.
> 
> Personally, I think that's a load of bollocks. And it certainly doesn't
> apply to Linux-specific files like <linux/cdrom.h>, which are perfectly
> entitled to use a C standard from last millennium, regardless of
> namespace 'pollution' issues. That's why we continue to use the crappy
> __u32 types. Can you be more specific about why this is a problem? Don't
> we mostly define those crappy types using arch-specific knowledge, as
> 'int', 'long', etc?
>...

It would certainly help if Joerg would tell what exactly breaks, but I 
spot one likely problem in include/asm-i386/types.h:

#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif

It might make sense to remove the #if and simply require that
a C compiler under Linux must know about the C99 "long long"?

> dwmw2

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux Kernel include files

[Joerg Schilling]

david@lang.hm wrote:

> On Fri, 22 Jun 2007, Joerg Schilling wrote:
>
> > Is there some hope that at least the Linux kernel interface definition files and
> > everything recursively included from these files will be rewritten in vanilla
> > ANSI C?
>
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.

Well, there is no need to go to ANSI C as pre-ANSI would to it also.
The problem is non ANSI gcc extensions.

> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.
>
> however, there is another interesting thing going on at the moment. The 
> standards commity is currently deciding what will be in the next rev of 
> the C specs (tentitivly labels C1x for discussions, they are hopeing to 
> release them in '09 or '10)
>
> some of the things that are GCC extentions are going to be added to the 
> spec (ahtough possibly with a change to the syntax)

This may make sense after it did happen, but it does not help today.

> so now is the time to talk to your local reps who go to these meetings and 
> make your suggestions for what should be added to the standard and what 
> should not be.
>
> remember that anything to be added must be implemented somehwere, 
> preferrably by multiple seperate compilers.

Using plain C in the Linux kernel include files would be sufficient for all
compilers that make sense to be supported.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Joerg Schilling]

Arjan van de Ven <arjan@infradead.org> wrote:

>
> > Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS 
> > dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI 
> > transport, so it is impossible to use Sun Studio to compile cdrtools.
> > 
> > Why does this happen?
> > 
> > Well, the reason is that in order to support Linux specific features, you need 
> > to include Linux specific include files (the Linux kernel include files).
>
>
> I assume you typoed and meant "cleaned up kernel include files as
> installed by make headers_install" instead.

I am thinking about kernel include files that do correct preincludes for
type-cleanness and that work if you use them without #defining __KERNEL_

> >  As 
> > these include files are currently not written in vanilla (ANSI) C but in a 
> > GCC-C-variant, other compilers do not like these include files.
>
> can you give a specific example of a header installed by make
> headers_install that breaks this way and is hurting you? Because it may
> well be possible to fix the problems, now that we have this special
> cleanup phase since several releases....

star needs "ext2_fs.h". This file is not usable at all on many Linux 
distributions, even with GCC.

libscg (cdrtools) needs "scsi/sg.h" but it currently includes a lot of other
files:

scsi-linux-sg.c:#include <linux/version.h>
scsi-linux-sg.c:#include <asm/types.h>
scsi-linux-sg.c:#include <scsi/scsi.h>
scsi-linux-sg.c:#include <linux/scsi.h>
scsi-linux-sg.c:#include <linux/fs.h>           /* From ancient versions, really needed? */
scsi-linux-sg.c:#include "block/blk.h"          /* From ancient versions, really needed? */
scsi-linux-sg.c:#include "scsi/scsi.h"
scsi-linux-sg.c:#include "scsi/sg.h"
scsi-linux-sg.c:#include <linux/cdrom.h>

If there wase _one_ clean SCSI pass through interface on Linux,
things would be a lot easier.....


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Joerg Schilling]

Arnd Bergmann <arnd@arndb.de> wrote:

> On Friday 22 June 2007, david@lang.hm wrote:
> > this has been discussed many times and the answer is that the kernel is 
> > not gong to change it's side of things to ANSI C.
>
> I don't think that's entirely true with regard to the include files.
> We have always tried not to step on anyone's toes there, e.g. regarding
> the use of __u32 vs. uint32_t style types. It's certainly desirable
> to make the kernel headers that are _meant_ for inclusion compatible
> with standard compilers.
>
> Mike Frysinger has posted a few patches that make the installed headers
> friendlier to strict C99 users. While there was some negative feedback
> about these patches, it was not about the idea of making the installed
> headers C99 clean, but rather about the question whether those non-clean
> parts should be exported in the first place.

Wouldn't it be simpler to ask the developers to deliver their include files
in a state that is clean for user space programs?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Joerg Schilling]

David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> > The main problems are not really hard to fix......
> > 
> > -	Most problems eem to be related to the fact that Linux does not
> > 	use C-99 based types in the kernel and the related type definitions 
> > 	are not written in plain C. This is something that should be fixed
> > 	with a source consolidation program or by defining aliases to 
> > 	C-99 types in case the compiler is not GCC.
>
>
> The argument has been made that the standard C99 types are _optional_,
> and anything included from a C library's headers without _explicitly_
> being included by the user shouldn't define those types.

????

This uses double negation and is close to unreadable.

A kernel include file that defines an interface to a user space program
should be self containing (that means that all includes for all non-standard
types should be done inside these include files). Whether or not C-99 
types are used or not is less important than to use type definitions written 
in clean C so compilers other than gcc may use them.

> Personally, I think that's a load of bollocks. And it certainly doesn't
> apply to Linux-specific files like <linux/cdrom.h>, which are perfectly
> entitled to use a C standard from last millennium, regardless of
> namespace 'pollution' issues. That's why we continue to use the crappy
> __u32 types. Can you be more specific about why this is a problem? Don't
> we mostly define those crappy types using arch-specific knowledge, as
> 'int', 'long', etc?

I recommend you to install Sun Studio and to try to compile star or cdrtools
using Sun Studio by calling "make CCOM_suncc".

ftp://ftp.berlios.de/pub/star/alpha/
ftp://ftp.berlios.de/pub/cdrecord/alpha/

You may need to hand edit the file incs/<arch-dir>/{xconfig.h!rules.conf}

in order to enable the auto-disabled features.

In any case, self reading the error messages from Sun Studio helps more than
trying to discuss it.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Arjan van de Ven]

> > I assume you typoed and meant "cleaned up kernel include files as
> > installed by make headers_install" instead.
> 
> I am thinking about kernel include files that do correct preincludes for
> type-cleanness and that work if you use them without #defining __KERNEL_

there is no __KERNEL__ in the "make headers_install"'d kernel headers.
And they are more or less sanity checked (no sanity check is complete
obviously) against certain common errors already (like including headers
that aren't installed).

if sanity checks are missing (and you seem to imply they do) then I'm
sure David welcomes suggestions for new sanity checks.
> > can you give a specific example of a header installed by make
> > headers_install that breaks this way and is hurting you? Because it may
> > well be possible to fix the problems, now that we have this special
> > cleanup phase since several releases....
> 
> star needs "ext2_fs.h". This file is not usable at all on many Linux 
> distributions, even with GCC.

oh I thought we were talking about the kernel, not about distributions.
Again, did you check the output of "make headers_install" (this is what
distributions are using going forward), and if so, can you give
*specific* examples of what we should add checks and fixes for?



-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: Linux Kernel include files

[Robert P. J. Day]

On Mon, 25 Jun 2007, Arjan van de Ven wrote:

> there is no __KERNEL__ in the "make headers_install"'d kernel headers.

not quite technically true, as "unifdef" isn't smart enough to factor
out __KERNEL__ if it's part of a larger, logical expression involving
the "||" operator.  but that's being admittedly nitpicky.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Linux Kernel include files

[David Woodhouse]

On Mon, 2007-06-25 at 17:17 +0200, Joerg Schilling wrote:
> David Woodhouse <dwmw2@infradead.org> wrote:
> > On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> A kernel include file that defines an interface to a user space program
> should be self containing (that means that all includes for all non-standard
> types should be done inside these include files). Whether or not C-99 
> types are used or not is less important than to use type definitions written 
> in clean C so compilers other than gcc may use them.

Yes. In general we try to achieve this. Most header files should include
<asm/types.h>, which tends to define the types we use in terms which
should work in any compiler.

> >  Can you be more specific about why this is a problem? Don't
> > we mostly define those crappy types using arch-specific knowledge, as
> > 'int', 'long', etc?
> 
> I recommend you to install Sun Studio and to try to compile star or cdrtools
> using Sun Studio by calling "make CCOM_suncc".
>
> ftp://ftp.berlios.de/pub/star/alpha/
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> 
> You may need to hand edit the file incs/<arch-dir>/{xconfig.h!rules.conf}
> 
> in order to enable the auto-disabled features.
> 
> In any case, self reading the error messages from Sun Studio helps more than
> trying to discuss it.

I have no interest in doing this for myself, and I suspect that if I
tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
anyway. Please just show the error messages.

-- 
dwmw2

Re: Linux Kernel include files

[david]

On Mon, 25 Jun 2007, Joerg Schilling wrote:

> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Friday 22 June 2007, david@lang.hm wrote:
>>> this has been discussed many times and the answer is that the kernel is
>>> not gong to change it's side of things to ANSI C.
>>
>> I don't think that's entirely true with regard to the include files.
>> We have always tried not to step on anyone's toes there, e.g. regarding
>> the use of __u32 vs. uint32_t style types. It's certainly desirable
>> to make the kernel headers that are _meant_ for inclusion compatible
>> with standard compilers.
>>
>> Mike Frysinger has posted a few patches that make the installed headers
>> friendlier to strict C99 users. While there was some negative feedback
>> about these patches, it was not about the idea of making the installed
>> headers C99 clean, but rather about the question whether those non-clean
>> parts should be exported in the first place.
>
> Wouldn't it be simpler to ask the developers to deliver their include files
> in a state that is clean for user space programs?

that's what make headers_install does, as others have pointed out.

David Lang

Re: Linux Kernel include files

[Harald Arnesen]

David Woodhouse <dwmw2@infradead.org> writes:

>> >  Can you be more specific about why this is a problem? Don't
>> > we mostly define those crappy types using arch-specific knowledge, as
>> > 'int', 'long', etc?
>> 
>> I recommend you to install Sun Studio and to try to compile star or cdrtools
>> using Sun Studio by calling "make CCOM_suncc".
>>
>> ftp://ftp.berlios.de/pub/star/alpha/
>> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>> 
>> You may need to hand edit the file incs/<arch-dir>/{xconfig.h!rules.conf}
>> 
>> in order to enable the auto-disabled features.
>> 
>> In any case, self reading the error messages from Sun Studio helps more than
>> trying to discuss it.
>
> I have no interest in doing this for myself, and I suspect that if I
> tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
> anyway. Please just show the error messages.

Apart from the usual whining about GNU make, the error message is:
make: *** No rule to make target `CCOM_suncc'.  Stop.

If I actually install smake, as Jörg recommends, the message becomes:
smake: Can't find any source for 'CCOM_suncc'.
smake: Couldn't make 'CCOM_suncc'.
-- 
Hilsen Harald.

Re: Linux Kernel include files

[Sam Ravnborg]

On Mon, Jun 25, 2007 at 04:53:55PM +0200, Joerg Schilling wrote:
> 
> star needs "ext2_fs.h". This file is not usable at all on many Linux 
> distributions, even with GCC.

I was curious so I did:

$ mkdir ~/foo
$ cd ~/kernel/linux-2.6
$ make INSTALL_HDR_PATH=~/foo
$ cd ~/foo
$ cat j.c
#include <stdio.h>
#include "etx2_fs.h"

main()
{
	printf("helloo\n");
}

$ gcc -o j j.c
=> No warning, no errors

$ gcc -ansi -pedantic -o j j.c
In file included from j.c:2:
ext2_fs.h:53:25: warning: ISO C does not permit named variadic macros

$ gcc -ansi -pedantic -std=c99 -o j j.c
In file included from j.c:2:
ext2_fs.h:53:25: warning: ISO C does not permit named variadic macros
j.c:5: warning: return type defaults to ‘int’

Is it this part you are referring to in the above or have I overlooked something?

	Sam

Re: Linux Kernel include files

[Joerg Schilling]

Harald Arnesen <harald@skogtun.org> wrote:

> David Woodhouse <dwmw2@infradead.org> writes:
>
> >> >  Can you be more specific about why this is a problem? Don't
> >> > we mostly define those crappy types using arch-specific knowledge, as
> >> > 'int', 'long', etc?
> >> 
> >> I recommend you to install Sun Studio and to try to compile star or cdrtools
> >> using Sun Studio by calling "make CCOM_suncc".
> >>
> >> ftp://ftp.berlios.de/pub/star/alpha/
> >> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >> 
> >> You may need to hand edit the file incs/<arch-dir>/{xconfig.h!rules.conf}
> >> 
> >> in order to enable the auto-disabled features.
> >> 
> >> In any case, self reading the error messages from Sun Studio helps more than
> >> trying to discuss it.
> >
> > I have no interest in doing this for myself, and I suspect that if I
> > tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
> > anyway. Please just show the error messages.
>
> Apart from the usual whining about GNU make, the error message is:
> make: *** No rule to make target `CCOM_suncc'.  Stop.
>
> If I actually install smake, as Jörg recommends, the message becomes:
> smake: Can't find any source for 'CCOM_suncc'.
> smake: Couldn't make 'CCOM_suncc'.

Well, I was in hope that a small typo (in special as the correct spelling is in 
the file README.compile) should not be a problem.

You need to use CCOM=suncc 

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[David Woodhouse]

On Mon, 2007-06-25 at 22:26 +0200, Joerg Schilling wrote:
> Well, I was in hope that a small typo (in special as the correct
> spelling is in the file README.compile) should not be a problem.
> 
> You need to use CCOM=suncc 

No, I need someone else to use CCOM=suncc for me. Unless suncc works on
Linux/PowerPC _and_ you find me a few extra hours in the day to deal
with bugs for someone who can't even be bothered to write a coherent bug
report.

-- 
dwmw2

Re: Linux Kernel include files

[Harald Arnesen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 544 bytes --]

Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:

>> If I actually install smake, as Jörg recommends, the message becomes:
>> smake: Can't find any source for 'CCOM_suncc'.
>> smake: Couldn't make 'CCOM_suncc'.
>
> Well, I was in hope that a small typo (in special as the correct spelling is in 
> the file README.compile) should not be a problem.
>
> You need to use CCOM=suncc 

Then it (star, I haven't tried cdrtools yes) compiles and links fine.
There must be something wrong with your Linux installation.
-- 
Hilsen Harald.

Re: Linux Kernel include files

[Harald Arnesen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 670 bytes --]

Harald Arnesen <harald@skogtun.org> writes:

> Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:
>
>>> If I actually install smake, as Jörg recommends, the message becomes:
>>> smake: Can't find any source for 'CCOM_suncc'.
>>> smake: Couldn't make 'CCOM_suncc'.
>>
>> Well, I was in hope that a small typo (in special as the correct spelling is in 
>> the file README.compile) should not be a problem.
>>
>> You need to use CCOM=suncc 
>
> Then it (star, I haven't tried cdrtools yes) compiles and links fine.
> There must be something wrong with your Linux installation.

FYI, cdrtools also compile and link fine with Sun's C compiler.
-- 
Hilsen Harald.

Re: Linux Kernel include files

[Joerg Schilling]

Harald Arnesen <harald@skogtun.org> wrote:

> Harald Arnesen <harald@skogtun.org> writes:
>
> > Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:
> >
> >>> If I actually install smake, as Jörg recommends, the message becomes:
> >>> smake: Can't find any source for 'CCOM_suncc'.
> >>> smake: Couldn't make 'CCOM_suncc'.
> >>
> >> Well, I was in hope that a small typo (in special as the correct spelling is in 
> >> the file README.compile) should not be a problem.
> >>
> >> You need to use CCOM=suncc 
> >
> > Then it (star, I haven't tried cdrtools yes) compiles and links fine.
> > There must be something wrong with your Linux installation.
>
> FYI, cdrtools also compile and link fine with Sun's C compiler.

Mmmmm, if you call "cdrecord -scanbus", what do you get?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Harald Arnesen]

Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:

>> FYI, cdrtools also compile and link fine with Sun's C compiler.
>
> Mmmmm, if you call "cdrecord -scanbus", what do you get?

I may have misunderstood your make system. I cd-ed into the cdrtools
directory, ran ./Gmake.linux clean (I had already compiled with GCC),
and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of
the make output.

However, what confused me was that the cdrecord binary wasn't removed.
And scrolling back, I see several compile errors from Sun's C compiler.

Shouldn't "make clean" remove the executable files?
-- 
Hilsen Harald.

Re: Linux Kernel include files

[Joerg Schilling]

Harald Arnesen <harald@skogtun.org> wrote:

> Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:
>
> >> FYI, cdrtools also compile and link fine with Sun's C compiler.
> >
> > Mmmmm, if you call "cdrecord -scanbus", what do you get?
>
> I may have misunderstood your make system. I cd-ed into the cdrtools
> directory, ran ./Gmake.linux clean (I had already compiled with GCC),
> and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of
> the make output.
>
> However, what confused me was that the cdrecord binary wasn't removed.
> And scrolling back, I see several compile errors from Sun's C compiler.
>
> Shouldn't "make clean" remove the executable files?

make clean only removes the *.o files.

If you call "make relink", all results are removed before recreating.

BTW: your problem is caused by a "bash" bug. With a shell that correctly
works with "sh -ce 'command...'", you would see an abort after the first
error.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[H. Peter Anvin]

Adrian Bunk wrote:
> 
> It would certainly help if Joerg would tell what exactly breaks, but I 
> spot one likely problem in include/asm-i386/types.h:
> 
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> typedef __signed__ long long __s64;
> typedef unsigned long long __u64;
> #endif
> 
> It might make sense to remove the #if and simply require that
> a C compiler under Linux must know about the C99 "long long"?
> 

Yes.

	-hpa

Re: Linux Kernel include files

[Kyle Moffett]

On Jun 22, 2007, at 11:00:38, Adrian Bunk wrote:
> It would certainly help if Joerg would tell what exactly breaks,  
> but I spot one likely problem in include/asm-i386/types.h:
>
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> typedef __signed__ long long __s64;
> typedef unsigned long long __u64;
> #endif
>
> It might make sense to remove the #if and simply require that a C  
> compiler under Linux must know about the C99 "long long"?

Gah, this particular topic and a few other similar header- 
compatibility ones show up once a month on LKML; I should probably  
just make a patch to fix all the types.h files and be done with it.   
The proper solution is this:

# if __STDC_VERSION__ >= 19901L
typedef   signed long long __s64;
typedef unsigned long long __u64;
# elif defined(__GNUC__)
__extension__ typedef   signed long long __s64;
__extension__ typedef unsigned long long __u64;
# else
#  error "Your compiler doesn't support long long (IOW: It sucks).   
Please get a new one"
# endif

That way if you have any kind of vaguely-long-long-compatible  
compiler then it will work, and otherwise you'll get a nice useful  
error message.  It also makes sure that GCC doesn't spew warnings/ 
errors when in c89-pedantic mode.  The "__extension__" keyword is  
designed for use in implementation header files which want to use GCC- 
isms unconditionally.

Cheers,
Kyle Moffett

Re: Linux Kernel include files

[Adrian Bunk]

On Tue, Jun 26, 2007 at 09:32:39PM -0400, Kyle Moffett wrote:
> On Jun 22, 2007, at 11:00:38, Adrian Bunk wrote:
>> It would certainly help if Joerg would tell what exactly breaks, but I 
>> spot one likely problem in include/asm-i386/types.h:
>>
>> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>> typedef __signed__ long long __s64;
>> typedef unsigned long long __u64;
>> #endif
>>
>> It might make sense to remove the #if and simply require that a C compiler 
>> under Linux must know about the C99 "long long"?
>
> Gah, this particular topic and a few other similar header-compatibility 
> ones show up once a month on LKML; I should probably just make a patch to 
> fix all the types.h files and be done with it.  The proper solution is 
> this:
>
> # if __STDC_VERSION__ >= 19901L
> typedef   signed long long __s64;
> typedef unsigned long long __u64;
> # elif defined(__GNUC__)
> __extension__ typedef   signed long long __s64;
> __extension__ typedef unsigned long long __u64;
> # else
> #  error "Your compiler doesn't support long long (IOW: It sucks).  Please 
> get a new one"

This part is wrong.

gcc supported "long long" before C99 existed.
And Joerg said the Sun cc supported "long long" before gcc did.

> # endif
>
> That way if you have any kind of vaguely-long-long-compatible compiler then 
> it will work, and otherwise you'll get a nice useful error message.

No, consider a pre-C99 gcc version that supports "long long".

> It 
> also makes sure that GCC doesn't spew warnings/errors when in c89-pedantic 
> mode.  The "__extension__" keyword is designed for use in implementation 
> header files which want to use GCC-isms unconditionally.

That's a good point I missed.

What about:

#if defined(__GNUC__) && __STDC_VERSION__ < 19901L
__extension__ typedef   signed long long __s64;
__extension__ typedef unsigned long long __u64;
#else
typedef   signed long long __s64;
typedef unsigned long long __u64;
#endif

> Cheers,
> Kyle Moffett

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux Kernel include files

[Joerg Schilling]

Adrian Bunk <bunk@stusta.de> wrote:

> That's a good point I missed.
>
> What about:
>
> #if defined(__GNUC__) && __STDC_VERSION__ < 19901L
> __extension__ typedef   signed long long __s64;
> __extension__ typedef unsigned long long __u64;
> #else
> typedef   signed long long __s64;
> typedef unsigned long long __u64;
> #endif

What about using:

#if (defined(__GNUC__) || defined(__SUNPRO_C)) && !defined(__STRICT_ANSI__) 

Well, there seems to be one other compiler (the one from Intel).
It may be that if this compiler does not claim to be GCC, another
definituion needs to be added.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Linux Kernel include files

[Robert P. J. Day]

On Wed, 27 Jun 2007, Joerg Schilling wrote:

> Adrian Bunk <bunk@stusta.de> wrote:
>
> > That's a good point I missed.
> >
> > What about:
> >
> > #if defined(__GNUC__) && __STDC_VERSION__ < 19901L
> > __extension__ typedef   signed long long __s64;
> > __extension__ typedef unsigned long long __u64;
> > #else
> > typedef   signed long long __s64;
> > typedef unsigned long long __u64;
> > #endif
>
> What about using:
>
> #if (defined(__GNUC__) || defined(__SUNPRO_C)) && !defined(__STRICT_ANSI__)
>
> Well, there seems to be one other compiler (the one from Intel).
> It may be that if this compiler does not claim to be GCC, another
> definituion needs to be added.

the intel compiler does indeed claim to be gcc.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Userspace compiler support of "long long"

[Adrian Bunk]

On Wed, Jun 27, 2007 at 05:52:08PM +0200, Joerg Schilling wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > That's a good point I missed.
> >
> > What about:
> >
> > #if defined(__GNUC__) && __STDC_VERSION__ < 19901L
> > __extension__ typedef   signed long long __s64;
> > __extension__ typedef unsigned long long __u64;
> > #else
> > typedef   signed long long __s64;
> > typedef unsigned long long __u64;
> > #endif
> 
> What about using:
> 
> #if (defined(__GNUC__) || defined(__SUNPRO_C)) && !defined(__STRICT_ANSI__) 

AFAIR __extension__ was gcc specific.

Does the Sun cc provide options for strict C90 checking?
And if yes, what is it's syntax for disabling this checking for a line 
of code?

> Well, there seems to be one other compiler (the one from Intel).
> It may be that if this compiler does not claim to be GCC, another
> definituion needs to be added.

AFAIR the Intel compiler claims to be gcc.

But these are by far not the only C compilers under Linux, and the more 
important points are:

Is there any userspace Linux compiler that does not support "long long"?
If yes, is there any other way to tell that something is a
64bit int on 32bit architectures?

> Jörg

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> AFAIR the Intel compiler claims to be gcc.
>
> But these are by far not the only C compilers under Linux, and the  
> more important points are:
>
> Is there any userspace Linux compiler that does not support "long  
> long"?

Don't know, but I'd guess not.


> If yes, is there any other way to tell that something is a 64bit  
> int on 32bit architectures?

Not that I know of.  Probably the straight #else conditional is OK.   
We should also merge up the types since *EVERY* linux architecture  
has these same types:

typedef   signed char      __s8;
typedef unsigned char      __u8;
typedef   signed short     __s16;
typedef unsigned short     __u16;
typedef   signed int       __s32;
typedef unsigned int       __u32;

Then all 64-bit archs have:
typedef   signed long      __s64;
typedef unsigned long      __u64;

While all 32-bit archs have:
typedef   signed long long __s64;
typedef unsigned long long __u64;

The only trick is if you care about building 32-bit compat code using  
64-bit linux kernel headers.  In that case we should probably just  
make all archs use "long long" for their 64-bit integers, unless  
there's some platform I'm not remembering where "long long" is 128- 
bits or bigger.  The other benefit is that people could then just use  
the printf format "%llu" for 64-bit integers instead of having to  
conditionalize it all over the place.

I'm working on a patch now.

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Randy Dunlap]

On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:

> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the  
> > more important points are:
> >
> > Is there any userspace Linux compiler that does not support "long  
> > long"?
> 
> Don't know, but I'd guess not.
> 
> 
> > If yes, is there any other way to tell that something is a 64bit  
> > int on 32bit architectures?
> 
> Not that I know of.  Probably the straight #else conditional is OK.   
> We should also merge up the types since *EVERY* linux architecture  
> has these same types:
> 
> typedef   signed char      __s8;
> typedef unsigned char      __u8;
> typedef   signed short     __s16;
> typedef unsigned short     __u16;
> typedef   signed int       __s32;
> typedef unsigned int       __u32;
> 
> Then all 64-bit archs have:
> typedef   signed long      __s64;
> typedef unsigned long      __u64;
> 
> While all 32-bit archs have:
> typedef   signed long long __s64;
> typedef unsigned long long __u64;
> 
> The only trick is if you care about building 32-bit compat code using  
> 64-bit linux kernel headers.  In that case we should probably just  
> make all archs use "long long" for their 64-bit integers, unless  
> there's some platform I'm not remembering where "long long" is 128- 
> bits or bigger.  The other benefit is that people could then just use  
> the printf format "%llu" for 64-bit integers instead of having to  
> conditionalize it all over the place.
> 
> I'm working on a patch now.

LDD3 ch. 11 says that long on Sparc64 is 32 bits.
Same for "ppc" (don't know which power* arch. they mean by that).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Userspace compiler support of "long long"

[Randy Dunlap]

On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:

> On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:
> 
> > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > > AFAIR the Intel compiler claims to be gcc.
> > >
> > > But these are by far not the only C compilers under Linux, and the  
> > > more important points are:
> > >
> > > Is there any userspace Linux compiler that does not support "long  
> > > long"?
> > 
> > Don't know, but I'd guess not.
> > 
> > 
> > > If yes, is there any other way to tell that something is a 64bit  
> > > int on 32bit architectures?
> > 
> > Not that I know of.  Probably the straight #else conditional is OK.   
> > We should also merge up the types since *EVERY* linux architecture  
> > has these same types:
> > 
> > typedef   signed char      __s8;
> > typedef unsigned char      __u8;
> > typedef   signed short     __s16;
> > typedef unsigned short     __u16;
> > typedef   signed int       __s32;
> > typedef unsigned int       __u32;
> > 
> > Then all 64-bit archs have:
> > typedef   signed long      __s64;
> > typedef unsigned long      __u64;
> > 
> > While all 32-bit archs have:
> > typedef   signed long long __s64;
> > typedef unsigned long long __u64;
> > 
> > The only trick is if you care about building 32-bit compat code using  
> > 64-bit linux kernel headers.  In that case we should probably just  
> > make all archs use "long long" for their 64-bit integers, unless  
> > there's some platform I'm not remembering where "long long" is 128- 
> > bits or bigger.  The other benefit is that people could then just use  
> > the printf format "%llu" for 64-bit integers instead of having to  
> > conditionalize it all over the place.
> > 
> > I'm working on a patch now.
> 
> LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> Same for "ppc" (don't know which power* arch. they mean by that).

Hm, I suppose that table only applies to userspace, not kernel...

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Userspace compiler support of "long long"

[Andi Kleen]

On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the  
> > more important points are:
> >
> > Is there any userspace Linux compiler that does not support "long  
> > long"?
> 
> Don't know, but I'd guess not.

Tendra C and probably lcc. I would guess tinycc too.

> The only trick is if you care about building 32-bit compat code using  
> 64-bit linux kernel headers.  In that case we should probably just  
> make all archs use "long long" for their 64-bit integers, unless  
> there's some platform I'm not remembering where "long long" is 128- 
> bits or bigger.  The other benefit is that people could then just use  
> the printf format "%llu" for 64-bit integers instead of having to  
> conditionalize it all over the place.
> 
> I'm working on a patch now.

Changing this will give you a zillion warnings for printk formats.

-Andi
 

Re: Userspace compiler support of "long long"

[Geert Uytterhoeven]

On Wed, 27 Jun 2007, Randy Dunlap wrote:
> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> > Same for "ppc" (don't know which power* arch. they mean by that).
> 
> Hm, I suppose that table only applies to userspace, not kernel...

32-bit userspace?

On 64-bit, `long' is 64-bit on all platforms supported by Linux.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Userspace compiler support of "long long"

[Kyle McMartin]

On Wed, Jun 27, 2007 at 04:16:48PM -0700, Randy Dunlap wrote:
> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> > Same for "ppc" (don't know which power* arch. they mean by that).
> 
> Hm, I suppose that table only applies to userspace, not kernel...
> 

Doing 64-bit Linux non-LP64 would be an interesting exercise in masochism...

Re: Userspace compiler support of "long long"

[Matthew Wilcox]

On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:
> Then all 64-bit archs have:
> typedef   signed long      __s64;
> typedef unsigned long      __u64;
> 
> While all 32-bit archs have:
> typedef   signed long long __s64;
> typedef unsigned long long __u64;

include/asm-parisc/types.h:typedef unsigned long long __u64;

For both 32 and 64-bit.

include/asm-sh64/types.h:typedef unsigned long long __u64;
include/asm-x86_64/types.h:typedef unsigned long long  __u64;

So that's three architectures that violate your first assertion.

Re: Linux Kernel include files

[H. Peter Anvin]

Kyle Moffett wrote:
> 
> Gah, this particular topic and a few other similar header-compatibility 
> ones show up once a month on LKML; I should probably just make a patch 
> to fix all the types.h files and be done with it.  The proper solution 
> is this:
> 
> # if __STDC_VERSION__ >= 19901L
> typedef   signed long long __s64;
> typedef unsigned long long __u64;
> # elif defined(__GNUC__)
> __extension__ typedef   signed long long __s64;
> __extension__ typedef unsigned long long __u64;
> # else
> #  error "Your compiler doesn't support long long (IOW: It sucks).  
> Please get a new one"
> # endif
> 
> That way if you have any kind of vaguely-long-long-compatible compiler 
> then it will work, and otherwise you'll get a nice useful error 
> message.  It also makes sure that GCC doesn't spew warnings/errors when 
> in c89-pedantic mode.  The "__extension__" keyword is designed for use 
> in implementation header files which want to use GCC-isms unconditionally.
> 

__extension__ should be macroized if so.

However, since something that doesn't have "long long" won't be able to 
compile those headers, there is absolutely no reason to not simply use 
it -- you get an error message on that line, which is good enough. 
There is definitely no reason to use a test like the one above, which is 
wrong for several supportable compilers.

	-hpa

Re: Userspace compiler support of "long long"

[H. Peter Anvin]

Kyle Moffett wrote:
>> 
> The only trick is if you care about building 32-bit compat code using 
> 64-bit linux kernel headers.  In that case we should probably just make 
> all archs use "long long" for their 64-bit integers, unless there's some 
> platform I'm not remembering where "long long" is 128-bits or bigger.  
> The other benefit is that people could then just use the printf format 
> "%llu" for 64-bit integers instead of having to conditionalize it all 
> over the place.
> 

No, you really don't want to do that, because then u64 != uint64_t on 
those platforms.

	-hpa

Re: Userspace compiler support of "long long"

[Jan Engelhardt]

On Jun 28 2007 04:12, Geert Uytterhoeven wrote:
>On Wed, 27 Jun 2007, Randy Dunlap wrote:
>> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
>> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
>> > Same for "ppc" (don't know which power* arch. they mean by that).
>> 
>> Hm, I suppose that table only applies to userspace, not kernel...
>
>32-bit userspace?
>
>On 64-bit, `long' is 64-bit on all platforms supported by Linux.

All types are as wide as the compiler makes them.

Compiler  short  int long llong
Turbo C      16   16   32     -
GCC -m32     16   32   32    64
GCC -m64     16   32   64    64



	Jan
-- 

Re: Userspace compiler support of "long long"

[Harald Arnesen]

Adrian Bunk <bunk@stusta.de> writes:

> Is there any userspace Linux compiler that does not support "long long"?
> If yes, is there any other way to tell that something is a
> 64bit int on 32bit architectures?

TenDRA C:

"test.c", line 6: Error:
  [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

-- 
Hilsen Harald.

Re: Userspace compiler support of "long long"

[Joerg Schilling]

Harald Arnesen <harald@skogtun.org> wrote:

> Adrian Bunk <bunk@stusta.de> writes:
>
> > Is there any userspace Linux compiler that does not support "long long"?
> > If yes, is there any other way to tell that something is a
> > 64bit int on 32bit architectures?
>
> TenDRA C:
>
> "test.c", line 6: Error:
>   [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

You cannot use this compiler for any program that uses an interface that
needs long long.

BTW: C99 requires long long but the Large File summit from 1995 did to the
same since 1995. An 32 bit OS that supports large files cannot have a compiler
that does not support long long.

If TenDRA C does support 64 bit integral type in a different way. TenDRA C
would need to deliver include files that take care about this fact.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Userspace compiler support of "long long"

[Geert Uytterhoeven]

On Thu, 28 Jun 2007, Jan Engelhardt wrote:
> On Jun 28 2007 04:12, Geert Uytterhoeven wrote:
> >On Wed, 27 Jun 2007, Randy Dunlap wrote:
> >> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> >> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> >> > Same for "ppc" (don't know which power* arch. they mean by that).
> >> 
> >> Hm, I suppose that table only applies to userspace, not kernel...
> >
> >32-bit userspace?
> >
> >On 64-bit, `long' is 64-bit on all platforms supported by Linux.
> 
> All types are as wide as the compiler makes them.
> 
> Compiler  short  int long llong
> Turbo C      16   16   32     -
> GCC -m32     16   32   32    64
> GCC -m64     16   32   64    64

We do not support building Linux with Turbo C (or MS Visual C for Win64
P64).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Userspace compiler support of "long long"

[David Woodhouse]

On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote:
> We do not support building Linux with Turbo C (or MS Visual C for
> Win64 P64). 

We're talking about types which are exposed to userspace.

-- 
dwmw2

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 20:30:42, Andi Kleen wrote:
> On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
>> The only trick is if you care about building 32-bit compat code  
>> using 64-bit linux kernel headers.  In that case we should  
>> probably just make all archs use "long long" for their 64-bit  
>> integers, unless there's some platform I'm not remembering where  
>> "long long" is 128-bits or bigger.  The other benefit is that  
>> people could then just use the printf format "%llu" for 64-bit  
>> integers instead of having to conditionalize it all over the place.
>>
>> I'm working on a patch now.
>
> Changing this will give you a zillion warnings for printk formats.

Why?  If this were a problem then we'd be getting a zillion warnings  
*now* from all the 32-bit archs (which already use "long long" for 64- 
bit.  This would actually make it _easier_ to get the printk formats  
right, as you could always use %ull for 64-bit types without having  
to cast for 64-bit platforms.

This is another way to get around the "build 32-bit-compat userspace  
on 64-bit kernel headers" problem:  It tells GCC to use the  
"smallest" available type of the given size, which ends up being  
exactly the types we use now.  On the other hand, it only works for  
GCC which sort of ruins most of the reason for changing the types in  
the first place.

typedef   signed __s8  __attribute__((__mode__(__QI__)));
typedef unsigned __u8  __attribute__((__mode__(__QI__)));
typedef   signed __s16 __attribute__((__mode__(__HI__)));
typedef unsigned __u16 __attribute__((__mode__(__HI__)));
typedef   signed __s32 __attribute__((__mode__(__SI__)));
typedef unsigned __u32 __attribute__((__mode__(__SI__)));
typedef   signed __s64 __attribute__((__mode__(__DI__)));
typedef unsigned __u64 __attribute__((__mode__(__DI__)));

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote:
> On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:
>> Then all 64-bit archs have:
>> typedef   signed long      __s64;
>> typedef unsigned long      __u64;
>>
>> While all 32-bit archs have:
>> typedef   signed long long __s64;
>> typedef unsigned long long __u64;
>
> include/asm-parisc/types.h:typedef unsigned long long __u64;
>
> For both 32 and 64-bit.
>
> include/asm-sh64/types.h:typedef unsigned long long __u64;
> include/asm-x86_64/types.h:typedef unsigned long long  __u64;
>
> So that's three architectures that violate your first assertion.

Oh, ok, that makes it even easier to say this with certainty:   
Changing the other 64-bit archs to use "long long" for their 64-bit  
numbers will not cause additional warnings.  I'm also almost certain  
there are no architectures which use "long long" for 128-bit  
integers. (Moreover, I can't find hardly anything which does 128-bit  
integers at all).

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Jakub Jelinek]

On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote:
> On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote:
> >On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:
> >>Then all 64-bit archs have:
> >>typedef   signed long      __s64;
> >>typedef unsigned long      __u64;
> >>
> >>While all 32-bit archs have:
> >>typedef   signed long long __s64;
> >>typedef unsigned long long __u64;
> >
> >include/asm-parisc/types.h:typedef unsigned long long __u64;
> >
> >For both 32 and 64-bit.
> >
> >include/asm-sh64/types.h:typedef unsigned long long __u64;
> >include/asm-x86_64/types.h:typedef unsigned long long  __u64;
> >
> >So that's three architectures that violate your first assertion.
> 
> Oh, ok, that makes it even easier to say this with certainty:   
> Changing the other 64-bit archs to use "long long" for their 64-bit  
> numbers will not cause additional warnings.  I'm also almost certain  
> there are no architectures which use "long long" for 128-bit  
> integers. (Moreover, I can't find hardly anything which does 128-bit  
> integers at all).

unsigned long and unsigned long long have the same size, precision
and alignment on all LP64 arches, that's true.  But they have
different ranks and more importantly they mangle differently in C++.
So, whether some user exposed type uses unsigned long or unsigned long long
is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t
or any other type, you can't change it without breaking the ABI.

	Jakub

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 06:26:06, Harald Arnesen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>> Is there any userspace Linux compiler that does not support "long  
>> long"?  If yes, is there any other way to tell that something is a  
>> 64bit int on 32bit architectures?
>
> TenDRA C:
>
> "test.c", line 6: Error:
>   [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

I can't even find the docs for their "tcc".  Their "tchk" appears to  
have a "#pragma longlong type allow" or something, so I'd imagine the  
same exists for tcc and would be required to build stuff using kernel  
headers.  On the other hand, their compiler looks so immature that it  
does not appear to be worth spending much time worrying about now.   
When somebody shows up with a solution for that compiler then we can  
look at it at that time.

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 08:08:03, Jakub Jelinek wrote:
> On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote:
>> Oh, ok, that makes it even easier to say this with certainty:  
>> Changing the other 64-bit archs to use "long long" for their 64- 
>> bit numbers will not cause additional warnings.  I'm also almost  
>> certain there are no architectures which use "long long" for 128- 
>> bit integers. (Moreover, I can't find hardly anything which does  
>> 128-bit integers at all).
>
> unsigned long and unsigned long long have the same size, precision  
> and alignment on all LP64 arches, that's true.  But they have  
> different ranks and more importantly they mangle differently in C+ 
> +.  So, whether some user exposed type uses unsigned long or  
> unsigned long long is part of the ABI, whether that's size_t,  
> uintptr_t, uint64_t, u_int64_t or any other type, you can't change  
> it without breaking the ABI.

That sounds *extraordinarily* broken.  Hopefully this would *not*  
affect the type of a function which is passed a C "struct" containing  
the "long long", right?

Hmm, I guess the question is:  Do we support people directly passing  
__u64 to C++ functions in userspace?  I could understand, perhaps,  
passing around structures defined in the kernel headers, but  
certainly not the kernel-internal types.  The only reason we even  
export those is so we can have a private set of bit-size-defined  
types with which to define kernel ABI structures.

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 07:36:14, David Woodhouse wrote:
> On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote:
>> We do not support building Linux with Turbo C (or MS Visual C for  
>> Win64 P64).
>
> We're talking about types which are exposed to userspace.

Yes, and all 64-bit software built using kernel headers must be built  
in LP64 mode, anything else is pure insanity.  On LP64 (IE: how the  
kernel itself is compiled on EVERY 64-bit arch):

char == 8 bits
short == 16 bits
int == 32 bits
long == 64 bits
pointer == 64 bits
long long == 64 bits

On LP32 (IE: how the kernel itself is compiled on EVERY 32-bit arch):

char == 8 bits
short == 16 bits
int == 32 bits
long == 32 bits
pointer == 32 bits
long long == 64 bits

Ergo we can simply require that if you want to use kernel headers you  
must be using the same mode as the kernel is compiled in (LP32 or LP64).

The simplest guaranteed-not-to-break way to do this on _every_  
supported platform is:
typedef   signed char  __s8;
typedef unsigned char  __s8;
typedef   signed short __s16;
typedef unsigned short __s16;
typedef   signed int   __s32;
typedef unsigned int   __s32;
# if __STDC_VERSION__ >= 19901L
typedef   signed long long __s64;
typedef unsigned long long __s64;
# elif defined(__GNUC__)
__extension__ typedef   signed long long __s64;
__extension__ typedef unsigned long long __s64;
# endif

If you have some other compiler that works under linux *AND* supports  
a 64-bit type in non-C99-mode (whether "long long" or something  
else), then they are welcome to submit patches to fix it.

Cheers,
Kyle Moffett

Re: Userspace compiler support of "long long"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Thu, Jun 28, 2007 at 08:11:59AM -0400, Kyle Moffett wrote:

> I can't even find the docs for their "tcc".  Their "tchk" appears to  

tchk is the same thing pretty much with output disabled.  There's a HTML
copy of the man page here:

  http://www.penguin-soft.com/penguin/man/1/tendracc.html

It's packaged for Debian and therefore Ubuntu and other derived
distributions.

> have a "#pragma longlong type allow" or something, so I'd imagine the  
> same exists for tcc and would be required to build stuff using kernel  
> headers.

You just need to specify -Ysystem (or some other API selection option)
when building to get it to accept long long.  Since TenDRA focuses on
strict standards conformance it defaults to something roughly equivalent
to GCC with -std=c89 -pedantic -Werror and requires the user to
explicitly enable support for any other APIs and features they want to
use.

>           On the other hand, their compiler looks so immature that it  
> does not appear to be worth spending much time worrying about now.   
> When somebody shows up with a solution for that compiler then we can  
> look at it at that time.

The compiler is solid enough but old - it predates C99 and has had no
real development since then beyond updating the system include overrides
to work with newer glibc versions.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]