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 fi
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:
>> > > > D
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
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
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.
> (L
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,
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 reas
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
> > âs_n
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 flags
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'
>
>
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
> @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 re
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, t
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 effect
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 before
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 cons
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 un
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__
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 conti
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
> $ ma
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 t
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 compil
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 typo
[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
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
L
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 instal
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
#i
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
>> u
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 ad
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 fo
> > 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 type
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.
> >
> > Wh
[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 tim
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
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 f
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.
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 always tried not to step on anyone's toes the
> 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
[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 tim
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 t
55 matches
Mail list logo
