Gentoo Archives: gentoo-dev

From: Peter Hjalmarsson <xake@×××××××××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild
Date: Sun, 20 Jun 2010 16:05:48
Message-Id: 1277049908.22112.16.camel@lillen
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild by Arfrever Frehtes Taifersar Arahesis
sön 2010-06-20 klockan 15:55 +0200 skrev Arfrever Frehtes Taifersar
Arahesis:
> > This problem is probably caused by bugs in Python 2, which have been fixed in Python 3. > > $ echo 'a = True' > test.pyx > $ cython test.pyx > $ gcc -O2 -Wall -I/usr/include/python3.1 -c test.c > $ gcc -O2 -Wall -I/usr/include/python2.6 -c test.c > test.c: In function ‘inittest’: > test.c:479: warning: dereferencing type-punned pointer will break strict-aliasing rules > test.c:479: warning: dereferencing type-punned pointer will break strict-aliasing rules > test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break strict-aliasing rules > test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break strict-aliasing rules > test.c:479: note: initialized from here > test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules > test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules > test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules > test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break strict-aliasing rules > test.c:479: note: initialized from here >
Actually this makes me question the append-flag even more. Why mess with what gcc does with the code for all versions of python if it works for x version of python? And "only" for som warnings? I could have understand a bit more if it was Errors. Also why not even a comment saying? Currently as one of the users of hardened and helping Zorry out with the hardened toolchain I have seen many packages filter flags like -fPIE and -fstack-protector without a comment on why, where and how it broke, and noone remeber why. New versions comes of software and if you do not know why it broke with a cflag you cannot test if the breakage is still there. This line of code is fine and all that until you forget why you added that flag or you retire and a later maintainer of the package does not dare to touch the flag since they do not know why it was added and what will break if the remove that line of ebuild code.