Re: Linux Kernel include files
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 not _obliged_ >>> > to fix it, of course. I just thought you'd like to know. >>> >>> Well there you are: my mailer is definitely NOT missbehaving. >>> Please do not repeat similar accusations when not knowing the reason. >> >>Just out of interest: In which cases do you want to break threading? > > The threading for this thread is ok. It's broken from [EMAIL PROTECTED] on, or news:[EMAIL PROTECTED] It will be broken again here, this time because of the news gateway. -- Top 100 things you don't want the sysadmin to say: 54. Uh huh.."nu -k $USER".. no problemsure thing... Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 not _obliged_ to fix it, of course. I just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Just out of interest: In which cases do you want to break threading? The threading for this thread is ok. It's broken from [EMAIL PROTECTED] on, or news:[EMAIL PROTECTED] It will be broken again here, this time because of the news gateway. -- Top 100 things you don't want the sysadmin to say: 54. Uh huh..nu -k $USER.. no problemsure thing... Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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 Woodhouse <[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 polite. > > > > > > > > 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 just thought you'd like to know. > > > > > > Well there you are: my mailer is definitely NOT missbehaving. > > > Please do not repeat similar accusations when not knowing the reason. > > > > Attacking people who suggest to you they *may* have noticed an anomaly is > > not polite at all, childish at best, and counter-productive in any case. > > Well, then please write this to the person who did attack me for no reason! > > What he did is typical trollish behavior, as he tried to turn a technical > based discussion into a flame war for no reason. > > Jörg Jörg - I see no attack. What I do see is a quite friendly notification that your mail program appears to be omitting those headers in certain mails and that such action is in violation of a published standard. Your response was inflammatory, rude and very trollish. And when the person calmly restated himself and the reason he made the original comment you again responded in an extremely unpleasant manner. When notified that your behavior was incorrect you pointed fingers and yelled "He started it!" - something that *CHILDREN* do. Since it appears that you act like a child its time to add you to my killfile again. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
[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 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 polite. >> > > >> > > 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 just >> > > thought you'd like to know. >> > >> > Well there you are: my mailer is definitely NOT missbehaving. >> > Please do not repeat similar accusations when not knowing the >> > reason. >> >> Attacking people who suggest to you they *may* have noticed an >> anomaly is not polite at all, childish at best, and >> counter-productive in any case. > > Well, then please write this to the person who did attack me for no > reason! > > What he did is typical trollish behavior, as he tried to turn a > technical based discussion into a flame war for no reason. Ah, it's nice to see Jörg back to his usual self. For a while there the headers discussion was looking almost reasonable. BTW Jörg, thanks for the absolutely fantastic real-life flame war you gave us at LinuxTag (by the Google booth, remember). I haven't had so much fun in a long time. Quite a few bystanders seemed rather entertained too. -- Måns Rullgård [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Personal attacks (was Re: Linux Kernel include files)
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 to send a personal attack, the natural reaction is to send a personal mail that does _not_ include a list of persons or a mailing list. As it does not seem to make sens to continue here, I will not reply to any further mail that tries to discuss something from the "mail threading" attack. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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: > > > > > David Woodhouse <[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 polite. > > > > > > > > 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 just thought you'd like to know. > > > > > > Well there you are: my mailer is definitely NOT missbehaving. > > > Please do not repeat similar accusations when not knowing the reason. > > > > Attacking people who suggest to you they *may* have noticed an anomaly is > > not polite at all, childish at best, and counter-productive in any case. > > Well, then please write this to the person who did attack me for no reason! I illustrated what looked like to be his reason and it was valid here too, and you even removed the proofs on purpose of not commenting. > What he did is typical trollish behavior, as he tried to turn a technical > based discussion into a flame war for no reason. Oh yes, of course... Any advice to make mail communication better for everyone on a mailing list surely is trolling and trying to bring anything into a flame war... I am always amused by the contents of your rants. I've never known if you sometimes believe what you say, but it's not my problem anyway. Maybe having the last word by boring people make you feel like you're right. But if you cannot openly communicate with people on mailing lists, please first do not open discussions on subjects which are known to derivate into flame wars. This month has been particularly loaded with non-productive contents already. > Jörg [advertisements removed] Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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 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 polite. > > > > > > 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 just thought you'd like to know. > > > > Well there you are: my mailer is definitely NOT missbehaving. > > Please do not repeat similar accusations when not knowing the reason. > > Attacking people who suggest to you they *may* have noticed an anomaly is > not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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 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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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: David Woodhouse [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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! I illustrated what looked like to be his reason and it was valid here too, and you even removed the proofs on purpose of not commenting. What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Oh yes, of course... Any advice to make mail communication better for everyone on a mailing list surely is trolling and trying to bring anything into a flame war... I am always amused by the contents of your rants. I've never known if you sometimes believe what you say, but it's not my problem anyway. Maybe having the last word by boring people make you feel like you're right. But if you cannot openly communicate with people on mailing lists, please first do not open discussions on subjects which are known to derivate into flame wars. This month has been particularly loaded with non-productive contents already. Jörg [advertisements removed] Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Personal attacks (was Re: Linux Kernel include files)
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 to send a personal attack, the natural reaction is to send a personal mail that does _not_ include a list of persons or a mailing list. As it does not seem to make sens to continue here, I will not reply to any further mail that tries to discuss something from the mail threading attack. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
[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 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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Ah, it's nice to see Jörg back to his usual self. For a while there the headers discussion was looking almost reasonable. BTW Jörg, thanks for the absolutely fantastic real-life flame war you gave us at LinuxTag (by the Google booth, remember). I haven't had so much fun in a long time. Quite a few bystanders seemed rather entertained too. -- Måns Rullgård [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
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 Woodhouse [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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg Jörg - I see no attack. What I do see is a quite friendly notification that your mail program appears to be omitting those headers in certain mails and that such action is in violation of a published standard. Your response was inflammatory, rude and very trollish. And when the person calmly restated himself and the reason he made the original comment you again responded in an extremely unpleasant manner. When notified that your behavior was incorrect you pointed fingers and yelled He started it! - something that *CHILDREN* do. Since it appears that you act like a child its time to add you to my killfile again. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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. > (Lots of redefinitions.) > > $ rpm -q linux-kernel-headers glibc > linux-kernel-headers-2.6.21-7 > glibc-2.6-5 > (suse 10.3 factory) > > So looks like there's still something to do. Hm, yes. But what? Is it reasonable for people to include and at the same time? It's suboptimal that they have to include for certain definitions, but that file also provides conflicting definitions of stuff which exists elsewhere. Should we split into two parts? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 unistd.h #include linux/in.h /* get IP_FREEBIND */ Creates a lot of error messages. (Lots of redefinitions.) $ rpm -q linux-kernel-headers glibc linux-kernel-headers-2.6.21-7 glibc-2.6-5 (suse 10.3 factory) So looks like there's still something to do. Hm, yes. But what? Is it reasonable for people to include linux/in.h and netinet/in.h at the same time? It's suboptimal that they have to include linux/in.h for certain definitions, but that file also provides conflicting definitions of stuff which exists elsewhere. Should we split linux/in.h into two parts? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 just thought you'd like to know. >> >> Well there you are: my mailer is definitely NOT missbehaving. >> Please do not repeat similar accusations when not knowing the reason. > >Just out of interest: In which cases do you want to break threading? The threading for this thread is ok. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 sb->s_fs_info;
>}
[...]
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.
(Lots of redefinitions.)
$ rpm -q linux-kernel-headers glibc
linux-kernel-headers-2.6.21-7
glibc-2.6-5
(suse 10.3 factory)
So looks like there's still something to do.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 polite. > > > > 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 just thought you'd like to know. > > Well there you are: my mailer is definitely NOT missbehaving. > Please do not repeat similar accusations when not knowing the reason. Just out of interest: In which cases do you want to break threading? MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) signature.asc Description: Digital signature
Re: Linux Kernel include files
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_next_generationâ
> > /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
> > /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
>
> Hi Jörg.
>
> 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 sb->s_fs_info;
> }
>
Thank you!
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 consistent 'Lunix is > > > broken' chants are, the only reason I'm bothering to participate in this > > > thread is on the off-chance that something _productive_ will come of it. > > > > I have been forced to add this test as too many people reported that they > > have no been able to compile star on their Linux distribution. > > But do you not know _why_? What exactly are you testing _for_? > > Bug reports which merely say 'is broken' are not helpful. If you like to know what I test, I encourage you to check the autoconf scripts. I am testing whether the named include file may be used from a user space program. As I did mention already, I was forced to add the test in order to be able to compile at all. > > > 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 polite. > > 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 may try to compile using 'make COPTX=-DTRY_EXT2_FS' > > > > Again, can you be _specific_? Amusing though your consistent 'Lunix is > > broken' chants are, the only reason I'm bothering to participate in this > > thread is on the off-chance that something _productive_ will come of it. > > I have been forced to add this test as too many people reported that they > have no been able to compile star on their Linux distribution. But do you not know _why_? What exactly are you testing _for_? Bug reports which merely say 'is broken' are not helpful. > > 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 polite. 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 just thought you'd like to know. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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, can you be _specific_? Amusing though your consistent 'Lunix is > broken' chants are, the only reason I'm bothering to participate in this > thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. > 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 polite. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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, can you be _specific_? Amusing though your consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. 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 polite. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 may try to compile using 'make COPTX=-DTRY_EXT2_FS' Again, can you be _specific_? Amusing though your consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. But do you not know _why_? What exactly are you testing _for_? Bug reports which merely say 'is broken' are not helpful. 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 polite. 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 just thought you'd like to know. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. But do you not know _why_? What exactly are you testing _for_? Bug reports which merely say 'is broken' are not helpful. If you like to know what I test, I encourage you to check the autoconf scripts. I am testing whether the named include file may be used from a user space program. As I did mention already, I was forced to add the test in order to be able to compile at all. 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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Hi Jörg.
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)
{
return sb-s_fs_info;
}
Thank you!
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 polite. 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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Just out of interest: In which cases do you want to break threading? MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) signature.asc Description: Digital signature
Re: Linux Kernel include files
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)
{
return sb-s_fs_info;
}
[...]
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 unistd.h
#include linux/in.h /* get IP_FREEBIND */
Creates a lot of error messages.
(Lots of redefinitions.)
$ rpm -q linux-kernel-headers glibc
linux-kernel-headers-2.6.21-7
glibc-2.6-5
(suse 10.3 factory)
So looks like there's still something to do.
Jan
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Just out of interest: In which cases do you want to break threading? The threading for this thread is ok. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
> @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 precise error > message or description does help. absolutely. if you find issues with the "real" kernel headers (eg the make headers_install ones) ... as you have seen there's lots of interest to make sure they're as useful as reasonably possible -- 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 SuSE bugs to SuSE; that's more effective ;) > (although I don't know how they will deal with bugreports against older > versions) > > your bug looks certainly valid.. just you're not using the "proper" > header set that the kernel developers suggest ;) Even though you put the smiley there, it does not seem fair to expect people to know the latest bits of kernel developement and deployment procedures unless hanging around on lkml is a requirement for linux users. I'm just browsing that list, filtering and ignoring a lot. If I didn't do that, I would not even suspect something like make headers_install to exist, nor would I try to search for it. @Jörg: The responsibility to maintain clean headers shifted only recently, 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 precise error message or description does help. -- W.I.N.D.O.W.S.: Wireless Intelligent Neohuman Designed for Observation and Worldwide Sabotage -- http://www.brunching.com/toys/toy-cyborger.html (down) Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 guard is bogus. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 ;) (although I don't know how they will deal with bugreports against older versions) your bug looks certainly valid.. just you're not using the "proper" header set that the kernel developers suggest ;) -- 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 so I did:
> >
> > $ mkdir ~/foo
> > $ cd ~/kernel/linux-2.6
> > $ make INSTALL_HDR_PATH=~/foo
> > $ cd ~/foo
> > $ cat j.c
> > #include
> > #include "etx2_fs.h"
> >
> > main()
> > {
> > printf("helloo\n");
> > }
> >
> > $ gcc -o j j.c
> > => No warning, no errors
> >
>
> 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 âuid_tâ
> /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
> âs_next_generationâ
> /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
> /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Hi Jörg.
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 sb->s_fs_info;
}
And therefore the include statement is removed in the exported set of kernel
include files.
So this particular issue is solved with the latest kernel and using the headers
prepared for export.
This tells me that we are on the right track with exporting the headers and
sanitize them.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 âuid_tâ > > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before > > âs_next_generationâ > > /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token > > /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token > > Already fixed since kernel 2.6.18. > > Our header were a mess and we are working on getting them better. > But we can't timetravel and fix old distributions. 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. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 so I did:
> >
> > $ mkdir ~/foo
> > $ cd ~/kernel/linux-2.6
> > $ make INSTALL_HDR_PATH=~/foo
> > $ cd ~/foo
> > $ cat j.c
> > #include
> > #include "etx2_fs.h"
> >
> > main()
> > {
> > printf("helloo\n");
> > }
> >
> > $ gcc -o j j.c
> > => No warning, no errors
> >
>
> 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 âuid_tâ
> /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
> âs_next_generationâ
> /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
> /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Already fixed since kernel 2.6.18.
Our header were a mess and we are working on getting them better.
But we can't timetravel and fix old distributions.
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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"? The Sun compiler did support the long long type before gcc did. This is not a problem. I get e.g.: ==> COMPILING "scsihack.o" "/usr/include/linux/byteorder/little_endian.h", line 43: inline keyword applied to __le64: must be a function identifier "/usr/include/linux/byteorder/little_endian.h", line 43: syntax error before or at: __cpu_to_le64p "/usr/include/linux/byteorder/little_endian.h", line 45: operands must have arithmetic type: op "*" "/usr/include/linux/byteorder/little_endian.h", line 47: syntax error before or at: * "/usr/include/linux/byteorder/little_endian.h", line 49: undefined symbol: p "/usr/include/linux/byteorder/little_endian.h", line 49: cannot dereference non-pointer type "/usr/include/linux/byteorder/little_endian.h", line 67: inline keyword applied to __be64: must be a function identifier "/usr/include/linux/byteorder/little_endian.h", line 67: syntax error before or at: __cpu_to_be64p "/usr/include/linux/byteorder/little_endian.h", line 69: syntax error before or at: __swab64p "/usr/include/linux/byteorder/little_endian.h", line 71: syntax error before or at: * "/usr/include/linux/byteorder/little_endian.h", line 73: undefined symbol: p "scsi-linux-sg.c", line 1152: warning: statement not reached cc: acomp failed for scsihack.c And it seems that yout proposal did point into the right direction. 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. Thanks for the help! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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. Maybe because it automatically deactivates the Linux extensions if the autoconfiguration sees broken include files. Did you see something like: checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces 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' Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 INSTALL_HDR_PATH=~/foo
> $ cd ~/foo
> $ cat j.c
> #include
> #include "etx2_fs.h"
>
> main()
> {
> printf("helloo\n");
> }
>
> $ gcc -o j j.c
> => No warning, no errors
>
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 âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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
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 before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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. Maybe because it automatically deactivates the Linux extensions if the autoconfiguration sees broken include files. Did you see something like: checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces 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' Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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? The Sun compiler did support the long long type before gcc did. This is not a problem. I get e.g.: == COMPILING scsihack.o /usr/include/linux/byteorder/little_endian.h, line 43: inline keyword applied to __le64: must be a function identifier /usr/include/linux/byteorder/little_endian.h, line 43: syntax error before or at: __cpu_to_le64p /usr/include/linux/byteorder/little_endian.h, line 45: operands must have arithmetic type: op * /usr/include/linux/byteorder/little_endian.h, line 47: syntax error before or at: * /usr/include/linux/byteorder/little_endian.h, line 49: undefined symbol: p /usr/include/linux/byteorder/little_endian.h, line 49: cannot dereference non-pointer type /usr/include/linux/byteorder/little_endian.h, line 67: inline keyword applied to __be64: must be a function identifier /usr/include/linux/byteorder/little_endian.h, line 67: syntax error before or at: __cpu_to_be64p /usr/include/linux/byteorder/little_endian.h, line 69: syntax error before or at: __swab64p /usr/include/linux/byteorder/little_endian.h, line 71: syntax error before or at: * /usr/include/linux/byteorder/little_endian.h, line 73: undefined symbol: p scsi-linux-sg.c, line 1152: warning: statement not reached cc: acomp failed for scsihack.c And it seems that yout proposal did point into the right direction. 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. Thanks for the help! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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
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 before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Already fixed since kernel 2.6.18.
Our header were a mess and we are working on getting them better.
But we can't timetravel and fix old distributions.
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 before âuid_tâ /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before âs_next_generationâ /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token Already fixed since kernel 2.6.18. Our header were a mess and we are working on getting them better. But we can't timetravel and fix old distributions. 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. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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
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 before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Hi Jörg.
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)
{
return sb-s_fs_info;
}
And therefore the include statement is removed in the exported set of kernel
include files.
So this particular issue is solved with the latest kernel and using the headers
prepared for export.
This tells me that we are on the right track with exporting the headers and
sanitize them.
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 ;) (although I don't know how they will deal with bugreports against older versions) your bug looks certainly valid.. just you're not using the proper header set that the kernel developers suggest ;) -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 guard is bogus. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 SuSE bugs to SuSE; that's more effective ;) (although I don't know how they will deal with bugreports against older versions) your bug looks certainly valid.. just you're not using the proper header set that the kernel developers suggest ;) Even though you put the smiley there, it does not seem fair to expect people to know the latest bits of kernel developement and deployment procedures unless hanging around on lkml is a requirement for linux users. I'm just browsing that list, filtering and ignoring a lot. If I didn't do that, I would not even suspect something like make headers_install to exist, nor would I try to search for it. @Jörg: The responsibility to maintain clean headers shifted only recently, 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 precise error message or description does help. -- W.I.N.D.O.W.S.: Wireless Intelligent Neohuman Designed for Observation and Worldwide Sabotage -- http://www.brunching.com/toys/toy-cyborger.html (down) Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
@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 precise error message or description does help. absolutely. if you find issues with the real kernel headers (eg the make headers_install ones) ... as you have seen there's lots of interest to make sure they're as useful as reasonably possible -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 ./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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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'. > >> > >> 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. M, if you call "cdrecord -scanbus", what do you get? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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//{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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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
#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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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//{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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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
, 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//{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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 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_ 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 , 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//{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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel 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. > > > > 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 scsi-linux-sg.c:#include scsi-linux-sg.c:#include scsi-linux-sg.c:#include scsi-linux-sg.c:#include/* 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 If there wase _one_ clean SCSI pass through interface on Linux, things would be a lot easier. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel 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. 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 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_ 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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'. 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. M, if you call cdrecord -scanbus, what do you get? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
[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 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 ./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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 , 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 , 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel include files
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 , 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
