After NPTL migration, strange gcc-3.4.3-20050110 message

wrc1944

[I posted this in poprtage/programming, and got 80 reads, but 0 responses. I figured since I'm ~x86 and run unsupported kernels, maybe I was in the wrong forum, so I deleted it there, and am re-posting here, in hopes someone knows what's going on, and if i need to take any corrective action]

I just migrated to NPTL NPTLONLY (followed wiki instructions), and rebuilt glibc, gcc-config, binutils, and gcc. All went OK, except I get the following message after I emerge sync'd and found a new upgrade for gcc from 3.4.3-20050110-r1 to -r2 (had to rebuild libtool twice to get -r2 to compile). I had used -r1 since it came out, with no problems. So- I rebuilt both -r1 and then -r2 AFTER setting NPTL, and both had the following message- I don't recall seeing it when I emerged r1 originally some weeks ago, without NPTL set.

Anyway, what does this message mean- about it saying 20050110 doesn't exist anymore, when it does exist, and is my default gcc version? Things seem to be working OK so far. I haven't had any of the old libstdc++.la problems yet.
------------------------------------------------------------------------------------------------------------------
>>> /usr/libexec/gcc/i686-pc-linux-gnu/3.4.3-20050110/cc1plus
--- /sbin/
>>> /sbin/fix_libtool_files.sh
* The currently selected specs-specific gcc config,
* 20050110, doesn't exist anymore. This is usually
* due to enabling/disabling hardened or switching to a version
* of gcc that doesnt create multiple specs files. The default
* config will be used, and the previous preference forgotten.
* Switching to i686-pc-linux-gnu-3.4.3-20050110 compiler ... [ ok ]

* If you intend to use the gcc from the new profile in an already
* running shell, please remember to do:

* # source /etc/profile

* If you have issues with packages unable to locate libstdc++.la,
* then try running 'fix_libtool_files.sh' on the old gcc versions.

>>> Regenerating /etc/ld.so.cache...
* Caching service dependencies ... [ ok ]
>>> sys-devel/gcc-3.4.3.20050110-r2 merged.

sys-devel/gcc
selected: 3.4.3.20050110-r1
protected: 3.4.3.20050110-r2 3.3.4-r1
omitted: none
-----------------------------------------------
MY INFO:

wrc@mymachine ~ $ gcc-config -l
[1] i686-pc-linux-gnu-3.3.4
[2] i686-pc-linux-gnu-3.4.3-20050110 *
[3] i686-pc-linux-gnu-3.4.3-20050110-hardened
[4] i686-pc-linux-gnu-3.4.3-20050110-hardenednopie
[5] i686-pc-linux-gnu-3.4.3-20050110-hardenednossp

mymachine wrc # emerge --info
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.12-rc1-vivid1 i686)
=================================================================
System uname: 2.6.12-rc1-vivid1 i686 AMD Athlon(tm) XP 1800+
Gentoo Base System version 1.6.10
Python: dev-lang/python-2.2.3-r1,dev-lang/python-2.3.5 [2.3.5 (#1, Feb 17 2005, 20:00:36)]
dev-lang/python: 2.2.3-r1, 2.3.5
sys-devel/autoconf: 2.59-r6, 2.13
sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5
sys-devel/binutils: 2.15.92.0.2-r8
sys-devel/libtool: 1.5.14
virtual/os-headers: 2.6.8.1-r4
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=athlon-xp -ftracer -fweb -frename-registers -ffast-math -fomit-frame-pointer -fprefetch-loop-arrays -pipe -falign-functions=64 -momit-leaf-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=athlon-xp -ftracer -fweb -frename-registers -ffast-math -fomit-frame-pointer -fprefetch-loop-arrays -pipe -falign-functions=64 -momit-leaf-frame-pointer -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.osuosl.org/distfiles http://mirror.gentoo.no/ http://gentoo.chem.wisc.edu/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X alsa apm arts avi berkdb bitmap-fonts caps cdr crypt cups curl emboss encode esd fam flac fluidsynth foomaticdb fortran gaim gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 jack jack-tmpfs jpeg kde ladspa libg++ libwww mad mikmod mmx motif mp3 mpeg ncurses nls nptl nptlonly oggvorbis opengl oss other_var1 other_var2 pam pdflib perl png ppds python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts xml2 xmms xv zlib"
Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL
_________________
Abit KX7-333, MSI KT3 Ultra 2
AthlonXP 1700+ Thoroughbred B's,
512MB Crucial PC2700 DDR
Maxtor ATA133 40GB 7200rpm drives
ATI Radeon 9000 Pro, Audigy 2 ZS sound
Gentoo ~x86, VidaLinux, winXP Pro-sp2
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

wrc1944 · Posted: Mon Apr 11, 2005 5:15 pm Post subject:

184 views and zero responses? Hasn't anyone else wondered about this, or had it show up in their emerge output?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

steve_d555 · Posted: Tue Apr 12, 2005 4:46 am Post subject:

Try taking out the use flag NPTLONLY, sometimes that can lead to problems with some programs. I have no idea, but since that is one of the things that has changed, why not.
_________________
rubyforums | blog | boxwhore

wrc1944 · Posted: Tue Apr 12, 2005 6:17 am Post subject:

Hmmmmm. I had tried that first thing, as I had read about various problems. However, I couldn't recompile glibc after going with NPTL without it, so I had to leave it in.

I'm starting to think my system might have a very slight misconfiguration somehow relating to gcc, glibc, and/or xorg-x11. Everything works well. but i sometimes get these types of weird messages on emerge updates.

steve_d555,
Thanks for the suggestion! First response to this in hundreds of views.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Bob P · Posted: Tue Apr 12, 2005 9:22 am Post subject:

i dunno jack about athlons, but i have a few opinions that may or may not be helpful.

first, i think you've got to be one brave soul to put ~x86 in your accept keywords, given the current state of flux in the GCC 343 toolkit. there have been huge problems with gcc-config lately that the devs have been trying to silently fix. my preferred method is to selectively use ~arch only for specific packages, enabling it on a per package basis via package.keywords.

your cflag settings are rather aggessive. fast-math is a known troublemaker. i would back off on a few of them and reduce the optimization level, and rebuild.

if you have a statically retained library, then no amount of recompiling the toolkit components in isolation is going to help you. you have to rebuild the entire system redundantly in order to fix the toolchain problem.

NPTLONLY causes problems. i'd get rid of it.

i would also remove the LDFLAGS.

so my recommendation would be:

CFLAGS="-O2 -march=athlon-xp -ftracer -fweb -frename-registers -fomit-frame-pointer -pipe -momit-leaf-frame-pointer -force-addr"

ACCEPT_KEYWORDS="x86"

and then i would do this:

emerge -e system
emerge -e system
emerge -e world
emerge -e world

if you do all of these things, i guarantee that your system will work.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

Bob P · Posted: Tue Apr 12, 2005 9:23 am Post subject:

btw, Portage & Programming was the right place to post for your problem. sometimes it just takes time. :wink:

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

wrc1944 · Posted: Tue Apr 12, 2005 1:47 pm Post subject:

Bob P,
Many thanks for your feedback. I've read many of your posts, and have always learned a lot, and can't wait to see how the Jackass Project turns out. Let me briefly address your points, as to my experience so far. BTW, I only run AMD athlon systems, so maybe that's a factor in my experiences so far. I sync my main box about once a week.

In my case, I've used ~x86 since I started Gentoo, and really have had far less problems than I've ever had with any other distro. I came from Mandrake, and have installed and tested many many others (source and binary), including freebsd. Any hiccup (usually self-inflicted) with ~x86 has always been resolved quickly , but they are so few and far between, I can't imagine x86 would make noticable improvement in my system stability. I would describe my Gentoo boxes as consistently "rock solid," working fine for what I use them for. I would think in running hybrid x86/~x86 systems, it would be hard to keep track of things. I'll still swear by ~x86 for my usage, which admittedly is basically just home desktop office/multimedia/internet, so I might not run into problems other users might have.

Isn't -force-addr redundant, as it is enabled at levels -O2, -O3, -Os? I've also read recently that in most cases it actually degrades performance. I did use it previously, but dropped it about a year ago.

On my boxes, I've so far never traced any problem to -O3, as opposed to -O2.

Most of the recent info I've seen (and my own experience) about -ffast-math and recent gcc versions supports the position that previous problems with floating point no longer apply. At least in my case, I've used it for over a year, and have run into only 2 or 3 problems. The benchmarks I've seen definitely support it being one of the best performancing enhancing optimization flags available.

After reading your other thread, I have adopted

emerge -e system
emerge -e system
emerge -e world
emerge -e world

On the NPTLONLY thing, I wanted to not use it, but glibc wouldn't compile without it (I tried dropping cflags, but no luck- it really appeared to be that glibc needed NPTLONLY). And, the NPTL wiki still says to use it. However, next time I do emerge -e I'll try dropping it again.

I tried prelink, and noticed perhaps slightly faster loading of apps. I then read about LDFLAGS, and so then I tried them, with essentially the same results- perhaps subjectively perceived as slightly better. I'm curious as to why would you recommend dropping them?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Bob P · Posted: Tue Apr 12, 2005 2:10 pm Post subject:

the reason that you've been as successful with -O3 as i have is because many of the critical ebuilds filter the flag out, and replace it with -O2.

one reason for naming clfags redundantly is to circumvent their removal by the ebuild maintainers who like to strip -O3 and replace it with -O2. if you specify -O3 AND you manually and redundantly specifcy the cflags that are added when you go from the -O2 to the -O3 specification, then you preserve some of the -O3 optimizations when the ebuild strips -O3 off and replaces it with -O2. i've grepped the portage tree to list the ebuilds that perform this replacement, and none of them filter these individual flags. until the ebuild guys figure this out, we've got a good thing going for us.

building your toolkit with -O3 is really a waste of time. glibc and gcc filter -O3. if you have any doubts, watch the screen when glibc compiles, and you'll see that all of the flags displayed onscreen are -O2. so you might as well just use -O2 and manually enter the flags that are included in the upgrade from 2 to 3.

one problem with ~x86 is that there are some ebuilds that get linked by the toolkit that you may not expect to play a critical role. personally, i do not trust toolkit components that are in the testing branch very much, so i keep a close eye on them, and i force the stable branch for everything else. i am very aggressive in my gentoo builds, and i won't use the ~x86 flag. it just causes too many problems. to avoid these kinds of problems, and to maximize stability, jackass! uses x86 exclusively, save for a few critical toolkit packages.

in working on Jackass!, one of our guys has sworn that -ffast-math is still a troublemaker, so we avoid it. we've rebuilt the toolkit at least 10-20 times for 4 architectures in the past week without one single failure, so its hard to argue with success. IMHO, you're already at the point of diminishing returns, and fast math offers lots of risk for little reward.

NPTLONLY is BAD, regardless of what the wiki says.

LDFLAGS are another one of those diminishing returns optimizations. plenty of risk, little reward.

hth.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

wrc1944 · Posted: Tue Apr 12, 2005 4:08 pm Post subject:

Thanks for the info. You make some good points, and I'll rethink LDFLAGS and NPTLONLY. My objective was to go pure NPTL, and get away from the old linuxthreads, but perhaps that isn't the wisest course? My thinking came from reading several items like this:

steve_d555 · Posted: Tue Apr 12, 2005 6:47 pm Post subject:

I have had nptlonly out of my useflags from when I switched over and everything has been fine. Its worth compiling twice if you dont have problems. Also it doesnt really look like the error has anything to do with your CFlags, though if you do have problems down the road compiling, try taking out the more extreme ones.
_________________
rubyforums | blog | boxwhore

wrc1944 · Posted: Tue Apr 12, 2005 10:02 pm Post subject:

In my recent extensive reading on the NPTL subject, I've run across many hundreds of statements like these: