[arch-dev-public] gcc 4.3 and archlinux
Hi all, I've prepared gcc 4.3.0 for the x86_64 platform in testing: - kernel-headers updated to 2.6.24.3 - glibc patched with some upstream CVS patches borrowed from gentoo - binutils rebuilt with gcc 4.3 and glibc 2.7-8 - gcc-libs updated to 4.3.0 - gcc updated to 4.3.0 and patched to support gcj without installing/building it (gcc should be able to build java files when gcj is installed now) - removed gcc-fortran provides from gcc-libs, as we had a sobump - changed gcc-gcj to upstream tarballs instead of Ubuntu branch - rebuilt gjdoc which is a native java program - updated java-gcj-compat - rebuilt all fortran applications against new gcc-libs and changed dependencies In the meanwhile, I found out one big change: gcc 4.3 doesn't include C functions anymore when including c++ includes. This breaks a horrible amount of packages, but fixing is easy: Whenever there's a missing function, look it up in its manpage: strcpy: man 3 strcpy, look for include, which will be <string.h> in this case. As we're using C++ now and want a C include, this will become #include <cstring> without the .h and a c prepended. As gcc 4.3 should be backwards compatible with 4.2 (except for libgcj and libgfortran sonames), I don't think there's much trouble moving these packages to core and extra. I'd like to have these merged after Tobias has finished our ISOs (and we have enough signoffs), as I don't want to make big changes right before a release.
On Sun, 2008-03-09 at 22:52 +0200, Roman Kyrylych wrote:
Huh? We need to patch a lot of C++ source code that relies on C includes?
Functions like malloc, strlen, strcpy, etc need C includes. The offended packages don't include these files, which is known to fail on GCC 4.3. Older compilers include the required headers via other included headers somehow, so these programs don't look broken on older compilers. The example I showed is the common way to fix these packages when we run into them.
On Sun, Mar 9, 2008 at 4:54 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
To be clear, the C++ standard specifies what functions MUST be part of a given include, but allow any other functions/symbols to also be included. This is actually the main reason why "using namespace std" is discouraged for beginners - because any header could import an ungodly amount of symbols into the global namespace by doing that. So yeah, it sounds like they cleaned things up and now improper C++ code breaks. It's a good thing, if you ask me.
participants (3)
-
Aaron Griffin
-
Jan de Groot
-
Roman Kyrylych