[Dovecot] PATCH: compile dovecot-1.1.beta14 with gcc 2.95
Hi,
I patched dovecot-1.1.beta14 to compile under gcc 2.95. __builtin_expect and __attribute__((malloc)) are only available since gcc 3.0, and __builtin_types_compatible_p since 3.1.
Also the flexible array members (char a[]) are not available for gcc 2.95. So I replaced them with zero-extent arrays (char a[0]), which should also work, but that is gcc specific. A general pointer (char* a) should work as well, I guess.
I have attached a patch that fixes all this. It is for beta13 but also works on beta14.
BTW.: There is a typo in src/login-common/main.c, it's equivalent, not equilevant.
Cheers,
Sven
-- http://sven.anderson.de "Believe those who are seeking the truth. tel: +49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
On Wed, 2008-01-23 at 16:57 +0100, Sven Anderson wrote:
I patched dovecot-1.1.beta14 to compile under gcc 2.95. __builtin_expect and __attribute__((malloc)) are only available since gcc 3.0, and __builtin_types_compatible_p since 3.1.
Thanks, committed.
Also the flexible array members (char a[]) are not available for gcc 2.95. So I replaced them with zero-extent arrays (char a[0]), which should also work, but that is gcc specific. A general pointer (char* a) should work as well, I guess.
char a[] is C99 standard, so I'll keep using that. There aren't many gcc 2.95 users anymore.
BTW.: There is a typo in src/login-common/main.c, it's equivalent, not equilevant.
Fixed. I noticed only a year or two ago that I had been misspelling it for ages.
As a follow-up on this, these two lines also helped me to compile the 1.1rc1
on gcc 2.96:
diff -ru dovecot-1.1.beta13/src/lib/str-find.c
dovecot-1.1.beta13.patched/src/lib/str-find.c
--- dovecot-1.1.beta13/src/lib/str-find.c Tue Oct 23 16:01:16 2007
+++ dovecot-1.1.beta13.patched/src/lib/str-find.c Thu Jan 17 14:08:03
2008
@@ -12,7 +12,7 @@
unsigned int match_count;
int badtab[UCHAR_MAX+1];
- int goodtab[];
+ int goodtab[0];
};
static void init_badtab(struct str_find_context *ctx)
diff -ru dovecot-1.1.beta13/src/lib-imap/imap-match.c
dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c
--- dovecot-1.1.beta13/src/lib-imap/imap-match.c Sun Dec 9 19:14:27
2007
+++ dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c Thu Jan 17
14:09:02 2008
@@ -19,7 +19,7 @@
struct imap_match_pattern *patterns;
char sep;
- char patterns_data[];
+ char patterns_data[0];
};
Regards,
KAM
----- Original Message -----
From: "Sven Anderson"
Hi,
I patched dovecot-1.1.beta14 to compile under gcc 2.95. __builtin_expect and __attribute__((malloc)) are only available since gcc 3.0, and __builtin_types_compatible_p since 3.1.
Also the flexible array members (char a[]) are not available for gcc 2.95. So I replaced them with zero-extent arrays (char a[0]), which should also work, but that is gcc specific. A general pointer (char* a) should work as well, I guess.
I have attached a patch that fixes all this. It is for beta13 but also works on beta14.
BTW.: There is a typo in src/login-common/main.c, it's equivalent, not equilevant.
Cheers,
Sven
-- http://sven.anderson.de "Believe those who are seeking the truth. tel: +49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
This is included in my patch already, but Timo didn't want to commit it, since [0] is gcc specific, and [] is C99 standard. Kevin A. McGrail schrieb:
As a follow-up on this, these two lines also helped me to compile the 1.1rc1 on gcc 2.96:
diff -ru dovecot-1.1.beta13/src/lib/str-find.c dovecot-1.1.beta13.patched/src/lib/str-find.c --- dovecot-1.1.beta13/src/lib/str-find.c Tue Oct 23 16:01:16 2007 +++ dovecot-1.1.beta13.patched/src/lib/str-find.c Thu Jan 17 14:08:03 2008 @@ -12,7 +12,7 @@ unsigned int match_count;
int badtab[UCHAR_MAX+1]; - int goodtab[]; + int goodtab[0]; };
static void init_badtab(struct str_find_context *ctx) diff -ru dovecot-1.1.beta13/src/lib-imap/imap-match.c dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c --- dovecot-1.1.beta13/src/lib-imap/imap-match.c Sun Dec 9 19:14:27 2007 +++ dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c Thu Jan 17 14:09:02 2008 @@ -19,7 +19,7 @@ struct imap_match_pattern *patterns;
char sep; - char patterns_data[]; + char patterns_data[0]; };
-- http://sven.anderson.de "Believe those who are seeking the truth. tel: +49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
I can't argue with that logic but documenting it in a wiki or INSTALL or
including the patches with the distribution might be more agreeable.
And yes, the patch below was a cut and paste from your patch. I didn't mean
to say otherwise just to point out that for gcc 2.96, only two small array
size changes were needed.
Regards,
KAM
----- Original Message -----
From: "Sven Anderson"
This is included in my patch already, but Timo didn't want to commit it, since [0] is gcc specific, and [] is C99 standard.
Kevin A. McGrail schrieb:
As a follow-up on this, these two lines also helped me to compile the 1.1rc1 on gcc 2.96:
diff -ru dovecot-1.1.beta13/src/lib/str-find.c dovecot-1.1.beta13.patched/src/lib/str-find.c --- dovecot-1.1.beta13/src/lib/str-find.c Tue Oct 23 16:01:16 2007 +++ dovecot-1.1.beta13.patched/src/lib/str-find.c Thu Jan 17 14:08:03 2008 @@ -12,7 +12,7 @@ unsigned int match_count;
int badtab[UCHAR_MAX+1]; - int goodtab[]; + int goodtab[0]; };
static void init_badtab(struct str_find_context *ctx) diff -ru dovecot-1.1.beta13/src/lib-imap/imap-match.c dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c --- dovecot-1.1.beta13/src/lib-imap/imap-match.c Sun Dec 9 19:14:27 2007 +++ dovecot-1.1.beta13.patched/src/lib-imap/imap-match.c Thu Jan 17 14:09:02 2008 @@ -19,7 +19,7 @@ struct imap_match_pattern *patterns;
char sep; - char patterns_data[]; + char patterns_data[0]; };
On Feb 27, 2008, at 4:22 PM, Kevin A. McGrail wrote:
I can't argue with that logic but documenting it in a wiki or
INSTALL or including the patches with the distribution might be more
agreeable.
Why are you people still using so old gcc versions? I guess I could
accept a patch something like:
#if old gcc version # define FLEXIBLE_ARRAY 0 #else # define FLEXIBLE_ARRAY #endif
.. int goodtab[FLEXIBLE_ARRAY]; ..
On Wed, 27 Feb 2008, Timo Sirainen wrote:
On Feb 27, 2008, at 4:22 PM, Kevin A. McGrail wrote:
I can't argue with that logic but documenting it in a wiki or INSTALL or including the patches with the distribution might be more agreeable.
Why are you people still using so old gcc versions?
As an observer, I'd like to remark that it's amazing that twentiety-century known-broken non-releases http://gcc.gnu.org/gcc-2.96.html of GCC are in use in 2008.
I'm honestly curious what keeps you guys on them.
-- Asheesh.
-- Maybe you can't buy happiness, but these days you can certainly charge it.
Well, for me, it's a vast number of boxes deployed and often maintained by others that are running stabling for 8+ years making the nuance of upgrading to a newer version of GCC fairly mute from a lay persons perspective. Seriously, how can you argue with a non-technical user that their box installed in 2001 has a "problem" when everything is working "fine"?
Plus it annoys Timo and that's just an extra bonus ;-)
regards, KAM ----- Original Message ----- From: "Asheesh Laroia" asheesh@asheesh.org To: "Dovecot Mailing List" dovecot@dovecot.org Cc: "Kevin A. McGrail" kmcgrail@pccc.com; "Sven Anderson" sven@anderson.de Sent: Wednesday, February 27, 2008 4:35 PM Subject: Re: [Dovecot] Follow-up re: gcc 2.96 - Re: PATCH: compile dovecot-1.1.beta14 with gcc 2.95
On Wed, 27 Feb 2008, Timo Sirainen wrote:
On Feb 27, 2008, at 4:22 PM, Kevin A. McGrail wrote:
I can't argue with that logic but documenting it in a wiki or INSTALL or including the patches with the distribution might be more agreeable.
Why are you people still using so old gcc versions?
As an observer, I'd like to remark that it's amazing that twentiety-century known-broken non-releases http://gcc.gnu.org/gcc-2.96.html of GCC are in use in 2008.
I'm honestly curious what keeps you guys on them.
-- Asheesh.
-- Maybe you can't buy happiness, but these days you can certainly charge it.
On 2/27/2008, Kevin A. McGrail (kmcgrail@pccc.com) wrote:
Well, for me, it's a vast number of boxes deployed and often maintained by others that are running stabling for 8+ years making the nuance of upgrading to a newer version of GCC fairly mute from a lay persons perspective. Seriously, how can you argue with a non-technical user that their box installed in 2001 has a "problem" when everything is working "fine"?
Plus it annoys Timo and that's just an extra bonus ;-)
All kidding and joking aside... this is pure laziness on the part of the sys admin, nothing more. IF you find this remark offensive, then you must be guilty.
The 'client' shouldn't even be involved in such a decision... if you are responsible for a box, it is your responsibility to make sure it is secure - and how can you trust ANYTHING on that box if you are using a broken/buggy compiler?
--
Best regards,
Charles
on 2/27/2008 1:46 PM Kevin A. McGrail spake the following:
Well, for me, it's a vast number of boxes deployed and often maintained by others that are running stabling for 8+ years making the nuance of upgrading to a newer version of GCC fairly mute from a lay persons perspective. Seriously, how can you argue with a non-technical user that their box installed in 2001 has a "problem" when everything is working "fine"?
How much longer can a system be expected to run? 8+ years at 24/7 is about a half a million hours. Drives are getting old and expensive to replace. Processors are probably slow. Energy use is high. Motherboard capacitors are probably drying up. The systems are past a safe point and are getting closer to the "great e-waste pile in the sky".
And why would someone install the same old OS on new hardware, and would it support it.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
Scott Silva wrote:
How much longer can a system be expected to run? 8+ years at 24/7 is about a half a million hours. Drives are getting old and expensive to replace. Processors are probably slow. Energy use is high. Motherboard capacitors are probably drying up. The systems are past a safe point and are getting closer to the "great e-waste pile in the sky".
I retired a 13 year old DEC AlphaStation 5/266 yesterday... Legacy systems are still doing useful things. You just have to make sure that they're isolated from the outside as they can't be patched or upgraded. (e.g. newer versions of OpenSSH won't compile under Digital UNIX 4.2C)
Steve
P.S. For the record, the DEC box has only ever needed to be shut down for power outages and (in its early life) OS upgrades. It ran 24/7 and never had a hardware fault (and still doesn't). Now that's reliable hardware!
Computer Systems Administrator, E-Mail:-steve@earth.ox.ac.uk Department of Earth Sciences, Tel:- +44 (0)1865 282110 University of Oxford, Parks Road, Oxford, UK. Fax:- +44 (0)1865 272072
on 2-29-2008 2:36 AM Stephen Usher spake the following:
Scott Silva wrote:
How much longer can a system be expected to run? 8+ years at 24/7 is about a half a million hours. Drives are getting old and expensive to replace. Processors are probably slow. Energy use is high. Motherboard capacitors are probably drying up. The systems are past a safe point and are getting closer to the "great e-waste pile in the sky".
I retired a 13 year old DEC AlphaStation 5/266 yesterday... Legacy systems are still doing useful things. You just have to make sure that they're isolated from the outside as they can't be patched or upgraded. (e.g. newer versions of OpenSSH won't compile under Digital UNIX 4.2C)
Steve
P.S. For the record, the DEC box has only ever needed to be shut down for power outages and (in its early life) OS upgrades. It ran 24/7 and never had a hardware fault (and still doesn't). Now that's reliable hardware! True, but just because it hasn't failed in 13 years doesn't mean that it wont fail tomorrow. Or next week. Everything wears out sooner or later. I don't feel right using a server for critical systems for more than 5 years. I usually will warranty them to that age, and then move them on.
The servers that used to handle our e-mail needs a few years ago are now terabyte backup targets. A new raid controller and some new drives, and the critical part of them is as good as new. If a MB or power supply dies I can move the drive cage to another system and get to the data in less than an hour.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
Am 27.02.2008 um 15:31 schrieb Timo Sirainen:
Why are you people still using so old gcc versions? I guess I could
accept a patch something like:
I'm using an old custom-made vserver system, and it's running fine, so
why spend a lot of time to migrate to a newer distribution?
Sven
-- http://sven.anderson.de "Believe those who are seeking the truth. tel: +49-551-9969285 Doubt those who find it." mobile: +49-179-4939223 (André Gide)
on 2/27/2008 2:06 PM Sven Anderson spake the following:
Am 27.02.2008 um 15:31 schrieb Timo Sirainen:
Why are you people still using so old gcc versions? I guess I could accept a patch something like:
I'm using an old custom-made vserver system, and it's running fine, so why spend a lot of time to migrate to a newer distribution?
Sven
It's running fine until it gets rooted/compromised. Then what do you do?
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
participants (7)
-
Asheesh Laroia
-
Charles Marcus
-
Kevin A. McGrail
-
Scott Silva
-
Stephen Usher
-
Sven Anderson
-
Timo Sirainen