Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
Thanks for all your effort, Richard. It turns out to have been operator error all along. There's an old addition to my /etc/make.conf that adds the offending LDFLAGS stuff, with a note that it was inspired by a thread in this list. Sigh. If I had continued reading the thread for a few more days back then, I would have saved myself this trouble, as some wiser folks made it clear why this was bad. Odd that only the one package was clobbered by this. Oh, well... ++ kevin On 6/14/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/14/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: I would guess you're out of ideas then, except in desperation, I tried looking for just part of that: -W1 and came up with some stuff I hope will further inspire you: Nope, all of that is normal... But before you go breaking a braincell on this, realize that the ebuild became moot yesterday when I was able to create a binary package from a backup image and install it on the running image. So pursuing this may be wasted effort. The package is very old after all. Well let me take this opportunity to apologize for not giving you directions on how to work around this problem. Getting around it probably would have been fairly simple...I think an 'LDFLAGS= emerge --oneshot glib-1.2.10-r5' might have done it. I am still concerned though, since we don't know where those flags were coming from, they may return to bite you again. kdevelop won't emerge because it winds up needing a *.h file that does not exist, in a *.cpp file that is itself built from a *.ui file. It strikes me that this one's gonna have a huge learning curve (for me at least). Sounds like a pretty common problem with MAKEOPTS=-jN (N1). What can happen with a parallel make is that if one step needs a file that is generated by another step, it can start executing before the file is complete generated by the other step. The flow looks something like: thread-a: generating foo.h and foo.cpp from foo.ui... thread-b: waiting for foo.h and foo.cpp to make foo.o... thread-a: writing to foo.h and foo.cpp... thread-b: compiling foo.o from foo.cpp... thread-b: ERROR compiling foo.cpp! thread-a: finished writing to foo.h and foo.cpp... Makefiles have to be specially written to properly avoid the above scenario... The workaround is to 'MAKEOPTS=-j1 emerge --oneshot kdevelop' -Richard -- gentoo-user@gentoo.org mailing list -- Kevin O'Gorman, PhD -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/14/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/14/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: I would guess you're out of ideas then, except in desperation, I tried looking for just part of that: -W1 and came up with some stuff I hope will further inspire you: Nope, all of that is normal... But before you go breaking a braincell on this, realize that the ebuild became moot yesterday when I was able to create a binary package from a backup image and install it on the running image. So pursuing this may be wasted effort. The package is very old after all. Well let me take this opportunity to apologize for not giving you directions on how to work around this problem. Getting around it probably would have been fairly simple...I think an 'LDFLAGS= emerge --oneshot glib-1.2.10-r5' might have done it. I am still concerned though, since we don't know where those flags were coming from, they may return to bite you again. kdevelop won't emerge because it winds up needing a *.h file that does not exist, in a *.cpp file that is itself built from a *.ui file. It strikes me that this one's gonna have a huge learning curve (for me at least). Sounds like a pretty common problem with MAKEOPTS=-jN (N1). What can happen with a parallel make is that if one step needs a file that is generated by another step, it can start executing before the file is complete generated by the other step. The flow looks something like: thread-a: generating foo.h and foo.cpp from foo.ui... thread-b: waiting for foo.h and foo.cpp to make foo.o... thread-a: writing to foo.h and foo.cpp... thread-b: compiling foo.o from foo.cpp... thread-b: ERROR compiling foo.cpp! thread-a: finished writing to foo.h and foo.cpp... Makefiles have to be specially written to properly avoid the above scenario... The workaround is to 'MAKEOPTS=-j1 emerge --oneshot kdevelop' -Richard Thanks for the idea. No joy. I tried it and got the identical error. ++ kevin -- Kevin O'Gorman, PhD -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
Kevin O'Gorman wrote: checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1 -ldl-Wl,-O1) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The extra flags may be coming from your environment. From the same terminal where you would run emerge, run the following: set | grep O1 Daniel -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/14/06, Daniel Drake [EMAIL PROTECTED] wrote: Kevin O'Gorman wrote: checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1 -ldl-Wl,-O1) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The extra flags may be coming from your environment. From the same terminal where you would run emerge, run the following: set | grep O1 Daniel No joy. It comes up empty. Moreover, I've done plenty of other emerges without a problem. So there's something specific with this one. ++ kevin -- Kevin O'Gorman, PhD -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote:
On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:
Start digging. It completed just fine.
Ok, do this and send me the result.
# emerge --debug =dev-libs/glib-1.2.10-r5 ~/glib-merge.txt 21
-Richard
PS. Please post further replies in plain-text. The multi-part
HTML/text messages are making it difficult for me to reply and
maintain correct levels of ''. In gmail, just click the 'Plain text'
link above the composition box.
--
gentoo-user@gentoo.org mailing list
Done. Results attached. Sorry about the HTML. I hadn't noticed it
was turned on. And I generally oppose HTML mail.
++ kevin
--
Kevin O'Gorman, PhD
myaction None
myopts ['--debug', '--buildpkg']
Calculating dependencies
Parent:None
Depstring: =dev-libs/glib-1.2.10-r5
Candidates: ['=dev-libs/glib-1.2.10-r5']
ebuild: dev-libs/glib-1.2.10-r5
binpkg: None
+ dyn_clean
+ '[' -z /var/tmp/portage/glib-1.2.10-r5 ']'
+ type -p chflags
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/image
/var/tmp/portage/glib-1.2.10-r5/homedir
+ hasq keeptemp autoconfig buildpkg distlocks metadata-transfer sandbox sfperms
strict
+ [[ autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict
== *\ \k\e\e\p\t\e\m\p\ * ]]
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/temp
+ hasq keepwork autoconfig buildpkg distlocks metadata-transfer sandbox sfperms
strict
+ [[ autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict
== *\ \k\e\e\p\w\o\r\k\ * ]]
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.unpacked
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.compiled
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.tested
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.installed
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.packaged
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/build-info
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/work
+ '[' -f /var/tmp/portage/glib-1.2.10-r5/.unpacked ']'
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/distdir
++ find /var/tmp/portage/glib-1.2.10-r5 -mindepth 1 -maxdepth 1
+ '[' -z '' ']'
+ rmdir /var/tmp/portage/glib-1.2.10-r5
+ true
+ set +x
Parent:ebuild / dev-libs/glib-1.2.10-r5 merge
Depstring:
Exiting... None
... done!
Emerging (1 of 1) dev-libs/glib-1.2.10-r5 to /
checking ebuild checksums ;-)
checking auxfile checksums ;-)
checking miscfile checksums ;-)
checking glib-1.2.10.tar.gz ;-)
+ dyn_setup
++ type -t pre_pkg_setup
+ '[' '' == function ']'
+ pkg_setup
+ return
++ type -t post_pkg_setup
+ '[' '' == function ']'
+ set +x
+ dyn_unpack
+ trap abort_unpack SIGINT SIGQUIT
++ type -t pre_src_unpack
+ '[' '' == function ']'
+ local newstuff=no
+ '[' -e /var/tmp/portage/glib-1.2.10-r5/work ']'
+ '[' -e /var/tmp/portage/glib-1.2.10-r5/work ']'
+ '[' '!' -d /var/tmp/portage/glib-1.2.10-r5/work ']'
+ install -m0700 -d /var/tmp/portage/glib-1.2.10-r5/work
+ cd /var/tmp/portage/glib-1.2.10-r5/work
+ vecho ' Unpacking source...'
+ [[ '' == \1 ]]
+ echo ' Unpacking source...'
Unpacking source...
+ src_unpack
+ unpack glib-1.2.10.tar.gz
+ local x
+ local y
+ local myfail
+ local tarvars
+ '[' GNU == BSD ']'
+ tarvars=--no-same-owner
+ '[' -z glib-1.2.10.tar.gz ']'
+ for x in '$@'
+ vecho ' Unpacking glib-1.2.10.tar.gz to
/var/tmp/portage/glib-1.2.10-r5/work'
+ [[ '' == \1 ]]
+ echo ' Unpacking glib-1.2.10.tar.gz to
/var/tmp/portage/glib-1.2.10-r5/work'
Unpacking glib-1.2.10.tar.gz to /var/tmp/portage/glib-1.2.10-r5/work
+ y=glib-1.2.10.tar
+ y=tar
+ myfail='glib-1.2.10.tar.gz does not exist'
+ '[' gl = ./ ']'
+ srcdir=/var/tmp/portage/glib-1.2.10-r5/distdir/
+ [[ glib-1.2.10.tar.gz == /var/tmp/portage/glib-1.2.10-r5/distdir* ]]
+ '[' '!' -s /var/tmp/portage/glib-1.2.10-r5/distdir/glib-1.2.10.tar.gz ']'
+ myfail='failure unpacking glib-1.2.10.tar.gz'
+ case ${x##*.} in
+ '[' tar == tar ']'
+ tar zxf /var/tmp/portage/glib-1.2.10-r5/distdir/glib-1.2.10.tar.gz
--no-same-owner
+ chmod -Rf a+rX,u+w,g-w,o-w .
+ cd /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10
+ epatch /usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch
+ local PIPE_CMD=
+ local STDERR_TARGET=/var/tmp/portage/glib-1.2.10-r5/temp/3567.out
+ local PATCH_TARGET=/var/tmp/portage/glib-1.2.10-r5/temp/3567.patch
+ local PATCH_SUFFIX=
+ local SINGLE_PATCH=no
+ local x=
+ unset P4CONFIG P4PORT P4USER
+ '[' 1 -gt 1 ']'
+ '[' -n /usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch -a -f
/usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch ']'
+ SINGLE_PATCH=yes
+ local EPATCH_SOURCE=/usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch
+ local EPATCH_SUFFIX=patch
+ case ${EPATCH_SUFFIX##*\.} in
+ PIPE_CMD=cat
+ PATCH_SUFFIX=patch
+ '[' yes = no ']'
+ for x in '${EPATCH_SOURCE}'
+ '[' -f /usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch ']'
+ '[' yes = yes -o /usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch '!='
/usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch -o
/usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch '!='
/usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch ']'
+ local count=0
+ local 'popts=-g0
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/14/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: Done. Results attached. Sorry about the HTML. I hadn't noticed it was turned on. And I generally oppose HTML mail. Hmm, the problem first shows up here: + append-ldflags -ldl + [[ -z -ldl ]] + export 'LDFLAGS=-Wl,-O1 -ldl' + LDFLAGS='-Wl,-O1 -ldl' Just to explain, this occurs when the src_unpack step in the glib-1.2.10-r5.ebuild calls append-ldflags $(dlopen_lib). The append-ldflags function is defined in /usr/portage/eclass/flag-o-matic.eclass. But what this tells me is that LDFLAGS already exists in the environment, because the -Wl,-O1 part is already there. That means either it is in your make.conf or environment and we are missing it somehow, or it is being defined in some part of portage that is missed by the --debug option. So here is one more thing to try to figure this out: grep -r -- -Wl,-O1 /usr/portage/profiles /usr/portage/eclass /etc/portage /etc/profile* \ /usr/local/portage /usr/lib/portage /usr/portage/dev-libs/glib/ This had better turn up something...or I am out of ideas. :- -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/14/06, Richard Fish [EMAIL PROTECTED] wrote:
On 6/14/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:
Done. Results attached. Sorry about the HTML. I hadn't noticed it
was turned on. And I generally oppose HTML mail.
Hmm, the problem first shows up here:
+ append-ldflags -ldl
+ [[ -z -ldl ]]
+ export 'LDFLAGS=-Wl,-O1 -ldl'
+ LDFLAGS='-Wl,-O1 -ldl'
Just to explain, this occurs when the src_unpack step in the
glib-1.2.10-r5.ebuild calls append-ldflags $(dlopen_lib). The
append-ldflags function is defined in
/usr/portage/eclass/flag-o-matic.eclass.
But what this tells me is that LDFLAGS already exists in the
environment, because the -Wl,-O1 part is already there. That means
either it is in your make.conf or environment and we are missing it
somehow, or it is being defined in some part of portage that is missed
by the --debug option.
So here is one more thing to try to figure this out:
grep -r -- -Wl,-O1 /usr/portage/profiles /usr/portage/eclass
/etc/portage /etc/profile* \
/usr/local/portage /usr/lib/portage /usr/portage/dev-libs/glib/
This had better turn up something...or I am out of ideas. :-
-Richard
I would guess you're out of ideas then, except in desperation, I tried
looking for just part
of that: -W1 and came up with some stuff I hope will further inspire you:
treat ~ # grep -r -- -Wl /usr/portage/profiles /usr/portage/eclass
/etc/portage /etc/profile* /usr/local/portage /usr/lib/portage
/usr/portage/dev-libs/glib/
/usr/portage/eclass/flag-o-matic.eclass:
-fPIC|-fpic|-fPIE|-fpie|-Wl,pie|-pie)
/usr/portage/eclass/flag-o-matic.eclass:# Turn C style ldflags (-Wl,-foo) into
straight ldflags - the results
/usr/portage/eclass/flag-o-matic.eclass:# to gcc where it needs the '-Wl,'.
/usr/portage/eclass/flag-o-matic.eclass:x=${x#-Wl,}
/usr/portage/eclass/flag-o-matic.eclass:echo -Wl,-z,now ;;
/usr/portage/eclass/flag-o-matic.eclass:echo
-Wl,-z,now ;;
/usr/portage/eclass/toolchain.eclass: LC_ALL=C gcc ${T}/libctest.c -lc -o libctest
-Wl,-verbose ${T}/libctest.log || return 1
/usr/portage/eclass/x-modular.eclass: filter-ldflags -Wl,-z,now
/usr/lib/portage/bin/misc-functions.sh: vecho
LDFLAGS='-Wl,-z,now' emerge ${PN}
treat ~ #
But before you go breaking a braincell on this, realize that the
ebuild became moot yesterday
when I was able to create a binary package from a backup image and
install it on the running
image. So pursuing this may be wasted effort. The package is very
old after all.
So: would you like to help me figure out why revdep-rebuild cannot
rebuild the *current* version
of kdevelop for me? grin Now that all this time has been freed up
/grin. It is a concern because I'm going to be using kdevelop quite
a lot for a while now, so even though I've got
a installed version, I worry about hidden bugs and breakage.
Context: right now revdep-rebuild thinks it needs to remake kdevelop
and kmyfirewall. Nothing else. Its reasons seem to be a thousand or
so (!) breakages involving /usr/lib/kde3/*.la files. If I've got it
right, these are libtool files that are not part of what's
distributed, but are built by libtool.
kdevelop won't emerge because it winds up needing a *.h file that does
not exist, in a *.cpp file that is itself built from a *.ui file. It
strikes me that this one's gonna have a huge learning curve (for me at
least).
So: what do you wanna do?
--
Kevin O'Gorman, PhD
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/14/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: I would guess you're out of ideas then, except in desperation, I tried looking for just part of that: -W1 and came up with some stuff I hope will further inspire you: Nope, all of that is normal... But before you go breaking a braincell on this, realize that the ebuild became moot yesterday when I was able to create a binary package from a backup image and install it on the running image. So pursuing this may be wasted effort. The package is very old after all. Well let me take this opportunity to apologize for not giving you directions on how to work around this problem. Getting around it probably would have been fairly simple...I think an 'LDFLAGS= emerge --oneshot glib-1.2.10-r5' might have done it. I am still concerned though, since we don't know where those flags were coming from, they may return to bite you again. kdevelop won't emerge because it winds up needing a *.h file that does not exist, in a *.cpp file that is itself built from a *.ui file. It strikes me that this one's gonna have a huge learning curve (for me at least). Sounds like a pretty common problem with MAKEOPTS=-jN (N1). What can happen with a parallel make is that if one step needs a file that is generated by another step, it can start executing before the file is complete generated by the other step. The flow looks something like: thread-a: generating foo.h and foo.cpp from foo.ui... thread-b: waiting for foo.h and foo.cpp to make foo.o... thread-a: writing to foo.h and foo.cpp... thread-b: compiling foo.o from foo.cpp... thread-b: ERROR compiling foo.cpp! thread-a: finished writing to foo.h and foo.cpp... Makefiles have to be specially written to properly avoid the above scenario... The workaround is to 'MAKEOPTS=-j1 emerge --oneshot kdevelop' -Richard -- gentoo-user@gentoo.org mailing list
[gentoo-user] Gentoo system crumbling, reports of gcc death
It started with a kalarm problem, proceeded to Gentoo dependency heck, and
has progressed to the point that I fear the destruction of my current Gentoo system.
(I do have a recent tar backup of my entire root filesystem).
Right now I'm fighting with 'glib'. Some things are calling for glib-1.2*, and that
just won't emerge because the ebuild (get this!) says gcc is incapable of making
an executable. Faking it with packages.provided won't work because the
dependencies actually use some of the glib stuff during their own ebuilds.
I am partly to blame, of course. I got frustrated with older ebuilds that were
causing some of the dependency trouble, and got carried away with
emerge --prune, which I guess is just as broken as it says it is.
Anyway, here's what needs that old glib:
[EMAIL PROTECTED] portage # equery depends glib-1.2*
[ Searching for packages depending on glib-1.2*... ]
media-libs/libmovtar-0.1.3-r1
dev-python/wxpython-2.4.2.4-r3
x11-libs/wxGTK-2.4.2-r3
media-video/mjpegtools-1.6.2-r3
net-analyzer/ethereal-0.99.0
[EMAIL PROTECTED] portage #
Some dependencies are deep, so I cannot just unmerge that list.
There's only one ebuild that satisfies this need: 1.2.10-r5
* dev-libs/glib
Available versions: 1.2.10-r5 2.6.5 2.8.4 2.8.5 2.8.6 ~2.10.3
Installed: 2.8.6
Homepage: http://www.gtk.org/
Description: The GLib library of C routines
I've been building binary packages for quite a long while, but it
doesn't go back quite that far, so I really need it to emerge. But
it won't. It won't even configure, because something (autoconf?) says gcc is at fault:
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=pentium4
-fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1
-ldl-Wl,-O1) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
!!! Please attach the following file when filing a report to bugs.gentoo.org:
!!! /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10/config.log
!!! ERROR: dev-libs/glib-1.2.10-r5 failed.
Call stack:
ebuild.sh, line 1539: Called dyn_compile
ebuild.sh, line 939: Called src_compile
glib-1.2.10-r5.ebuild, line 43: Called econf '--with-threads=posix' '--enable-debug=yes'
ebuild.sh, line 541: Called die
!!! econf failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
[EMAIL PROTECTED] portage #
And that file it says to attach:
[EMAIL PROTECTED] portage # cat /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:634: checking for a BSD compatible install
configure:687: checking whether build environment is sane
configure:744: checking whether make sets ${MAKE}
configure:783: checking for working aclocal
configure:796: checking for working autoconf
configure:809: checking for working automake
configure:822: checking for working autoheader
configure:835: checking for working makeinfo
configure:951: checking host system type
configure:972: checking build system type
configure:992: checking for ranlib
configure:1022: checking for gcc
configure:1135: checking whether the C compiler (gcc -O2
-march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx
-fPIC -Wl,-O1 -ldl-Wl,-O1) works
configure:1151: gcc -o conftest -O2 -march=pentium4
-fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC
-Wl,-O1 -ldl-Wl,-O1 conftest.c 15
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ldl-Wl,-O1
collect2: ld returned 1 exit status
configure: failed program was:
#line 1146 configure
#include confdefs.h
main(){return(0);}
[EMAIL PROTECTED] portage #
This looks like an error in the last option on that command line. Is it now obsolete? Could
I install an earlier gcc and make this ebuild use it?
One way out just occurred to me: clear a partition to install that tar of the root partition, and
use it to quickpkg a copy of that old glib. Is there any simpler way?
-- Kevin O'Gorman, PhD
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: I am partly to blame, of course. I got frustrated with older ebuilds that were causing some of the dependency trouble, and got carried away with emerge --prune, which I guess is just as broken as it says it is. Ok, first take some deep breaths and relax. All is fixable. checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1 -ldl-Wl,-O1) works... no Looks like CFLAGS and LDFLAGS have gotten combined somehow. What does emerge --info show? Also post the output of env | grep -e CFLAGS -e CXXFLAGS -e LDFLAGS. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:I am partly to blame, of course.I got frustrated with older ebuilds that werecausing some of the dependency trouble, and got carried away with emerge --prune, which I guess is just as broken as it says it is.Ok, first take some deep breaths and relax.All is fixable. checking for gcc... gccchecking whether the C compiler (gcc -O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1 -ldl-Wl,-O1) works... noLooks like CFLAGS and LDFLAGS have gotten combined somehow.What does emerge --info show?Also post the output of env | grep -e CFLAGS -e CXXFLAGS -e LDFLAGS. That one comes up empty. There are no FLAGs in my environment. -Richard--gentoo-user@gentoo.org mailing listEmerge --info: [EMAIL PROTECTED] etc # emerge --info Portage 2.1 (default-linux/x86/2005.1, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r7-kosmanor i686) = System uname: 2.6.16-gentoo-r7-kosmanor i686 Intel(R) XEON(TM) CPU 1.80GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS=x86 AUTOCLEAN=yes CBUILD=i686-pc-linux-gnu CFLAGS=-O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /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/bind CONFIG_PROTECT_MASK=/etc/env.d /etc/gconf /etc/terminfo CXXFLAGS=-O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx DISTDIR=/usr/portage/distfiles FEATURES=autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict GENTOO_MIRRORS=ftp://fido.online.kz/gentoo/pub http://gentoo.inf.elte.hu/ ftp://ftp.isu.edu.tw/pub/Linux/Gentoo http://gentoo.scphost.com MAKEOPTS=-j3 PKGDIR=/usr/portage/packages PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages' PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY=/usr/local/portage SYNC=rsync://rsync.namerica.gentoo.org/gentoo-portage USE=x86 X Xaw3d acl acpi aim alsa apache2 apm arts avi bash-completion bcmath berkdb bitmap-fonts calendar caps cdr cli crypt cscope ctype cups dbm doc dri dvd dvdr eds emboss encode ethereal exif fastcgi foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile icq imagemagik imap imlib ipv6 isdnlog java joystick jpeg junit kde kerberos libg++ libwww mad mbox mcal mikmod mime mmap mmx motif mp3 mpeg mpi msession mysql ncurses nis nls nsplugin odbc offensive ogg oggvorbis openal opengl oscar oss pam pcre pdflib perl pic png posix postgres ppds pppd python qt quicktime readline reflection ruby samba sdl session snmp sockets spell spl sse ssl svga sysvipc tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb vorbis xml2 xmms xorg xpm xv yahoo zlib elibc_glibc kernel_linux userland_GNU Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS [EMAIL PROTECTED] etc # -- Kevin O'Gorman, PhD
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote:
On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:
checking for gcc... gcc
checking whether the C compiler (gcc -O2 -march=pentium4
-fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx -fPIC -Wl,-O1
-ldl-Wl,-O1) works... no
Looks like CFLAGS and LDFLAGS have gotten combined somehow.
What does emerge --info show? Also post the output of env | grep -e
CFLAGS -e CXXFLAGS -e LDFLAGS.
That one comes up empty. There are no FLAGs in my environment.
Well this is a bit confusing, because the command that configure uses
for the compiler test is:
${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS
The ebuild only adds the -fPIC option, and the -Wl,-O1 -ldl-Wl,-O1
stuff doesn't show up anywhere in the glib sources. So the only place
that could come from is the environment...
We didn't check CPPFLAGS, do you have that set by chance?
What does locate config.site report? (or find / -name config.site
if you don't use slocate). It should come back with nothing...
Just for comparison, when I build glib-1.2, I get:
checking whether the C compiler (gcc -march=pentium4 -Os
-fomit-frame-pointer -pipe -fweb -fPIC ) works... yes
and my CFLAGS are set to
CFLAGS=-march=pentium4 -Os -fomit-frame-pointer -pipe -fweb
So you can see the ebuild adds -fPIC option, and nothing else should
be sneaking in...
-Richard
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: Well this is a bit confusing, because the command that configure uses for the compiler test is: Something else that might give me some more ideas: find /usr/local/portage /etc/portage -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: Well this is a bit confusing, because the command that configure uses for the compiler test is: Something else that might give me some more ideas:find /usr/local/portage /etc/portage-Richard--gentoo-user@gentoo.org mailing list That was a bit more productive: [EMAIL PROTECTED] ~ # find /usr/local/portage/ /etc/portage /usr/local/portage/ /usr/local/portage/sys-kernel /usr/local/portage/sys-kernel/win4lin-sources /usr/local/portage/sys-kernel/win4lin-sources/Manifest /usr/local/portage/sys-kernel/win4lin-sources/files /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.brk-locked.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1137.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1016.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81295.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.PaX-84167.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81106.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.arpFix.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.vma.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.82201.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.78362.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1056.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.77666.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81195.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.77094.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.78363.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.4.28-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r11 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.cmdlineLeak.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-win4lin-sources-2.6.11-r11 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.binfmt_a.out.patch /usr/local/portage/sys-kernel/win4lin-sources/files/Changelog-2.4.bz2 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.1-r2 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.9-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.77181.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.10-r6 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.10-r7 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r7 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r8 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.7-r19 /usr/local/portage/sys-kernel/win4lin-sources/ChangeLog /usr/local/portage/sys-kernel/win4lin-sources/metadata.xml /usr/local/portage/sys-kernel/win4lin-sources/win4lin-sources-2.6.11-r11.ebuild/usr/local/portage/packages /usr/local/portage/Parallels-workstation.ebuild.tar.gz /usr/local/portage/app-emulation /usr/local/portage/app-emulation/parallels-workstation /usr/local/portage/app-emulation/parallels-workstation/files /usr/local/portage/app-emulation/parallels-workstation/files/2.0 /usr/local/portage/app-emulation/parallels-workstation/files/2.0/parallels.rc /usr/local/portage/app-emulation/parallels-workstation/files/parallels.rc /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.0.1514 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1598 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1622 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1634 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1650 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1658 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1670 /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.0.1514.ebuild /usr/local/portage/app-emulation/parallels-workstation/Manifest /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1622.ebuild /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1598.ebuild /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1634.ebuild
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On Tue, 13 Jun 2006 13:00:20 -0700, Kevin O'Gorman wrote: Nope. I checked just for FLAGS and got nothing. What about emerge --info | grep FLAG -- Neil Bothwick Heisenberg's Uncertainty Principle: The location of all objects cannot be known simultaneously. Corollary: If a lost thing is found, something else will disappear. signature.asc Description: PGP signature
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Neil Bothwick [EMAIL PROTECTED] wrote: On Tue, 13 Jun 2006 13:00:20 -0700, Kevin O'Gorman wrote: Nope.I checked just for FLAGS and got nothing.What aboutemerge --info | grep FLAG--Neil BothwickHeisenberg's Uncertainty Principle: The location of all objects cannot be known simultaneously. Corollary: If a lost thing is found, something elsewill disappear.nothing untoward:treat dev-libs # emerge --info | grep FLAGCFLAGS=-O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmx CXXFLAGS=-O2 -march=pentium4 -fomit-frame-pointer -pipe -mfpmath=sse -msse2 -mmmxUnset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTStreat dev-libs # ++ kevin-- Kevin O'Gorman, PhD
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: On 6/13/06, Richard Fish [EMAIL PROTECTED] wrote: Something else that might give me some more ideas: find /usr/local/portage /etc/portage That was a bit more productive:Yeah, but I still don't see anything that looks like a problem.Youhave no eclasses in your overlay, your don't have a stray bashrc in /etc/portage, or anything else that looks like it could beresponsible...Let's try this manually:# cd /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10# eval `grep CFLAGS= /etc/make.conf` ; export CFLAGS # eval `grep LDFLAGS= /etc/make.conf` ; export LDFLAGS# ./configure --with-threads=posix --enable-debug=yesSee if the above has the same problem and shows the same flags.If itdoes, try (notice the line continuation '\'...): # sh -x ./configure --with-threads=posix --enable-debug=yes 21 \ | bzip2 -9 ~/glib-configure-trace.bz2You can then email me the glib-configure-trace.bz2 file privately, toavoid consuming too much bandwidth on this list. If the above configure *doesn't* show the same problem, then there maybe something wrong with the environment that only shows up under theuser 'portage'.I'll have to do some more digging as to what this could be...-Richard--gentoo-user@gentoo.org mailing listStart digging. It completed just fine.++ kevin -- Kevin O'Gorman, PhD
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Kevin O'Gorman [EMAIL PROTECTED] wrote: Start digging. It completed just fine. Ok, do this and send me the result. # emerge --debug =dev-libs/glib-1.2.10-r5 ~/glib-merge.txt 21 -Richard PS. Please post further replies in plain-text. The multi-part HTML/text messages are making it difficult for me to reply and maintain correct levels of ''. In gmail, just click the 'Plain text' link above the composition box. -- gentoo-user@gentoo.org mailing list
