Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Jun 28 2007 12:57, Jan-Benedict Glaw wrote:
>>> > It's not an accusation -- it's merely an observation. You may not have
>>> > noticed that your mailer was misbehaving; now you _do_ know, and if you
>>> > care about RFC compliance you might want to
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 28 2007 12:57, Jan-Benedict Glaw wrote:
It's not an accusation -- it's merely an observation. You may not have
noticed that your mailer was misbehaving; now you _do_ know, and if you
care about RFC compliance you might want to fix it. You're
On Saturday 30 June 2007 08:02:16 Joerg Schilling wrote:
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > Jörg,
> >
> > On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
> > > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
[EMAIL PROTECTED] (Joerg Schilling) writes:
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
>> Jörg,
>>
>> On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
>> > David Woodhouse <[EMAIL PROTECTED]> wrote:
>> >
>> > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
>> > > >
Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > Jörg
> [advertisements removed]
Please stop this kind of trolling, you did not remove anything here,
so do not claim to remove things
As you don't seem to know the nettiquette:
If you believe you have some kind of problems that was used by
On Sat, Jun 30, 2007 at 02:02:16PM +0200, Joerg Schilling wrote:
> Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > Jörg,
> >
> > On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
> > > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Thu, 2007-06-28 at 12:27 +0200, Joerg
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Jörg,
>
> On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > > > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > > > > By
Willy Tarreau [EMAIL PROTECTED] wrote:
Jörg,
On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
By the way, your mailer
On Sat, Jun 30, 2007 at 02:02:16PM +0200, Joerg Schilling wrote:
Willy Tarreau [EMAIL PROTECTED] wrote:
Jörg,
On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
Willy Tarreau [EMAIL PROTECTED] wrote:
Jörg
[advertisements removed]
Please stop this kind of trolling, you did not remove anything here,
so do not claim to remove things
As you don't seem to know the nettiquette:
If you believe you have some kind of problems that was used by the
OP
[EMAIL PROTECTED] (Joerg Schilling) writes:
Willy Tarreau [EMAIL PROTECTED] wrote:
Jörg,
On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL
On Saturday 30 June 2007 08:02:16 Joerg Schilling wrote:
Willy Tarreau [EMAIL PROTECTED] wrote:
Jörg,
On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
David
On Thu, 2007-06-28 at 15:49 +0200, Jan Engelhardt wrote:
> I'll have to chime in here.
> Test program:
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include /* get IP_FREEBIND */
>
> Creates a lot of error messages.
>
On Thu, 2007-06-28 at 15:49 +0200, Jan Engelhardt wrote:
I'll have to chime in here.
Test program:
#include sys/socket.h
#include sys/stat.h
#include sys/types.h
#include arpa/inet.h
#include netinet/in.h
#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
#include
On Jun 28 2007 12:57, Jan-Benedict Glaw wrote:
>> >
>> > It's not an accusation -- it's merely an observation. You may not have
>> > noticed that your mailer was misbehaving; now you _do_ know, and if you
>> > care about RFC compliance you might want to fix it. You're not _obliged_
>> > to fix
On Jun 27 2007 19:18, Sam Ravnborg wrote:
>
>For my test I used latest -git of the Linux kernel.
>In this version the include of ext2_fs_bh.h is guarded
>by __KERNEL__ like this:
>
>#ifdef __KERNEL__
>#include
>static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
>{
>return
On Thu, 2007-06-28 12:39:57 +0200, Joerg Schilling <[EMAIL PROTECTED]> wrote:
> > > > By the way, your mailer seems to be sometimes omitting In-Reply-To: and
> > > > References: headers, which RFC2822 says you SHOULD include in replies.
> > >
> > > Sending such accusation without knowing the
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> > from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
> > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
> >
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > > > Warning: *** linux/ext2_fs.h is not usable at all ***
> > > > Warning:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > > Warning: *** linux/ext2_fs.h is not usable at all ***
> > > Warning: *** This makes it impossible to support Linux file
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > Warning: *** linux/ext2_fs.h is not usable at all ***
> > Warning: *** This makes it impossible to support Linux file flags ***
> > You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
>
David Woodhouse [EMAIL PROTECTED] wrote:
On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it impossible to support Linux file flags ***
You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
Again,
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it impossible to support Linux file flags ***
You
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it
Sam Ravnborg [EMAIL PROTECTED] wrote:
gcc -c t.c
In file included from /usr/include/linux/ext2_fs.h:20,
from t.c:2:
/usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
On Thu, 2007-06-28 12:39:57 +0200, Joerg Schilling [EMAIL PROTECTED] wrote:
By the way, your mailer seems to be sometimes omitting In-Reply-To: and
References: headers, which RFC2822 says you SHOULD include in replies.
Sending such accusation without knowing the reason is not
On Jun 27 2007 19:18, Sam Ravnborg wrote:
For my test I used latest -git of the Linux kernel.
In this version the include of ext2_fs_bh.h is guarded
by __KERNEL__ like this:
#ifdef __KERNEL__
#include linux/ext2_fs_sb.h
static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
{
On Jun 28 2007 12:57, Jan-Benedict Glaw wrote:
It's not an accusation -- it's merely an observation. You may not have
noticed that your mailer was misbehaving; now you _do_ know, and if you
care about RFC compliance you might want to fix it. You're not _obliged_
to fix it, of course. I
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
> @Jörg: The responsibility to maintain clean headers shifted only recently,
yes.. from distro to the kernel ;)
in the old case it was always a distro bug...
> and there is possibly still a lot to do. If you can point out errors, they
> can and probably will be fixed. But as you know, having a
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
>> Well, I did report these kind of problems many years ago and as it has not
>> been fixed after some years, I was asuming that it is still the way I see it
>> on Suse 10.0.
>
> I'd suggest
Joerg Schilling wrote:
After copying /usr/include/linux/types.h to
/opt/sunstudio12/prod/include/cc/linux/types.h and removing all
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
...
#endif
stuff, I got cdrtools compiled using "suncc" and I did even get a woring
cdrecord.
Indeed,
On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
> Well, I did report these kind of problems many years ago and as it has not
> been
> fixed after some years, I was asuming that it is still the way I see it on
> Suse
> 10.0.
I'd suggest reporting SuSE bugs to SuSE; that's more
On Wed, Jun 27, 2007 at 03:58:43PM +0200, Joerg Schilling wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > 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.
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > On Suse Linux 10.0, I get e.g.:
> >
> > cat t.c
> > #include
> > #include
> >
> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> > from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error
On Wed, Jun 27, 2007 at 03:58:43PM +0200, Joerg Schilling wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > 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.
On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> Warning: *** linux/ext2_fs.h is not usable at all ***
> Warning: *** This makes it impossible to support Linux file flags ***
> You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
Again, can you be _specific_? Amusing though your
On Wed, 27 Jun 2007, Joerg Schilling wrote:
> Adrian Bunk <[EMAIL PROTECTED]> 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
Adrian Bunk <[EMAIL PROTECTED]> 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
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__) &&
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Personally, I think that's a load of bollocks. And it certainly doesn't
> > apply to Linux-specific files like , which are perfectly
> > entitled to use a C standard from last millennium, regardless of
> > namespace 'pollution' issues. That's why we
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (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
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> 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
> $
Sam Ravnborg [EMAIL PROTECTED] wrote:
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
Harald Arnesen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (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
Adrian Bunk [EMAIL PROTECTED] wrote:
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
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
Adrian Bunk [EMAIL PROTECTED] 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
On Wed, 27 Jun 2007, Joerg Schilling wrote:
Adrian Bunk [EMAIL PROTECTED] 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
On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
Warning: *** linux/ext2_fs.h is not usable at all ***
Warning: *** This makes it impossible to support Linux file flags ***
You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
Again, can you be _specific_? Amusing though your
On Wed, Jun 27, 2007 at 03:58:43PM +0200, Joerg Schilling wrote:
Sam Ravnborg [EMAIL PROTECTED] wrote:
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
Adrian Bunk [EMAIL PROTECTED] wrote:
On Suse Linux 10.0, I get e.g.:
cat t.c
#include stdio.h
#include linux/ext2_fs.h
gcc -c t.c
In file included from /usr/include/linux/ext2_fs.h:20,
from t.c:2:
/usr/include/linux/ext2_fs_sb.h:40: error: syntax error
On Wed, Jun 27, 2007 at 03:58:43PM +0200, Joerg Schilling wrote:
Sam Ravnborg [EMAIL PROTECTED] wrote:
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
On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
Well, I did report these kind of problems many years ago and as it has not
been
fixed after some years, I was asuming that it is still the way I see it on
Suse
10.0.
I'd suggest reporting SuSE bugs to SuSE; that's more effective
Joerg Schilling wrote:
After copying /usr/include/linux/types.h to
/opt/sunstudio12/prod/include/cc/linux/types.h and removing all
#if defined(__GNUC__) !defined(__STRICT_ANSI__)
...
#endif
stuff, I got cdrtools compiled using suncc and I did even get a woring
cdrecord.
Indeed, this
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
Well, I did report these kind of problems many years ago and as it has not
been fixed after some years, I was asuming that it is still the way I see it
on Suse 10.0.
I'd suggest reporting
@Jörg: The responsibility to maintain clean headers shifted only recently,
yes.. from distro to the kernel ;)
in the old case it was always a distro bug...
and there is possibly still a lot to do. If you can point out errors, they
can and probably will be fixed. But as you know, having a
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
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;
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
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
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;
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Joerg Schilling) writes:
>
> >> FYI, cdrtools also compile and link fine with Sun's C compiler.
> >
> > M, if you call "cdrecord -scanbus", what do you get?
>
> I may have misunderstood your make system. I cd-ed into the cdrtools
[EMAIL PROTECTED] (Joerg Schilling) writes:
>> FYI, cdrtools also compile and link fine with Sun's C compiler.
>
> M, 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
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> Harald Arnesen <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] (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
Harald Arnesen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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
[EMAIL PROTECTED] (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
>
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
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> David Woodhouse <[EMAIL PROTECTED]> 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
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
David Woodhouse <[EMAIL PROTECTED]> 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
>>
On Mon, 25 Jun 2007, Joerg Schilling wrote:
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Friday 22 June 2007, [EMAIL PROTECTED] 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
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
On Mon, 2007-06-25 at 17:17 +0200, Joerg Schilling wrote:
> David Woodhouse <[EMAIL PROTECTED]> 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
> > 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
David Woodhouse <[EMAIL PROTECTED]> 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
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Friday 22 June 2007, [EMAIL PROTECTED] 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.
>
se 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
cal 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 kerne
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:[EMAIL PROTECTED] (home
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
Arnd Bergmann [EMAIL PROTECTED] wrote:
On Friday 22 June 2007, [EMAIL PROTECTED] 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
David Woodhouse [EMAIL PROTECTED] 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
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
On Mon, 2007-06-25 at 17:17 +0200, Joerg Schilling wrote:
David Woodhouse [EMAIL PROTECTED] 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
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
On Mon, 25 Jun 2007, Joerg Schilling wrote:
Arnd Bergmann [EMAIL PROTECTED] wrote:
On Friday 22 June 2007, [EMAIL PROTECTED] 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
David Woodhouse [EMAIL PROTECTED] 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
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
Harald Arnesen [EMAIL PROTECTED] wrote:
David Woodhouse [EMAIL PROTECTED] 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
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
[EMAIL PROTECTED] (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
Harald Arnesen [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (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
Harald Arnesen [EMAIL PROTECTED] wrote:
Harald Arnesen [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (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'.
[EMAIL PROTECTED] (Joerg Schilling) writes:
FYI, cdrtools also compile and link fine with Sun's C compiler.
M, 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
Harald Arnesen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Joerg Schilling) writes:
FYI, cdrtools also compile and link fine with Sun's C compiler.
M, if you call cdrecord -scanbus, what do you get?
I may have misunderstood your make system. I cd-ed into the cdrtools
directory, ran
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
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
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
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.
1 - 100 of 112 matches
Mail list logo
