The first patch copies the gcc-[34] behaviour of eselect compiler support and gcc-${PV} symlinks to gcc 2, and makes it no longer automatically switch versions. The second patch is to enable gcc 2 to build on nptlonly systems; NPTL glibc installs an unusable <bits/stdio-lock.h> header used by <libio.h> (it #includes a private glibc header file which doesn't and shouldn't get installed), so the patch takes Fedora's approach and copies over the non-NPTL header instead (which is also usable with NPTL). With these patches, gcc 2 builds and runs without problems. Portage 2.1_pre5-r1 (default-linux/x86/2006.0, gcc-4.0.2, glibc-2.3.6-r3, 2.6.15-gentoo-r5 i686) ================================================================= System uname: 2.6.15-gentoo-r5 i686 AMD Duron(tm) Processor Gentoo Base System version 1.12.0_pre16 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.91.0.6 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe" DISTDIR="/var/dist" FEATURES="autoconfig collision-protect cvs distlocks noauto notitles sandbox sfperms sign strict" GENTOO_MIRRORS=" http://ftp.easynet.nl/mirror/gentoo http://distfiles.gentoo.org " LANG="en_GB.UTF-8" LDFLAGS="-Wl,--as-needed" LINGUAS="en en_GB ja nl" PKGDIR="/var/pkg" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cvs/gentoo-x86" PORTDIR_OVERLAY="/etc/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X acl acpi asf avi bidi bitmap-fonts bzip2 cdinstall cdparanoia cjk crypt cscope css cups curl dlloader dri dvd dvdread emboss encode firefox ftp gcc-libffi gif gmp gpgme gtk gtk2 idn imlib immqt ipv6 ithreads jpeg kdeenablefinal leim libg++ libwww linuxthreads-tls lynxkeymap mbox mmx mmxext mozdevelop mpeg mplayer ncurses nethack nls noamazon nocxx nodrm non-flattened nopie normalize nossp nptl nptlonly offensive ogg openal opengl oss pango pcre pdflib pic png ppds quicktime readline real reiser4 rtc sdl spell ssl tetex threads truetype truetype-fonts type1-fonts udev unicode usb userlocales v4l verbose vim-pager vorbis win32codecs xine xv xvid zlib zvbi elibc elibc_glibc input_devices input_devices_keyboard input_devices_mouse kernel kernel_linux linguas linguas_en linguas_en_GB linguas_ja linguas_nl userland userland_GNU video_cards video_cards_ati" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL, MAKEOPTS
Created attachment 81075 [details, diff] gcc-2.95.3-r9.ebuild.diff
Created attachment 81076 [details, diff] glibc-2.3.6-r3.ebuild.diff
Comment on attachment 81075 [details, diff] gcc-2.95.3-r9.ebuild.diff no, gcc-2.95.3-r9 is dead
if you really want to help, test my gcc-2 ebuild based on toolchain.eclass: http://dev.gentoo.org/~vapier/gcc2-stages/gcc-2.95.3-r10.ebuild
> src_install() { > die If you want me to try and modify it to make it work, alright, but if you just want me to test something, I think you may have uploaded the wrong file :)
hmm, i seem to have lost my real file ... basically we need a new gcc-2 ebuild that just has a src_unpack() func like most of our other gcc ebuilds ... all the real work is off loaded to toolchain.eclass
Alrighty, if you find it again, I'll be happy to test it, and I can try to write it myself in case you don't. The glibc patch will be necessary even with such a gcc 2 ebuild though, of course.
Created attachment 81264 [details, diff] Updated glibc patch (for C++ programs)
Created attachment 81265 [details, diff] toolchain.eclass patch
Created attachment 81266 [details, diff] gcc-2.95.3-r10 ebuild
Created attachment 81267 [details, diff] gcc 2.95.3 patch for DESTDIR
mmm lets see toolchain.eclass ... i dont get the change in USE=vanilla logic ive added gcc/Makefile.in to the ht_fix_file list the 'version_is_at_least 3' shouldnt be needed around gcj/objc as the functions themselves check to see if the source code supports the language --enable-version-specific-runtime-libs is a bad idea better to put the 'version_is_at_least 3' inside of gcc_movelibs() i'm not slipping in the USE=vanilla/stubs change :p why the use bootstrap change in gcc-config ?
is that glibc hack still applicable to glibc-2.4 ? what exactly is the issue you're trying to address ?
> mmm lets see toolchain.eclass ... > > i dont get the change in USE=vanilla logic gcc 2 won't work with USE=vanilla, at all, so vanilla should not be in IUSE, and the USE flag should be ignored. > ive added gcc/Makefile.in to the ht_fix_file list Thanks. > the 'version_is_at_least 3' shouldnt be needed around gcj/objc as the functions > themselves check to see if the source code supports the language Ah, no problem with that then. (The 'version_is_at_least 3' is still useful, of course, in the part where IUSE gets set.) > --enable-version-specific-runtime-libs is a bad idea Without it, gcc 2's libstdc++ ends up in /usr/lib. Does it cause problems for newer gcc's? > better to put the 'version_is_at_least 3' inside of gcc_movelibs() No problem with that. > i'm not slipping in the USE=vanilla/stubs change :p I told you on IRC when I first showed you the patch that it was simply my cvs diff, not only the gcc 2 related changes. I consider the current behaviour broken (USE=vanilla used to not apply any SSP patches, stub or otherwise, but it was changed because SSP should only be disabled with USE=nossp, and now SSP (possibly stub) patches are (either accidentally or with a misleading comment) always applied), so I fixed it locally, but I haven't bothered to report it as a bug. > why the use bootstrap change in gcc-config ? Also unrelated to gcc 2, but bootstrap (flag) used to rebuild gcc with itself, which is now the default. It is no longer useful except to do part (and only part) of what USE=build already does. I also removed it from IUSE. > is that glibc hack still applicable to glibc-2.4 ? what exactly is the issue > you're trying to address ? Haven't checked if it's applicable to glibc 2.4, will tell you when I can. The issue is that NPTL <bits/{stdio,libc}-lock.h> is completely unusable outside of glibc. NPTL stdio-lock.h includes a glibc internal header which does not and should not get installed, so non-NPTL stdio-lock.h (also usable for NPTL) can be used instead, and for <bits/libc-lock.h> I don't know exactly what was wrong with it, but it broke C++ for gcc 2.
> > why the use bootstrap change in gcc-config ? > > Also unrelated to gcc 2, but bootstrap (flag) used to rebuild gcc with itself, > which is now the default. It is no longer useful except to do part (and only > part) of what USE=build already does. I also removed it from IUSE. Rereading it now though, especially with the comment right before it, tells me it may have been a bad idea. :)
> > i dont get the change in USE=vanilla logic > > gcc 2 won't work with USE=vanilla, at all why not ? > (The 'version_is_at_least 3' is still useful, of > course, in the part where IUSE gets set.) right, we need that > > --enable-version-specific-runtime-libs is a bad idea > > Without it, gcc 2's libstdc++ ends up in /usr/lib. and gcc_movelibs() takes care of that ... > Does it cause problems for newer gcc's? yes, that's why we cut it out ... > Haven't checked if it's applicable to glibc 2.4, will tell you when I can. The > issue is that NPTL <bits/{stdio,libc}-lock.h> is completely unusable outside > <snip> well the headers you're copying linuxthreads headers ... NPTL will not work with gcc-2 so seeing build failure isnt that surprising
> > > i dont get the change in USE=vanilla logic > > > > gcc 2 won't work with USE=vanilla, at all > > why not ? Considering there is a patch in this bug report with the description "gcc 2.95.3 patch for DESTDIR", I figured you could guess :) USE=vanilla would prevent it from being applied, and gcc would be installed directly to / (or abort with sandbox errors) There's also another build process fix in the current gcc 2 patchset already. > > > --enable-version-specific-runtime-libs is a bad idea > > > > Without it, gcc 2's libstdc++ ends up in /usr/lib. > > and gcc_movelibs() takes care of that ... gcc 2 doesn't support --print-multi-os-directory, and after modifying gcc_movelibs to not use that, it didn't work. I don't remember why or how it didn't work, but I'll retest right when I also check glibc 2.4. > > Does it cause problems for newer gcc's? > > yes, that's why we cut it out ... Ah. I suppose it could be used only for gcc 2, it's already used in the current gcc 2 ebuild. > well the headers you're copying linuxthreads headers ... I'm copying headers that actually work (yes, with NPTL). Whether linuxthreads uses them is irrelevant. > NPTL will not work with gcc-2 so seeing build failure isnt that surprising Except for broken headers, there are no problems with gcc 2 and NPTL, unless you want to compile glibc with gcc 2 (which probably breaks right now even without NPTL).
> is that glibc hack still applicable to glibc-2.4 ? what exactly is the issue > you're trying to address ? gcc 2 already won't build with glibc 2.4 for other reasons; glibc 2.4's headers use GCC extensions which didn't yet exist in gcc 2: In file included from /usr/include/sys/types.h:270, from /usr/include/stdlib.h:438, from /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/libgcc2.c:41: /usr/include/bits/pthreadtypes.h:69: warning: unnamed struct/union that defines no instances Which results in /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame In file included from /usr/include/sys/types.h:270, from /usr/include/stdlib.h:438, from /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame.c:42: /usr/include/bits/pthreadtypes.h:69: warning: unnamed struct/union that defines no instances /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame.c:55: extra brace group at end of initializer /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame.c:55: (near initialization for `object_mutex.__data') /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame.c:55: warning: excess elements in struct initializer /var/tmp/portage/gcc-2.95.3-r10/work/gcc-2.95.3/gcc/frame.c:55: warning: (near initialization for `object_mutex.__data') make[2]: *** [libgcc2.a] Error 1 make[2]: Leaving directory `/var/tmp/portage/gcc-2.95.3-r10/work/build/gcc' make[1]: *** [bootstrap-lean] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-2.95.3-r10/work/build/gcc' make: *** [bootstrap-lean] Error 2 Even without that, though, yes, glibc 2.4's <stdio-lock.h> is still broken.
then we should be localizing the hacks in gcc-2, not spreading it into glibc-2.4 should be easy to bundle linuxthreads headers with gcc-2 patchsets and copy them to the local gcc include tree
Well, I now find <bits/pthreadtypes.h> causes errors in tinycc and tendra as well, not just in gcc 2, and the code that they all error out on isn't valid C, so if possible I'd like to avoid "fixing" it by keeping broken headers on the system and only giving gcc 2 access to proper headers.
> Well, I now find <bits/pthreadtypes.h> causes errors in tinycc and tendra as > well, not just in gcc 2, and the code that they all error out on isn't valid C, > so if possible I'd like to avoid "fixing" it by keeping broken headers on the > system and only giving gcc 2 access to proper headers. While I still feel the same way, it's not as big an issue anymore as a patch already existed for tcc which I now put in portage, and I got tendra accepting it myself.
Comment on attachment 81267 [details, diff] gcc 2.95.3 patch for DESTDIR merged
Comment on attachment 81264 [details, diff] Updated glibc patch (for C++ programs) not going to happen
Comment on attachment 81265 [details, diff] toolchain.eclass patch ive merged most of these things ... we purposefully took --enable-version-specific-runtime-libs out of the configure arguments because it breaks things
gcc-2.95.3-r10 is in portage ... ive made sure that it still works in gcc2-native system and in an x86 system with a gcc-3.4.4 compiler
