[gentoo-amd64] coreutils-6.4 - cannot compile
Hello: Did anyone get a segmentation fault when installing coreutils-6.4? See build error below Regards, Mauro config.status: creating po/POTFILES config.status: creating po/Makefile /usr/portage/sys-apps/coreutils/coreutils-6.4.ebuild: line 79: 12677 Segmentation fault emake !!! ERROR: sys-apps/coreutils-6.4 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile coreutils-6.4.ebuild, line 101: Called die -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] coreutils-6.4 - cannot install
-- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Gnupg doesn't build
On Mon, 06 Nov 2006 12:06:56 -0500, Mark Haney wrote: > >> octavian ~ # emerge -u gnupg > >> Calculating dependencies... done! > >> >>> Auto-cleaning packages... > >> > >> >>> No outdated packages were found on your system. > >> > >> > >> * GNU info directory index is up-to-date. > >> > >> And it never gets upgraded. Has anyone else seen this? > >> > > > > Yeah, I get this on every package that's already up-to-date ;) > > > > > Yeah well that's not what portage says. (And I probably should have > explained a bit deeper. It was a LONG weekend.) > > [ebuild U ] [1.4.5] USE="-X* -bindist% > -usb*" > > That's what I have showing up in portage. gnupg is slotted, and the highest version slot is up to date. try emerge --oneshot =app-crypt/gnupg-1.4.5-r2 -- Neil Bothwick "There's more to life than sex, beer and computers. Not a lot more admittedly..." signature.asc Description: PGP signature
Re: [gentoo-amd64] Gnupg doesn't build
Christoph Mende wrote: On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote: I've tried everything over the last couple of days to upgrade gnupg and I get the same thing: octavian ~ # emerge -u gnupg Calculating dependencies... done! >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. And it never gets upgraded. Has anyone else seen this? Yeah, I get this on every package that's already up-to-date ;) Yeah well that's not what portage says. (And I probably should have explained a bit deeper. It was a LONG weekend.) [ebuild U ] app-crypt/gnupg-1.4.5-r2 [1.4.5] USE="-X* -bindist% -usb*" That's what I have showing up in portage. -- Ceterum censeo, Carthago delenda est. Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415 -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Gnupg doesn't build
On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote: > I've tried everything over the last couple of days to upgrade gnupg and > I get the same thing: > > octavian ~ # emerge -u gnupg > Calculating dependencies... done! > >>> Auto-cleaning packages... > > >>> No outdated packages were found on your system. > > > * GNU info directory index is up-to-date. > > And it never gets upgraded. Has anyone else seen this? > That indicates that portage thinks you have the newest version already. Which version do you have? Which do you want? Is the newer version masked by either package.mask (/usr/portage/profiles/package.mask or /etc/portage/package.mask)? Is the newer version keyworded higher than you accept? Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-amd64] Gnupg doesn't build
On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote: > I've tried everything over the last couple of days to upgrade gnupg and > I get the same thing: > > octavian ~ # emerge -u gnupg > Calculating dependencies... done! > >>> Auto-cleaning packages... > > >>> No outdated packages were found on your system. > > > * GNU info directory index is up-to-date. > > And it never gets upgraded. Has anyone else seen this? Yeah, I get this on every package that's already up-to-date ;) -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Gnupg doesn't build
I've tried everything over the last couple of days to upgrade gnupg and I get the same thing: octavian ~ # emerge -u gnupg Calculating dependencies... done! >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. And it never gets upgraded. Has anyone else seen this? -- Ceterum censeo, Carthago delenda est. Mark Haney Sr. Systems Administrator ERC Broadband (828) 350-2415 -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Unexpected side effect of GCC 4
Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 06 Nov 2006 08:48:16 +: > It's gentoolkit-0.2.3_pre2. I know it's deprecated, but that was done far > too early, as at the time equery couldn't do half the things qpkg did. > Definitely a case of too much haste. OK, that's what I'm using. I agree they cut it off a bit early, but between equery and esearch, I think there's full functionality now. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Unexpected side effect of GCC 4
"Hemmann, Volker Armin" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 06 Nov 2006 09:29:51 +0100: > where is the logic with that? > > You don't need to do regularly --emptytree emerges. If you don't change > gcc you never need it. So why? That's the thing. I haven't done a full emerge --emptytree since at least gcc-4.1.0, which was never unmasked (it's 4.1.1 that's unmasked). I did one sometime after 4.0, I think during the 4.1.0 release candidates, but not since. As for doing it every gcc upgrade, that's a bit ridiculous when you are running the weekly gcc snapshots as I was between 4.0 and 4.1. So, everything on my system has been compiled with (I think) at least a 4.1 release candidate or newer, but I haven't done a full --emptytree since 4.1.1 was released and unmasked, I know. Thus, particularly since I'm having that mysterious problem, it's time to do one, and see if the problem disappears. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Unexpected side effect of GCC 4
Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 06 Nov 2006 11:44:01 +: > On Monday 06 November 2006 08:41, Duncan wrote: > >> Peter Humphrey <[EMAIL PROTECTED]> posted >> > Perhaps I ought to look into putting /tmp and /var/tmp onto tmpfs. >> >> Do so. It makes a /big/ difference! > > My reading so far suggests that I include these two lines in /etc/fstab: > > tmpfs /tmp tmpfs nodev,nosuid,noexec 0 0 > tmpfs /var/tmp tmpfs nodev,nosuid,noexec 0 0 > > Is that all I have to do? I assume I don't need to specify tmpfs sizes; I > have 4 GB RAM of which 0.5 GB is unavailable (owing to a motherboard > problem that prompted the system builder to refund some of my money - > small consolation). I believe I remember your posts talking about that, back when I still had only a gig of RAM. Now that I have more than 3.5 gig of memory myself, I know a bit more about the memory hole and all that. If you have bios entries for configuring it and just couldn't get it to work before, maybe now that I know a bit more about the issue, we could try to work thru it. Of course, if you don't have the BIOS entries, it's just not going to happen... You don't /need/ to specify tmpfs size, but it might be worthwhile to do so. You don't want a runaway file in /tmp to take up all your memory and swap. Be aware that if you mount as tmpfs any location normally having global write permissions (the usual 1777 of /tmp for instance), you are letting any account have access to that memory. If you are the only human user of the machine, that's probably fine, but if not, you may want to ensure you are running quotas on it or something, and have them set appropriately. If you are just concerned about portage, you can of course point $PORTAGE_TMPDIR at a location other than the default, and set that location user portage group portage, 740 permissions or similar, so only portage (and root of course) can write to it. It's still possible that anyone in group portage could abuse it, but not simple users not in group portage. then. Here, as I'm the only human user, I don't have to be quite so strict on security. To keep things simple, /var/tmp is a symlink to /tmp, so I don't have to worry about a tmpfs for both dirs. You'll want to set the following in make.conf: PKG_TMPDIR PORTAGE_TMPDIR PORTAGE_TMPFS Note that setting the latter to a small, say 50 meg, tmpfs, is useful even if you aren't setting PORTAGE_TMPDIR on tmpfs. It's used for quick/small stuff like lockfiles and the like. The portage docs suggest setting it to /dev/shm, an LSB standard location for such things. I have a separate (max 50 meg as I said) tmpfs mounted at /dev/shm and followed the recommendation to point PORTAGE_TMPFS at it. Of course, you'll only need PKG_TMPDIR if you have FEATURES=buildpkg set or otherwise deal with binary packages. I have /tmp (which is where both the package and portage TMPDIRs point) set size=5g here, with 8 gig memory. With 3.5 gig of memory, you may wish to set something a bit smaller, say 3 gig. That should be fine for most emerges and will keep it from going too much into swap if something should start hogging your tmpfs. Of course, you'll have to make it a bit bigger for merging say OOo (not the bin-version), as it is said to require 5 gigs of space (I don't use it so wouldn't personally know), but you could use remount for special cases like that, keeping it to 3 gig or so normally. > Probably I should put a script into /etc/conf.d/start.local to create a > symlink from /var/tmp/ccache back to a real cache directory on disk, as > it seems daft to install a compiler cache and then flush it at every > reboot - at present mine has 1.5 GB of data. /tmp has 750 MB of stuff > and is a separate disk partition at present, mounted on whichever system > I boot. Don't worry about that symlink. Set CCACHE_DIR in make.conf directly, instead. Here, I have it pointed at a subdir on my fast raid-0/striped array. That works quite well. Since all the stuff portage normally uses (gcc, grep, sed, libraries commonly linked, etc) read into the regular kernel filesystem cache memory during the first emerge, and with all the work being done on tmpfs, there's little i/o but the ccache write updates going on during all but the qmerge phase of subsequent emerges. The disk spends most of its time idle, and you can watch the disk activity light and tell when the kernel's cache flush writes kick in, as it blinks red a couple times every few seconds. That's it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 08:48, Peter Humphrey wrote: > On Monday 06 November 2006 07:50, Duncan wrote: > > What version of gentoolkit do you have? qpkg is deprecated and has > > been since at at least gentoolkit 0.2.2-rc1, merged here back on May > > 27, according to my logs. > > It's gentoolkit-0.2.3_pre2. I know it's deprecated, but that was done far qpkg, that is. > too early, as at the time equery couldn't do half the things qpkg did. > Definitely a case of too much haste. > > > Even if you are using an older version, consider switching to equery > > instead, as qpkg hasn't been under development for some time and may > > therefore have strange bugs. > > I do use equery more now, and sooner or later will probably drop qpkg > quietly. I'm certainly not complaining of bugs in it. > > > I'd say this is probably one example, tho it's still working sort of > > correctly for you. > > Quite so. > > -- > Rgds > Peter -- Rgds Peter Humphrey -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 12:59, Hemmann, Volker Armin wrote: > On Monday 06 November 2006 13:49, Jack Lloyd wrote: > > On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: > > > lets ask the other way round. Why should it speed up anything to have > > > X>number of cores? > > > > To account for I/O wait states > > and how often does something wait for io and how often does some data is > purged from the cache, because the other make instance is activated? The best way to find out is to test in your own circumstances. > When I switched from j2 to j1, compiling did not take any longer - but > the box way much more usable. Whereas when I changed from j3 to j5 on my 2 CPUs, compiling seemed to take less time and I didn't notice any effect on responsiveness. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Mon, Nov 06, 2006 at 01:59:33PM +0100, Hemmann, Volker Armin wrote: > On Monday 06 November 2006 13:49, Jack Lloyd wrote: > > On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: > > > lets ask the other way round. Why should it speed up anything to have > > > X>number of cores? Instead of a single thread per core, compiling > > > happily, you have two or more competing for one core and regularly kick > > > out each others data from the cache. > > > > To account for I/O wait states > > and how often does something wait for io and how often does some data is > purged from the cache, because the other make instance is activated? > > When I switched from j2 to j1, compiling did not take any longer - but the > box > way much more usable. OK. On my dual core machine, -j3 seems to be the sweet spot. Simply because something does not work for you does not mean it is going to be universally a bad idea. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 13:49, Jack Lloyd wrote: > On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: > > lets ask the other way round. Why should it speed up anything to have > > X>number of cores? Instead of a single thread per core, compiling > > happily, you have two or more competing for one core and regularly kick > > out each others data from the cache. > > To account for I/O wait states and how often does something wait for io and how often does some data is purged from the cache, because the other make instance is activated? When I switched from j2 to j1, compiling did not take any longer - but the box way much more usable. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: > lets ask the other way round. Why should it speed up anything to have > X>number > of cores? Instead of a single thread per core, compiling happily, you have > two or more competing for one core and regularly kick out each others data > from the cache. To account for I/O wait states -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 12:48, Peter Humphrey wrote: > On Monday 06 November 2006 10:47, Hemmann, Volker Armin wrote: > > Set Portage_NICENESS to 19, MAKEOPTS ot -jX with X maximum number of > > cores and activate ccache with at least 4GB and you don't need tempfs to > > install KDE (all of it), in less than 10h. > > Are you implying that setting X > number of cores will slow it down? I > have -j5 with two single CPUs, and KDE (part of it) takes far longer than > that. lets ask the other way round. Why should it speed up anything to have X>number of cores? Instead of a single thread per core, compiling happily, you have two or more competing for one core and regularly kick out each others data from the cache. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 10:47, Hemmann, Volker Armin wrote: > Set Portage_NICENESS to 19, MAKEOPTS ot -jX with X maximum number of > cores and activate ccache with at least 4GB and you don't need tempfs to > install KDE (all of it), in less than 10h. Are you implying that setting X > number of cores will slow it down? I have -j5 with two single CPUs, and KDE (part of it) takes far longer than that. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 08:41, Duncan wrote: > Peter Humphrey <[EMAIL PROTECTED]> posted > > Perhaps I ought to look into putting /tmp and /var/tmp onto tmpfs. > > Do so. It makes a /big/ difference! My reading so far suggests that I include these two lines in /etc/fstab: tmpfs /tmptmpfs nodev,nosuid,noexec 0 0 tmpfs /var/tmptmpfs nodev,nosuid,noexec 0 0 Is that all I have to do? I assume I don't need to specify tmpfs sizes; I have 4 GB RAM of which 0.5 GB is unavailable (owing to a motherboard problem that prompted the system builder to refund some of my money - small consolation). Probably I should put a script into /etc/conf.d/start.local to create a symlink from /var/tmp/ccache back to a real cache directory on disk, as it seems daft to install a compiler cache and then flush it at every reboot - at present mine has 1.5 GB of data. /tmp has 750 MB of stuff and is a separate disk partition at present, mounted on whichever system I boot. > I don't have all of KDE merged here Nor I; I just have 9 meta-packages because I didn't want the education or games stuff, among others. I might have preferred to go to finer grain still, but it looked like too much work. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
Set Portage_NICENESS to 19, MAKEOPTS ot -jX with X maximum number of cores and activate ccache with at least 4GB and you don't need tempfs to install KDE (all of it), in less than 10h. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 07:50, Duncan wrote: > What version of gentoolkit do you have? qpkg is deprecated and has been > since at at least gentoolkit 0.2.2-rc1, merged here back on May 27, > according to my logs. It's gentoolkit-0.2.3_pre2. I know it's deprecated, but that was done far too early, as at the time equery couldn't do half the things qpkg did. Definitely a case of too much haste. > Even if you are using an older version, consider switching to equery > instead, as qpkg hasn't been under development for some time and may > therefore have strange bugs. I do use equery more now, and sooner or later will probably drop qpkg quietly. I'm certainly not complaining of bugs in it. > I'd say this is probably one example, tho it's still working sort of > correctly for you. Quite so. -- Rgds Peter -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Unexpected side effect of GCC 4
Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 05 Nov 2006 11:50:06 +: > (I'd forgotten how many days would be needed for that, even on this > dual-Opteron-246 box with 4 GB. KDE takes an age. Perhaps I ought to look > into putting /tmp and /var/tmp onto tmpfs.) Do so. It makes a /big/ difference! I don't have all of KDE merged here, but trying to track down the issue I was having, but between trying to track down the issue I was having (which I won't repeat here), and the ~arch upgrade to kde 3.5.5, and the several -rX releases of various kde packages subsequent to 3.5.5, I've done a lot of kde remerging lately. As best I can tell and from memory of how long it took to emerge kde before I upgraded memory and put $PORTAGE_TMPDIR on tmpfs, it used to take me about 14-16 hours to merge what parts of KDE I have back with a single disk and a gig of memory, shortened to about 10-12 after I upgraded to a 4-disk RAID ($PORTDIR and $PORTAGE_TMPDIR on 4-way striped RAID-0, main system on RAID-6, so two-data stripes, two parity stripes), to only a bit over 8 hours, say 9, with $PORTAGE_TMPDIR on tmpfs after upgrading to 8 gig memory. If you aren't running RAID, you'll get the entire benefit of going from $PORTAGE_TMPDIR on the same drive as you are installing to and running from to having it on tmpfs, in one shot. Note that the RAID-6 main system is going to be a bit faster than a single drive, but that I only have dual Opteron 242s, not the 246s you said you have. I'm guessing you'll see a 2-hour minimum drop in compile times, if not 4-6, on KDE alone, by putting $PORTAGE_TMPDIR on tmpfs. For an entire emerge --emptytree world, you are looking probably a half-day of savings at least. I am /so/ looking forward to that upgrade to dual Opteron 285s! Even discounting the upgrade from dual to quad-cores, the clock-speed increase alone will rock! I'm guessing perhaps 6 hours (maybe as little as 4) for my KDE upgrades, and say a day (more or less) for a full system rebuild! That'll be SWEET INDEED! =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4
On Monday 06 November 2006 09:17, Duncan wrote: > > I mentioned that I need to do an emerge -emptytree again, as it has been > awhile. where is the logic with that? You don't need to do regularly --emptytree emerges. If you don't change gcc you never need it. So why? -- gentoo-amd64@gentoo.org mailing list
[gentoo-amd64] Re: Unexpected side effect of GCC 4
Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 05 Nov 2006 12:10:24 +: [rewrapped] > $ emerge --info | grep FLAGS > CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks > -freorder-blocks-and-partition -funit-at-a-time -fgcse-sm -fgcse-las > -fgcse-after-reload -fmerge-all-constants" > CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks > -funit-at-a-time -fgcse-sm -fgcse-las -fgcse-after-reload > -fmerge-all-constants" > Unset: CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS > So I have a pointer away from glibc and linux-headers. CFLAGS on the new > system are as on the old but with -combine added.The old and new systems > have the same versions of kernel, linux-headers and glibc, but different > versions of gcc. Rsync is crippled on the old system but fine on the new > one. Well, I /did/ say gcc 4.1.1 seemed way (as in, vastly) better than 3.4.x, for me, so at least that's being borne out. As for CFLAGS, the only change I've made recently is adding -ftree-vectorize, experimentally, given the discussion here. I'm not sure it's the problem, particularly as where I /am/ experiencing issues the first thing I tried was compiling stuff without it, so if it's the problem, it's in some obscure dependency somewhere, but I certainly had no issues before trying it and now I do, so for anyone else thinking of trying it, I'd recommend staying well away from -ftree-vectorize for the time being. I'd really like to be able to say for sure it is the problem, and find it very frustrating not to be able to nail it down, but suffice it to say /something's/ causing me problems right now and that's one of my recent changes, so I'd recommend staying well away from it. I mentioned that I need to do an emerge -emptytree again, as it has been awhile. I'm still debating whether to try it with or without -ftree-vectorize. If that's the problem, it may well go away if everything is compiled with it. OTOH, it may not. That's an awful lot of compiling to do and still have a problem if -ftree-vectorize is causing it and it doesn't go away with everything compiled with it, but OTOH, if that's /not/ the problem, and I decide not to try it, I'll never know whether that was the problem or not. I'm about to decide to simply play it safe and pretend nobody here ever called -ftree-vectorize to my attention, at least until the flag has had a bit more time to mature (say gcc 4.2 or 4.3). Only just because I'm the type of person I am, that would bother me as I will have never nailed it for sure. In any case, my best guess right now are that the issues I am having are related to a nasty interplay between -ftree-vectorize and glibc-2.5. In looking around at Gentoo glibc bugs, I found at least one equally strange one, on x86. The bug required glibc 2.5, and it required that a certain package be compiled with a certain cflag. With that cflag on glibc 2.4, it worked fine, as it did without the cflag on 2.5, but put them together and things blew up. It wasn't -ftree-vectorize, and it was on x86, but I've a rather strong suspicion my case is similar, only on amd64 and with a different cflag, -ftree-vectorize most likely. I've just not figured out which particular package is doing it, and not being able to figure it out as I said is VERY annoying to me, WAY more so than the bit of inconvenience the actual bug is causing. (Yes, I know I said all that already, but it's still annoying and I'm still griping about it! =8^( -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list
