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.
>
Arjan van de Ven <[EMAIL PROTECTED]> 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.
> >
> >
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
Arjan van de Ven [EMAIL PROTECTED] 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
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 110 matches
Mail list logo
