From: Will N. <wil...@gm...> - 2006-06-27 12:58:14
|
Hi all, Attached are a few more gcc 2.95.2 compatibility changes. They are all similar C "correctness" fixes which make gcc 2.95.2 happier and should not affect the resulting executable. The changes to nftw are the most extensive but are still quite simple. |
From: Mike F. <va...@ge...> - 2006-06-28 05:30:11
|
On Tuesday 27 June 2006 08:58, Will Newton wrote: > Attached are a few more gcc 2.95.2 compatibility changes. They are all > similar C "correctness" fixes which make gcc 2.95.2 happier and should > not affect the resulting executable. The changes to nftw are the most > extensive but are still quite simple. i merged a bunch of these then kind of forgot where i was ... so yeah, sync= up=20 and tell me what i missed ;) =2Dmike |
From: Will N. <wil...@gm...> - 2006-07-05 11:22:41
Attachments:
gcc-2.95.patch
|
On 6/28/06, Mike Frysinger <va...@ge...> wrote: Hi Mike, > i merged a bunch of these then kind of forgot where i was ... so yeah, sync up > and tell me what i missed ;) I've attached my latest diff against CVS for gcc 2.95.2 support. |
From: Will N. <wil...@gm...> - 2006-06-28 10:24:03
|
On 6/28/06, Mike Frysinger <va...@ge...> wrote: > On Tuesday 27 June 2006 08:58, Will Newton wrote: > > Attached are a few more gcc 2.95.2 compatibility changes. They are all > > similar C "correctness" fixes which make gcc 2.95.2 happier and should > > not affect the resulting executable. The changes to nftw are the most > > extensive but are still quite simple. > > i merged a bunch of these then kind of forgot where i was ... so yeah, sync up > and tell me what i missed ;) Thanks! I've attached the patches that are not fully applied to my latest anoncvs tree (not sure how up to date that is with Sourceforge these days). To get the latest tree to build I had to make another set of changes (makefiles.patch) which actually revert some changes you made recently. I'm not sure if I understand the USC_LIB thing correctly, but it seems it is intended to be used by libraries that include the usctest.h header but do not want to have their own copies of various globals. So as I understand it a testcase should never define _USC_LIB_ but any common library code that includes usctest.h should define _USC_LIB_. Is that how it is intended to work? |
From: David W. <da...@ar...> - 2006-06-28 17:11:00
|
On Wed, 28 Jun 2006 06:23:59 -0400, Will Newton <wil...@gm...> =20 wrote: > On 6/28/06, Mike Frysinger <va...@ge...> wrote: >> On Tuesday 27 June 2006 08:58, Will Newton wrote: >> > Attached are a few more gcc 2.95.2 compatibility changes. They are a= ll >> > similar C "correctness" fixes which make gcc 2.95.2 happier and shou= ld >> > not affect the resulting executable. The changes to nftw are the mos= t >> > extensive but are still quite simple. >> >> i merged a bunch of these then kind of forgot where i was ... so yeah,= =20 >> sync up >> and tell me what i missed ;) > > Thanks! I've attached the patches that are not fully applied to my > latest anoncvs tree (not sure how up to date that is with Sourceforge > these days). > > To get the latest tree to build I had to make another set of changes > (makefiles.patch) which actually revert some changes you made > recently. I'm not sure if I understand the USC_LIB thing correctly, > but it seems it is intended to be used by libraries that include the > usctest.h header but do not want to have their own copies of various > globals. So as I understand it a testcase should never define > _USC_LIB_ but any common library code that includes usctest.h should > define _USC_LIB_. Is that how it is intended to work? correct! It's for some compiler complaining about multi-definition of =20 variables or functions. --=20 David |