[arch-dev-public] gcc-4.7 toolchain in [testing]
I have uploaded the gcc-4.7 toolchain to [testing]. gcc-4.7.0-1 - upstream update - default linker hash style is "gnu" (we can now remove that from LDFLAGS in makepkg.conf) - soname bump for libobjc (rebuild done) binutils-2.22-5 - new upstream snapshot linux-api-headers-3.3-1 - upstream update glibc-2.15-8 - install timezone binaries (removed from tzdata) tzdata-2012b-2 - use binaries from glibc libtool-2.4.2-5 - rebuild As usual with major gcc updates, don't expect packages built against the new toolchain to work with the old one... (especially c++ software). I am quite happy this is working well (I am ~1/3 of the way through rebuilding [core] and have seen no failures so far), but there are a couple of minor test-suite issues I will investigate further. So this will be in [testing] for the usual couple of weeks. Allan
On 24/03/12 20:09, Allan McRae wrote:
I have uploaded the gcc-4.7 toolchain to [testing].
gcc-4.7.0-1 - upstream update - default linker hash style is "gnu" (we can now remove that from LDFLAGS in makepkg.conf) - soname bump for libobjc (rebuild done)
binutils-2.22-5 - new upstream snapshot
linux-api-headers-3.3-1 - upstream update
glibc-2.15-8 - install timezone binaries (removed from tzdata)
tzdata-2012b-2 - use binaries from glibc
libtool-2.4.2-5 - rebuild
As usual with major gcc updates, don't expect packages built against the new toolchain to work with the old one... (especially c++ software).
I am quite happy this is working well (I am ~1/3 of the way through rebuilding [core] and have seen no failures so far), but there are a couple of minor test-suite issues I will investigate further. So this will be in [testing] for the usual couple of weeks.
FYI: these are the new build failures in [core] with this toolchain: iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64' krb5: deltat.c:1694:12: error: 'yylval' may be used uninitialized in this function [-Werror=maybe-uninitialized] syslinux: /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t' Two are linux-api-headers related and one from -Werror Allan
On 24/03/12 22:20, Allan McRae wrote:
On 24/03/12 20:09, Allan McRae wrote:
I have uploaded the gcc-4.7 toolchain to [testing].
gcc-4.7.0-1 - upstream update - default linker hash style is "gnu" (we can now remove that from LDFLAGS in makepkg.conf) - soname bump for libobjc (rebuild done)
binutils-2.22-5 - new upstream snapshot
linux-api-headers-3.3-1 - upstream update
glibc-2.15-8 - install timezone binaries (removed from tzdata)
tzdata-2012b-2 - use binaries from glibc
libtool-2.4.2-5 - rebuild
As usual with major gcc updates, don't expect packages built against the new toolchain to work with the old one... (especially c++ software).
I am quite happy this is working well (I am ~1/3 of the way through rebuilding [core] and have seen no failures so far), but there are a couple of minor test-suite issues I will investigate further. So this will be in [testing] for the usual couple of weeks.
FYI: these are the new build failures in [core] with this toolchain:
iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64'
krb5: deltat.c:1694:12: error: 'yylval' may be used uninitialized in this function [-Werror=maybe-uninitialized]
syslinux: /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'
Two are linux-api-headers related and one from -Werror
Also... there is a conflict between gcc and gcc-fortran. It is exactly the same file so the use of force is OK. No [testing] user is stupid enough to do a -Syuf, right? Allan
On Sat, Mar 24, 2012 at 1:20 PM, Allan McRae <allan@archlinux.org> wrote:
On 24/03/12 20:09, Allan McRae wrote:
I have uploaded the gcc-4.7 toolchain to [testing].
gcc-4.7.0-1 - upstream update - default linker hash style is "gnu" (we can now remove that from LDFLAGS in makepkg.conf) - soname bump for libobjc (rebuild done)
binutils-2.22-5 - new upstream snapshot
linux-api-headers-3.3-1 - upstream update
glibc-2.15-8 - install timezone binaries (removed from tzdata)
tzdata-2012b-2 - use binaries from glibc
libtool-2.4.2-5 - rebuild
As usual with major gcc updates, don't expect packages built against the new toolchain to work with the old one... (especially c++ software).
I am quite happy this is working well (I am ~1/3 of the way through rebuilding [core] and have seen no failures so far), but there are a couple of minor test-suite issues I will investigate further. So this will be in [testing] for the usual couple of weeks.
FYI: these are the new build failures in [core] with this toolchain:
iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64'
A fixed package is in [testing] now. Ronald
On 24/03/12 22:58, Ronald van Haren wrote:
On Sat, Mar 24, 2012 at 1:20 PM, Allan McRae <allan@archlinux.org> wrote:
iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64'
A fixed package is in [testing] now.
My solution was to add: rm include/linux/types.h before the configure. iptables should be using the system one if it is there. Then I noticed.... # FS#25358: libxt_statistic.so undefined symbol: lround export LDFLAGS='-lm' which is clearly wrong. I also have no idea why "unset CFLAGS; unset LDFLAGS" is done after all the building is complete... Allan
On Sat, Mar 24, 2012 at 2:12 PM, Allan McRae <allan@archlinux.org> wrote:
On 24/03/12 22:58, Ronald van Haren wrote:
On Sat, Mar 24, 2012 at 1:20 PM, Allan McRae <allan@archlinux.org> wrote:
iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64'
A fixed package is in [testing] now.
My solution was to add:
rm include/linux/types.h
before the configure. iptables should be using the system one if it is there.
Fine with me. Changed in -3.
Then I noticed....
# FS#25358: libxt_statistic.so undefined symbol: lround export LDFLAGS='-lm'
which is clearly wrong.
I also have no idea why "unset CFLAGS; unset LDFLAGS" is done after all the building is complete...
Allan
Didn't look at it, but it doesn't make much sense. Removed both in -3 (FS#25358 is fixed upstream). Ronald
Le 2012-03-24 08:20, Allan McRae a écrit :
On 24/03/12 20:09, Allan McRae wrote:
I have uploaded the gcc-4.7 toolchain to [testing].
gcc-4.7.0-1 - upstream update - default linker hash style is "gnu" (we can now remove that from LDFLAGS in makepkg.conf) - soname bump for libobjc (rebuild done)
binutils-2.22-5 - new upstream snapshot
linux-api-headers-3.3-1 - upstream update
glibc-2.15-8 - install timezone binaries (removed from tzdata)
tzdata-2012b-2 - use binaries from glibc
libtool-2.4.2-5 - rebuild
As usual with major gcc updates, don't expect packages built against the new toolchain to work with the old one... (especially c++ software).
I am quite happy this is working well (I am ~1/3 of the way through rebuilding [core] and have seen no failures so far), but there are a couple of minor test-suite issues I will investigate further. So this will be in [testing] for the usual couple of weeks.
FYI: these are the new build failures in [core] with this toolchain:
iptables: /usr/include/linux/if_packet.h:176:2: error: unknown type name '__aligned_u64'
krb5: deltat.c:1694:12: error: 'yylval' may be used uninitialized in this function [-Werror=maybe-uninitialized]
syslinux: /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'
Two are linux-api-headers related and one from -Werror
Allan krb5 fixed in [testing]. As the error is in generated code, we simply tell gcc to ignore the error.
Stéphane
participants (3)
-
Allan McRae
-
Ronald van Haren
-
Stéphane Gaudreault