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
