Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sat, 2005-07-23 at 11:51 -0700, Zac Medico wrote: Jules Colding wrote: Hi, emerge --sync emerge -vauDN today gave me the following error. [snip] adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Yes, that is my thought too. Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. I think that I am the only one that can show the problem so you might very well be correct. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. I'll be doing that. Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sat, 2005-07-23 at 23:26 +0200, Richard Fish wrote: Hmm, since others with similar systems cannot duplicate the problem, I decided to capture all of the build output on my system (P4) and compare. Jules, there is definitely something not right on your system, but I don't know what yet. You get the following: +++ overriding content/cookie/contents.rdf adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. The /var/tmp/portage/homedir is wrong. Sharp eyes. I didn't notice that one. On my system, I get: +++ overriding content/cookie/contents.rdf adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/classic.jar Using the wrong version of autoconf/automake is the only thing I can think of that would cause this kind of thing. What do you get if you do: # which autoconf omc-2 ~ # which autoconf /usr/bin/autoconf # autoconf --version omc-2 ~ # autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. I am trying to reemerge autoconf and automake as zac advised. BTW, the homedir above is now empty, but is does still exists. It has other permissions that the other directories. Like: ### snip ## drwxr-xr-x 3 portage portage 72 Jul 21 03:05 grep-2.5.1-r6 drwxr-xr-x 3 portage portage 72 Jul 21 02:10 gzip-1.3.5-r5 drwxrws--- 4 portage portage 120 Jul 22 20:58 homedir drwxr-xr-x 3 portage portage 72 Jul 19 21:41 linux-headers-2.6.8.1-r4 ### snip ## Don't know if that is significant, but is sure does look suspicious... Best regards, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 14:22 +0200, Jules Colding wrote: On Sat, 2005-07-23 at 11:51 -0700, Zac Medico wrote: Jules Colding wrote: Hi, emerge --sync emerge -vauDN today gave me the following error. [snip] adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Yes, that is my thought too. Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. I think that I am the only one that can show the problem so you might very well be correct. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. I'll be doing that. OK, I get a segfault doing that: ## snip ### test -z /usr/share/automake-1.9/Automake || mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/Automake /bin/install -c -m 644 'Config.pm' '/var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/Automake/Config.pm' make[4]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' make[3]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' make[2]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' Making install in am make[2]: Entering directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[3]: Entering directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[3]: Nothing to be done for `install-exec-am'. test -z /usr/share/automake-1.9/am || mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/am /bin/sh: line 1: 16093 Segmentation fault mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/am make[3]: *** [install-dist_amDATA] Error 139 make[3]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib' make: *** [install-recursive] Error 1 !!! ERROR: sys-devel/automake-1.9.5 failed. !!! Function src_install, Line 36, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ## snip ### Wouldn't it be a good idea on this point to reemerge coreutils or maybe the whole of system? Is the correct way doing: emerge -e system emerge -e system emerge -e world emerge -e world ? or is a single emerge -e system sufficient? Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 01:02 +0200, Patrick Börjesson wrote: Although... I would suggest that the OP give a more explicit question, since I was really not sure if it was a anyone seen this before?, I'm a n00b, please solve this for me! or a where should I take this to get it solved? question. Being the OP it was a question in the line of Here might be a potential problem in the build but I don't know if it is the source, my system, the ebuild or if I'm an idiot. Has anyone seen this too? Sorry if I was to vague. I'll be more specific the next time :-) Best regards, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sat, 2005-07-23 at 11:51 -0700, Zac Medico wrote: This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. Hmm... Among my USE flags is nptlonly. Might that be a problem? -- jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. I'll be doing that. OK, I get a segfault doing that: ## snip ### test -z /usr/share/automake-1.9/Automake || mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/Automake /bin/install -c -m 644 'Config.pm' '/var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/Automake/Config.pm' make[4]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' make[3]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' make[2]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/Automake' Making install in am make[2]: Entering directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[3]: Entering directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[3]: Nothing to be done for `install-exec-am'. test -z /usr/share/automake-1.9/am || mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/am /bin/sh: line 1: 16093 Segmentation fault mkdir -p -- /var/tmp/portage/automake-1.9.5/image//usr/share/automake-1.9/am make[3]: *** [install-dist_amDATA] Error 139 make[3]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib/am' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/automake-1.9.5/work/automake-1.9.5/lib' make: *** [install-recursive] Error 1 !!! ERROR: sys-devel/automake-1.9.5 failed. !!! Function src_install, Line 36, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ## snip ### Wouldn't it be a good idea on this point to reemerge coreutils or maybe the whole of system? Is the correct way doing: emerge -e system emerge -e system emerge -e world emerge -e world Well, since world includes system, if you want to rebuild *everything*, I would think the following should be sufficient emerge --oneshot gcc binutils (check gcc-config and binutils-config to ensure sanity) emerge -e world The above should ensure that everything gets rebuilt with the rebuilt version of gcc and binutils. To save some time, you could try just system instead of world. That *should* still give you a sane build environment, but if you get many more segfaults, I am going to start thinking that you have some hardware problems... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 14:48 +0200, Richard Fish wrote: Well, since world includes system, if you want to rebuild *everything*, I would think the following should be sufficient emerge --oneshot gcc binutils OK. What about glibc or is that just a part of world? -- jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: On Sat, 2005-07-23 at 11:51 -0700, Zac Medico wrote: This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. Hmm... Among my USE flags is nptlonly. Might that be a problem? Well, nptlonly seems to work for a lot of people, so I don't think that should be a problem. I've only ever heard of it affecting old binary-only software. The only change I would be tempted to make to your USE flags would be to add multilib, which would give you the ability to build/run both 32 and 64-bit applications. I don't see how this could fix your current problems...but I did notice that Bob Sanders (one of the two WFM reports on this thread) has this in his USE flags. Of course he also doesn't have nptlonly, or userlocales, so who knows... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: On Sun, 2005-07-24 at 14:48 +0200, Richard Fish wrote: Well, since world includes system, if you want to rebuild *everything*, I would think the following should be sufficient emerge --oneshot gcc binutils OK. What about glibc or is that just a part of world? It is part of world. On my system it would be the 152nd package to be rebuilt. Technically, both gcc and binutils are also part of world, and will be built twice with the above instructions, but since they generate just about everything else, you want to make sure those are sane before starting. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 15:20 +0200, Richard Fish wrote: Jules Colding wrote: Hmm... Among my USE flags is nptlonly. Might that be a problem? Well, nptlonly seems to work for a lot of people, so I don't think that should be a problem. I've only ever heard of it affecting old binary-only software. I am seeing random crashes of Evolution. The backtrace originates, as far I know, always in libpthread, so maybe this nptlonly is a bad idea after all? The only change I would be tempted to make to your USE flags would be to add multilib, which would give you the ability to build/run both 32 and 64-bit applications. I don't see how this could fix your current problems...but I did notice that Bob Sanders (one of the two WFM reports on this thread) has this in his USE flags. Of course he also doesn't have nptlonly, or userlocales, so who knows... Hmm... I am seeing (-multilib) when doing the emerge of gcc and binutils, so multilib is disabled by my profile and shouldn't be enabled manually, right? Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: On Sun, 2005-07-24 at 14:22 +0200, Jules Colding wrote: On Sat, 2005-07-23 at 11:51 -0700, Zac Medico wrote: Jules Colding wrote: Hi, emerge --sync emerge -vauDN today gave me the following error. [snip] adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored ...SKIP... !!! ERROR: sys-devel/automake-1.9.5 failed. !!! Function src_install, Line 36, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ## snip ### Wouldn't it be a good idea on this point to reemerge coreutils or maybe the whole of system? Is the correct way doing: emerge -e system emerge -e system emerge -e world emerge -e world ? or is a single emerge -e system sufficient? Thanks, jules Hi, Don't have any new idea, but could you check if there are some hardened USE-flags in your /etc/make.conf (like 'pic', 'pie', 'hardened' etc). Using some of them on a normal system may cause problems. HTH. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 16:28 +0300, Rumen Yotov wrote: Hi, Don't have any new idea, but could you check if there are some hardened USE-flags in your /etc/make.conf (like 'pic', 'pie', 'hardened' etc). Using some of them on a normal system may cause problems. HTH. Rumen Nope, none. Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: Hmm... I am seeing (-multilib) when doing the emerge of gcc and binutils, so multilib is disabled by my profile and shouldn't be enabled manually, right? Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Richard Fish wrote: Jules Colding wrote: Hmm... I am seeing (-multilib) when doing the emerge of gcc and binutils, so multilib is disabled by my profile and shouldn't be enabled manually, right? Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 Um, nevermind. Going back to your original post: Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) But maybe you can try to follow their by hand instructions for to make sure that everything is sane for your profile. I mean, multilib should be enabled by default, unless you are actually linked to the /no-multilib profile... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 15:51 +0200, Richard Fish wrote: Jules Colding wrote: Hmm... I am seeing (-multilib) when doing the emerge of gcc and binutils, so multilib is disabled by my profile and shouldn't be enabled manually, right? Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. It does: [EMAIL PROTECTED] ~ $ ls -l /etc/make.profile lrwxrwxrwx 1 root root 50 Jul 19 20:22 /etc/make.profile - ../usr/portage/profiles/default-linux/amd64/2005.0 But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 Hmm... I am running 2005.0 (from stage1) and the only content of 2005.0/scripts is 2004.3-2005.0upgrade.sh so I guess that I shouldn't need to upgrade anything? -- jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: On Sun, 2005-07-24 at 15:20 +0200, Richard Fish wrote: Jules Colding wrote: Hmm... Among my USE flags is nptlonly. Might that be a problem? Well, nptlonly seems to work for a lot of people, so I don't think that should be a problem. I've only ever heard of it affecting old binary-only software. I am seeing random crashes of Evolution. The backtrace originates, as far I know, always in libpthread, so maybe this nptlonly is a bad idea after all? IMO that would be reading too much out of the a single segfault. You certainly have some instability but it is most likely rooted elsewhere. Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 15:58 +0200, Richard Fish wrote: Richard Fish wrote: Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 Um, nevermind. Going back to your original post: Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) But maybe you can try to follow their by hand instructions for to make sure that everything is sane for your profile. I mean, multilib should be enabled by default, unless you are actually linked to the /no-multilib profile... I am not, but emerge insists on (-multilib). I don't think the manual method will work either: ### snip # omc-2 ~ # USE=multilib emerge -va gcc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-devel/gcc-3.4.3-r1 (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No] no Quitting. ### snip # The existence of lib32 indicates multilib capabilities, right? I do got both /usr/lib64 and /usr/lib32. I think that I will let memtest86+ run overnight and see if it finds something. Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: On Sun, 2005-07-24 at 15:58 +0200, Richard Fish wrote: Richard Fish wrote: Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 Um, nevermind. Going back to your original post: Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) But maybe you can try to follow their by hand instructions for to make sure that everything is sane for your profile. I mean, multilib should be enabled by default, unless you are actually linked to the /no-multilib profile... I am not, but emerge insists on (-multilib). I don't think the manual method will work either: ### snip # omc-2 ~ # USE=multilib emerge -va gcc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-devel/gcc-3.4.3-r1 (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No] no Quitting. ### snip # The existence of lib32 indicates multilib capabilities, right? I do got both /usr/lib64 and /usr/lib32. I think that I will let memtest86+ run overnight and see if it finds something. Thanks, jules Hi, No experience with 64-bits, but a USE-flag in () means not supported by the profile. Have you changed profiles? HTH. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sun, 2005-07-24 at 17:43 +0300, Rumen Yotov wrote: No experience with 64-bits, but a USE-flag in () means not supported by the profile. Have you changed profiles? No. Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2 (AMD64 users please help)
Jules Colding wrote: On Sun, 2005-07-24 at 15:58 +0200, Richard Fish wrote: Richard Fish wrote: Could you double check the symlink /etc/make.profile. AFAIK, you want it to point to /usr/portage/profiles/default-linux/amd64/2005.0. But read this first before changing anything: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=1 Um, nevermind. Going back to your original post: Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) But maybe you can try to follow their by hand instructions for to make sure that everything is sane for your profile. I mean, multilib should be enabled by default, unless you are actually linked to the /no-multilib profile... I am not, but emerge insists on (-multilib). I don't think the manual method will work either: ### snip # omc-2 ~ # USE=multilib emerge -va gcc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-devel/gcc-3.4.3-r1 (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No] no Quitting. ### snip # The existence of lib32 indicates multilib capabilities, right? I do got both /usr/lib64 and /usr/lib32. How about /emul/linux/x86/lib? Argh, I don't get it. /u/p/p/default-linux/amd64/2005.0/use.mask contains multilib, but with a comment stating it is forced on when MULTILIB_ABIS is defined, and make.defaults has MULTILIB_ABIS=x86 amd64. Can any AMD64 users shed some light on this please? -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: Hmm... Among my USE flags is nptlonly. Might that be a problem? I don't think so as I have that too. Be lucky, Neil -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2 (AMD64 users please help)
On Sun, 24 Jul 2005 17:06:49 +0200 Richard Fish [EMAIL PROTECTED] wrote: Argh, I don't get it. /u/p/p/default-linux/amd64/2005.0/use.mask contains multilib, but with a comment stating it is forced on when MULTILIB_ABIS is defined, and make.defaults has MULTILIB_ABIS=x86 amd64. Can any AMD64 users shed some light on this please? multilib can be, or it used to be able to, turned off so that only 64-bit versions of the libs get built. Normally, it should be turned on and set in the USE string, for most folks on a x86_64 platform. But, on a system without multilib, turning it on means that, as a minimum an - emerge -uDav --newuse system will need to be performed to rebuild gcc, glibc and all the base system libs so that the following get created - /lib64 /lib32 /usr/lib32 /usr/lib64 and a few other items. Bob - -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2 (AMD64 users please help)
On Sun, 2005-07-24 at 11:10 -0700, Bob Sanders wrote: On Sun, 24 Jul 2005 17:06:49 +0200 Richard Fish [EMAIL PROTECTED] wrote: Argh, I don't get it. /u/p/p/default-linux/amd64/2005.0/use.mask contains multilib, but with a comment stating it is forced on when MULTILIB_ABIS is defined, and make.defaults has MULTILIB_ABIS=x86 amd64. Can any AMD64 users shed some light on this please? multilib can be, or it used to be able to, turned off so that only 64-bit versions of the libs get built. Normally, it should be turned on and set in the USE string, for most folks on a x86_64 platform. But, on a system without multilib, turning it on means that, as a minimum an - emerge -uDav --newuse system will need to be performed to rebuild gcc, glibc and all the base system libs so that the following get created - /lib64 /lib32 /usr/lib32 /usr/lib64 All of those are present on my system, but I am still seeing (-multilib) when I do e.g. emerge -va glibc. -- jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Patrick Börjesson schreef: On 05/07/23 18:37, Richard Fish wrote: And it seems to me that if there is a bug, it might be a *documentation* bug (because the other person who mentioned using march=k8 said that that was the recommendation of the docs, but that seems to no longer be the case, if people using this flag are regularly receiving compilation errors). Documentation bug? Not recommended by the docs any more? You might want to actually try to find information about the subjects you respond to. Straight out of the AMD64 Gentoo Handbook: AMD64 users who want to use a native 64 bit system should use -march=k8 Combining that cite with the information from the gcc info page, I'm pretty sure it's not a documentation bug. Hold on...the -march thing would be an easy mistake to make for those of us who don't run AMD processors, and are just trying to help. Afterall, the platform keyword is amd64. And gcc info says that k8, opteron, athlon64, and athlon-fx are all equivalent, although I would suggest that the non-k8 options are more descriptive. Of course, but in this case it wasn't an oversight... The poster explicitly said that using march=k8 seemed to no longer be the recommendation of the docs. That implies at least _some_ looking into the subject before posting... If the poster being referred to is me, that wasn't what I meant to say, or rather what I meant to be *understood*-- what I meant was that apparently the Handbook recommends using the k8 flag, but people using that flag seem (and I stress seem, as I don't follow this issue that closely, naturally) to be running into problems, whereas those using the amd64 flag are not (or at least not the same problems). Now, I don't know the truth of the matter, but that would lead me to suspect that there could be *outdated information in the Gentoo documentation* (thus, a documentation bug), which, if those affected can verify, should perhaps be submitted. Sorry for the confusion. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On 05/07/23 13:38, Jules Colding wrote: emerge --sync emerge -vauDN today gave me the following error. [snip] I'd think that the developers would rather have that information posted to http://bugs.gentoo.org/ instead... -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D pgpsoTSNZPCHa.pgp Description: PGP signature
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding schreef: Hi, emerge --sync emerge -vauDN today gave me the following error. adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions' gmake[1]: *** [tier_94] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla' make: *** [default] Error 2 !!! ERROR: www-client/mozilla-firefox-1.0.6-r2 failed. !!! Function src_compile, Line 159, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ## emerge --info # omc-2 ~ # emerge --info Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) = System uname: 2.6.12-gentoo-r6 x86_64 AMD Opteron(tm) Processor 252 Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox:1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS=amd64 AUTOCLEAN=yes CBUILD=x86_64-pc-linux-gnu CFLAGS=-march=k8 -O2 -pipe CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control CONFIG_PROTECT_MASK=/etc/gconf /etc/terminfo /etc/env.d CXXFLAGS=-march=k8 -O2 -pipe Well, since I just (literally, 10 minutes ago) emerged mozilla-firefox-1.0.6-r2, and had no problems on a 32-bit system, I must suspect that this is a 64-bit issue. In that regard, I see at least one thing in your emerge info that has been called into question for 64-bit users in recent threads: CFLAGS=-march=k8 I am, of course, not a 64-bit user, so I don't know anything about this, but I have seen several responses to similar questions that suggest that the correct flag is march=amd64 Oh, and despite what Patrick said, I think you were right to post here first-- no need to clog up b.g.o with what might be a configuration problem and waste developer's time closing an invalid bug. I think it's always wise to try to make sure that it really is a bug before posting it. And it seems to me that if there is a bug, it might be a *documentation* bug (because the other person who mentioned using march=k8 said that that was the recommendation of the docs, but that seems to no longer be the case, if people using this flag are regularly receiving compilation errors). Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sat, 2005-07-23 at 14:50 +0200, Holly Bostick wrote: Well, since I just (literally, 10 minutes ago) emerged mozilla-firefox-1.0.6-r2, and had no problems on a 32-bit system, I must suspect that this is a 64-bit issue. In that regard, I see at least one thing in your emerge info that has been called into question for 64-bit users in recent threads: CFLAGS=-march=k8 I am, of course, not a 64-bit user, so I don't know anything about this, but I have seen several responses to similar questions that suggest that the correct flag is march=amd64 Do you remember where you've seen this? I have searched devel, user and amd64 without finding any relevant posting. I choose march=k8 due to the recommendation of the handbook. Thanks, jules -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On 05/07/23 14:50, Holly Bostick wrote: Jules Colding schreef: emerge --sync emerge -vauDN today gave me the following error. [snip] Well, since I just (literally, 10 minutes ago) emerged mozilla-firefox-1.0.6-r2, and had no problems on a 32-bit system, I must suspect that this is a 64-bit issue. In that regard, I see at least one thing in your emerge info that has been called into question for 64-bit users in recent threads: CFLAGS=-march=k8 I am, of course, not a 64-bit user, so I don't know anything about this, but I have seen several responses to similar questions that suggest that the correct flag is march=amd64 Looking at gcc's info page, there is no amd64 target. The only ones I can find that seems reasonable are k8 and athlon64. I use k8 myself and haven't had _any_ problems with it. Oh, and despite what Patrick said, I think you were right to post here first-- no need to clog up b.g.o with what might be a configuration problem and waste developer's time closing an invalid bug. I really don't see how this could be a configuration problem, since it would have complained about an erroneous compilation flag if it was the k8 thing that was at fault... And missing files (which the compilation error points at) sounds pretty much like a valid bug to me... I think it's always wise to try to make sure that it really is a bug before posting it. Of course, but looking at the ordinary response from developers to these kind of emails, I'd guess that b.g.o is where they want the report, not here... And it seems to me that if there is a bug, it might be a *documentation* bug (because the other person who mentioned using march=k8 said that that was the recommendation of the docs, but that seems to no longer be the case, if people using this flag are regularly receiving compilation errors). Documentation bug? Not recommended by the docs any more? You might want to actually try to find information about the subjects you respond to. Straight out of the AMD64 Gentoo Handbook: AMD64 users who want to use a native 64 bit system should use -march=k8 Combining that cite with the information from the gcc info page, I'm pretty sure it's not a documentation bug. -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D pgpXnDevvfSnn.pgp Description: PGP signature
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Patrick Börjesson wrote: Oh, and despite what Patrick said, I think you were right to post here first-- no need to clog up b.g.o with what might be a configuration problem and waste developer's time closing an invalid bug. I really don't see how this could be a configuration problem, since it would have complained about an erroneous compilation flag if it was the k8 thing that was at fault... And missing files (which the compilation error points at) sounds pretty much like a valid bug to me... Errors building packages are *frequently* configuration problems. Anybody who has followed this list for at least a month knows that. Thus, this is a perfectly valid forum to get feedback on an issue before filing a new bug report on b.g.o. Bug reports that are not really bugs just waste valuable developer time. That said, I do agree that this looks like an AMD64 specific bug. I think it's always wise to try to make sure that it really is a bug before posting it. Of course, but looking at the ordinary response from developers to these kind of emails, I'd guess that b.g.o is where they want the report, not here... Here being gentoo-user, there are not a lot of developer responses here. On gentoo-dev, you are correct, the standard response is file on b.g.o. But I still maintain that it is better to ask here (or on the forums, or on #gentoo) first. And it seems to me that if there is a bug, it might be a *documentation* bug (because the other person who mentioned using march=k8 said that that was the recommendation of the docs, but that seems to no longer be the case, if people using this flag are regularly receiving compilation errors). Documentation bug? Not recommended by the docs any more? You might want to actually try to find information about the subjects you respond to. Straight out of the AMD64 Gentoo Handbook: AMD64 users who want to use a native 64 bit system should use -march=k8 Combining that cite with the information from the gcc info page, I'm pretty sure it's not a documentation bug. Hold on...the -march thing would be an easy mistake to make for those of us who don't run AMD processors, and are just trying to help. Afterall, the platform keyword is amd64. And gcc info says that k8, opteron, athlon64, and athlon-fx are all equivalent, although I would suggest that the non-k8 options are more descriptive. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Patrick Börjesson wrote: When did I say that it wasn't frequent with configuration problems leading to failed builds? I was (and anyone really reading my reply would realize it) pointing to this specific failed build. And I'm just curious; how would a configuration error (that the user has made) lead to a graphics file missing during the build? (not counting in those configurations where you're yourself editing the ebuild or otherwise fucking with depends and build options suggested by the ebuild maintainer) I already said I agree with you, that in this specific case it seems to be a bug appropriate for reporting to b.g.o. But looking at your original response, you said: I'd think that the developers would rather have that information posted to http://bugs.gentoo.org/ instead... To me, Holly, and I'd bet many others, the instead... in that line could only be read as telling the OP that he has posted to the wrong place, and that we do not welcome such things here. Plus, the OP message was very much of the here is the output of a failed build, what does it mean variety. Many such posts come from people who don't know how to recognize the actual source of the build failure. Whether it says missing file, unresolved symbol, locking failed, or compiler bug, they simply do not know what it *really* means (and sometimes, not even what line contains the real problem). Now, I don't mean to offend any users here. I don't expect everybody running Gentoo to be a programmer or linux expert. So I will say it clearly: if a user encounters an error in emerge that he doesn't know what to do with, it is entirely appropriate to post here first. Of course, but in this case it wasn't an oversight... The poster explicitly said that using march=k8 seemed to no longer be the recommendation of the docs. That implies at least _some_ looking into the subject before posting... No, Holly said that her advice was based on recent threads. A recent thread on this list involving gzip on by an amd64 user suggested trying different march options. Now, it was _bad_ advice (sorry Holly, but it was!), but Holly did say she doesn't use amd64 and wasn't sure. Since I'm myself using the specified platform and have had at least a bit experience with it Good. Please help educate those of us who don't have or know the amd64 platform very well! :-) Also, since the originator had posted the emerge info output, I assumed that he/she was at least a bit familiar with how bug handling is handled by Gentoo. Maybe, but I still think it was pretty clear that the OP was not sure whether the problem was an actual bug or not. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Holly Bostick wrote: Well, since I just (literally, 10 minutes ago) emerged mozilla-firefox-1.0.6-r2, and had no problems on a 32-bit system, I must suspect that this is a 64-bit issue. Nope. I emerged both firefox and thunderbird without issue on my AMD64 4000+ about 14 hours ago. In that regard, I see at least one thing in your emerge info that has been called into question for 64-bit users in recent threads: CFLAGS=-march=k8 I use k8. k8, opteron, etc., etc. are supposed to be synonyms as I understand it. k8 is the preferred one according to most sources I have read but, if they are truly synonyms, I'm not sure why one should be preferred over another. Oh, and despite what Patrick said, I think you were right to post here first-- no need to clog up b.g.o with what might be a configuration problem and waste developer's time closing an invalid bug. I think it's always wise to try to make sure that it really is a bug before posting it. Quite right. I doubt that it is a bug - more likely a broken system in some way. the other person who mentioned using march=k8 said that that was the recommendation of the docs, but that seems to no longer be the case, if people using this flag are regularly receiving compilation errors No errors here. :) Be lucky, Neil -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On Sat, 23 Jul 2005 13:38:38 +0200 Jules Colding [EMAIL PROTECTED] wrote: emerge --sync emerge -vauDN today gave me the following error. I had no problem, on my amd64 system, emergeing firefox this morning - [ I] www-client/mozilla-firefox (1.0.6-r2): Firefox Web Browser Here is my emerge info - Portage 2.0.51.22-r2 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r4 x86_64) = System uname: 2.6.12-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.13 ccache version 2.3 [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox:1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS=amd64 AUTOCLEAN=yes CBUILD=x86_64-pc-linux-gnu CFLAGS=-O2 -pipe CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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=-O2 -pipe DISTDIR=/usr/portage/distfiles FEATURES=autoconfig candy distlocks sandbox sfperms strict GENTOO_MIRRORS=http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo; MAKEOPTS=-j2 PKGDIR=/usr/portage/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage SYNC=rsync://rsync.gentoo.org/gentoo-portage USE=amd64 3dnowex X a52 aac accessibility acpi alsa audiofile avi bitmap-fonts bmp bzip2 bzlib cap cdinstall cdparanoia cdr cdrom codecs cpudetection crypt css cups curl curlwrappers dga dillo dv dvd dvdr dvdread emul-linux encode escreen esd exif fame ffmpeg fftw flac flash fluidsynth foomaticdb freetype gd gdbm gif gimp gimpprint gkrellm glut gmp gpm gs gtk gtk2 ieee1394 image imlib imlib2 ithreads jack-tmpfs jpeg jpeg2k ladcca lcms libcaca lirc lm_sensors lzo lzw mad mbox mime ming mixer mjpeg mng mp3 mpeg mpeg2 mpeg4 mplayer multilib mythtv nls nptl nvidia offensive ogg oggvorbis openal opengl oss pcre pdf pdfkit pdflib perl php png portaudio posix ppds python quicktime rar real rtc ruby sdk slang sndfile spell ssl svg tcltk theora tiff transcode usb uudeview v4l2 vcd vcdimager vhosts vorbis wmf xanim xfs xine xml xml2 xmms xosd xpm xscreensaver xv xvid xvmc yv12 zlib zvbi userland_GNU kernel_linux elibc_glibc Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY Bob - -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Jules Colding wrote: Hi, emerge --sync emerge -vauDN today gave me the following error. [snip] adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
Zac Medico wrote: Jules Colding wrote: Hi, emerge --sync emerge -vauDN today gave me the following error. [snip] adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. This seems like a continuation of the previous build problems that you have had with firefox (where we were discussing MAKEOPTS). Assuming that others cannot reproduce this (sorry, I don't have my amd64 right now), there's still something wrong with your build system somewhere. This could be a shot in the dark, but I think that you should remerge your autoconf and automake packages to see if that affects this. Zac Hmm, since others with similar systems cannot duplicate the problem, I decided to capture all of the build output on my system (P4) and compare. Jules, there is definitely something not right on your system, but I don't know what yet. You get the following: +++ overriding content/cookie/contents.rdf adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/homedir = ../../dist/bin/chrome/classic.jar error: file './resources/skin/classic/taskbar-cookie.gif' doesn't exist at ../../config/make-jars.pl line 418. The /var/tmp/portage/homedir is wrong. On my system, I get: +++ overriding content/cookie/contents.rdf adding: content/cookie/contents.rdf (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/modern.jar zip warning: ../modern.jar not found or empty adding: skin/modern/communicator/cookie/taskbar-cookie.gif (stored 0%) adding: skin/modern/communicator/cookie/status-cookie.gif (stored 0%) +++ making chrome /var/tmp/portage/mozilla-firefox-1.0.6-r2/work/mozilla/extensions/cookie = ../../dist/bin/chrome/classic.jar Using the wrong version of autoconf/automake is the only thing I can think of that would cause this kind of thing. What do you get if you do: # which autoconf # autoconf --version -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can't emerge mozilla-firefox-1.0.6-r2
On 05/07/23 20:19, Richard Fish wrote: Patrick Börjesson wrote: I'd think that the developers would rather have that information posted to http://bugs.gentoo.org/ instead... To me, Holly, and I'd bet many others, the instead... in that line could only be read as telling the OP that he has posted to the wrong place, and that we do not welcome such things here. Ok, reading my original post again I can see your point ;) Plus, the OP message was very much of the here is the output of a failed build, what does it mean variety. Many such posts come from people who don't know how to recognize the actual source of the build failure. Whether it says missing file, unresolved symbol, locking failed, or compiler bug, they simply do not know what it *really* means (and sometimes, not even what line contains the real problem). Ok, I might have read a bit too much into the fact that he posted the output of emerge info. Not very usual in this list (from what I've seen in the last couple of years) since most people who don't know what line in the build failure is relevant mostly don't give much information either concerning arch and other information that might be important to help finding the cause. Although... I would suggest that the OP give a more explicit question, since I was really not sure if it was a anyone seen this before?, I'm a n00b, please solve this for me! or a where should I take this to get it solved? question. Now, I don't mean to offend any users here. I don't expect everybody running Gentoo to be a programmer or linux expert. So I will say it clearly: if a user encounters an error in emerge that he doesn't know what to do with, it is entirely appropriate to post here first. Agreed Of course, but in this case it wasn't an oversight... The poster explicitly said that using march=k8 seemed to no longer be the recommendation of the docs. That implies at least _some_ looking into the subject before posting... No, Holly said that her advice was based on recent threads. A recent thread on this list involving gzip on by an amd64 user suggested trying different march options. Now, it was _bad_ advice (sorry Holly, but it was!), but Holly did say she doesn't use amd64 and wasn't sure. Ok. I just make it a point of trying to find a bit more information, than just previous threads in a user mailinglist, about the things I suggest. But I'll try being more forgiving towards those who might not next time ;) Since I'm myself using the specified platform and have had at least a bit experience with it Good. Please help educate those of us who don't have or know the amd64 platform very well! :-) Ehm... now let's not take this overboard ;) I'm by no means an expert (or even near experienced) on this arch. I'm just saying I might have at least some information that might be more relevant than a 32 bit only person might have... Also, since the originator had posted the emerge info output, I assumed that he/she was at least a bit familiar with how bug handling is handled by Gentoo. Maybe, but I still think it was pretty clear that the OP was not sure whether the problem was an actual bug or not. Maybe, but I'm still inclined to give short (and sometimes uninformative) answers to questions that doesn't really give enough information regarding both the experience level of the person, and especially what he/she wants help with. -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D pgpdswVpJHBjf.pgp Description: PGP signature
