Mailing List Archive

As an addendum to the above, I found this thread:

http://forums.gentoo.org/viewtopic-t-831467.html?sid=8182796e790caf6a0c9dd589570c8a4f

It looks like the build for akode is trying to find libakode.so before
it's actually been finished compiling. I still don't know what to do
about that, or why it would be happening now under GCC 4.4 when it
wasn't before, unless it's a libtool "--as-needed" related thing.

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted:

> As an addendum to the above, I found this thread:
>
> http://forums.gentoo.org/viewtopic-t-831467.html?
sid=8182796e790caf6a0c9dd589570c8a4f
>
> It looks like the build for akode is trying to find libakode.so before
> it's actually been finished compiling. I still don't know what to do
> about that, or why it would be happening now under GCC 4.4 when it
> wasn't before, unless it's a libtool "--as-needed" related thing.

IIRC, I had decided I didn't actually need akode for my usage long before
I ever switched to kde4, and thus haven't compiled it in... years, now. I
believe I was running into issues that lead to that investigation and
conclusion, that may be similar to what you're running into now. (FWIW, I
run ~arch and often unmask and run the latest gcc well before it's even
unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4
issues quite some time ago, tho I think this was long before that,
possibly as far back as the gcc-3.5 era.)

But, you mention a "new machine", presumably a multi-core machine, that
you're taking advantage of with MAKEOPTS=-jX, with X>1. While your
previous machines may also be multi-core, for various reasons they may
have used a different make job scheduling order and thus not run into the
problem. Or, perhaps it's a combination of that and --as-needed.

FWIW... my main machine is a dual socket Opteron 2xx, now top-of-its-line
Opteron 290s, so dual-dual-cores, but for years I ran dual Opteron 242s,
single-core, but two of them, so I've been running into parallel make
errors since I switched to Gentoo on the system in 2004. I've also been
running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's
indeed quite conceivable that I'd have run into parallel make issues,
perhaps related to --as-needed, perhaps not, way back when I /was/ still
building akode, if the package is wont to trigger them, as it seems to be.

So... try building the package with MAKEOPTS=-j1 and see if that works.
If so, it's a workaround; the makefile dependencies should really be fixed
properly, but that takes some make file (and possibly other) knowledge few
folks have, apparently even at the Gentoo developer level. A lot of the
time, therefore, such issues are simply worked around, with the ebuild
hard-coding MAKEOPTS=-j1. So assuming it works, that's likely the change
that'll happen -- make the ebuild hardcode MAKEOPTS=-j1.

(FWIW, I'm not going to discount the reasons many still run kde3, as until
4.4 and better, 4.5, despite official kde announcements to the contrary,
kde4 was simply too bug riddled to be reasonably usable, and I spent well
over 100 hours finding workaround, often scripting my own, and otherwise
making an otherwise broken kde-4.2.4 work for me when I switched so I KNOW
this to be true, but one thing I *DO* appreciate about kde4 is how much
more effectively it parallel builds in comparison to kde3, therefore
taking about half the build time on a 4-core including my dual-dual-core
system, compared to kde3. It's NICE to be able to do a kde4 upgrade in
the 4 hours or so it takes now, depending on how much is new code and how
much is not in ccache, compared to the entire day, 6-8 hours, if there
weren't other problems, it'd take to do the same with kde3.)

Meanwhile, until it gets into the ebuild, assuming you're using portage
(the other two package managers have their own system for this), you can
set the MAKEOPTS=-j1 for that specific package only, using /etc/portage/
env. This trick isn't well known or documented for what are now mostly
historical reasons (devs objected to making it too public as package
specific settings weren't reported in emerge --info, thus making
troubleshooting bugs difficult, but emerge --info <package> now reports
where settings for that package differ from the global settings), but
here's how to do it:

1) If the directory doesn't already exist, create /etc/portage/env/ with
the same ownership and permissions as /etc/portage/ .

2) The structure under env/ is category subdirs, package files. Thus, for
this package, you'll have the file /etc/portage/env/media-libs/akode .
Again, permissions should be similar to those in /etc/portage.

3) In /etc/portage/env/media-libs/akode , place the following line:

MAKEOPTS=-j1

That should be all there is to it. Portage should now always use only a
single job when building akode. I routinely use /etc/portage/env files
for setting single MAKEOPTS jobs and it works well. =:^)

/etc/portage/env/*/* files can be used for package specific cflags, etc,
too. In fact, they should work for anything that affects only the bash
side of portage, and because they /are/ bash, bash tricks like the
following also work:

I have this in /etc/portage/env/sys-fs/mdadm (one of several packages with
the issue), removing the -combine CFLAG from my normal CFLAGS using bash's
${var//} substitution construct, since mdadm doesn't like -combine.

CFLAGS="${CFLAGS/ -combine/}"


The one caveat that at least used to apply to /etc/portage/env/ files (I'm
not positive it still does as I've not had need of the missed
functionality, here) is that they're sourced into the bash side of
portage, namely, ebuild.sh, not the python side. So settings that affect
the python side (like some FEATURES) may not work as intended, while those
only affecting the bash side should. So changes affecting dependency
calculation, which is done on the python side, etc, might not "take". If
in doubt, simply try it and see.

So for testing and to work around the issue yourself until it's fixed in
the ebuild, use the env file. Once either a proper fix or at least the
MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the ebuild,
you can remove the env file workaround. No more having to change global
make.conf settings for a single package, then having to change them back!
=:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Sat, 21 Aug 2010, Duncan wrote:

> Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted:
>
>> As an addendum to the above, I found this thread:
>>
>> http://forums.gentoo.org/viewtopic-t-831467.html?
> sid=8182796e790caf6a0c9dd589570c8a4f
>>
>> It looks like the build for akode is trying to find libakode.so before
>> it's actually been finished compiling. I still don't know what to do
>> about that, or why it would be happening now under GCC 4.4 when it
>> wasn't before, unless it's a libtool "--as-needed" related thing.
>
> IIRC, I had decided I didn't actually need akode for my usage long before
> I ever switched to kde4, and thus haven't compiled it in... years, now. I
> believe I was running into issues that lead to that investigation and
> conclusion, that may be similar to what you're running into now. (FWIW, I
> run ~arch and often unmask and run the latest gcc well before it's even
> unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4
> issues quite some time ago, tho I think this was long before that,
> possibly as far back as the gcc-3.5 era.)
>
> But, you mention a "new machine", presumably a multi-core machine, that
> you're taking advantage of with MAKEOPTS=-jX, with X>1. While your
> previous machines may also be multi-core, for various reasons they may
> have used a different make job scheduling order and thus not run into the
> problem. Or, perhaps it's a combination of that and --as-needed.

Actually, the new machine plus the two previous machines have all had
SMP. But I've never used a -j option on any of them, because the fact
that parallel compilation doesn't always work right has always scared me
away from it and made me worry I could be causing myself unnecessary
grief in the future with hard-to-diagnose issues. I'd love to use it to
get builds done faster, but the extra speed has never been worth it to
me if I can't entirely trust it.

So, I've never used any '-j' setting in MAKEOPTS on any system. Is it
possible that with GCC 4.4 I'm getting some kind of implied parallel
execution anyway though, requiring me to set '-j1' to override it for
this package?

> I've also been
> running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's
> indeed quite conceivable that I'd have run into parallel make issues,
> perhaps related to --as-needed, perhaps not, way back when I /was/ still
> building akode, if the package is wont to trigger them, as it seems to be.

This is the first machine I've installed from scratch since
'--as-needed' became part of the desktop policy. It's never seen a
libtool environment that doesn't use it -- I don't know if that has
anything to do with this problem or not though.

> So... try building the package with MAKEOPTS=-j1 and see if that works.
> If so, it's a workaround; the makefile dependencies should really be fixed
> properly, but that takes some make file (and possibly other) knowledge few
> folks have, apparently even at the Gentoo developer level. A lot of the
> time, therefore, such issues are simply worked around, with the ebuild
> hard-coding MAKEOPTS=-j1. So assuming it works, that's likely the change
> that'll happen -- make the ebuild hardcode MAKEOPTS=-j1.

Just tried it, unfortunately, it did the same thing:

Making all in src_resampler
make[4]: Entering directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler'
if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../..
-I../../../akode/lib -I../../../akode/lib -I../../../akode/lib
-I./mppdec -O2 -march=athlon64 -pipe -MT src_resampler.lo -MD -MP
-MF ".deps/src_resampler.Tpo" -c -o src_resampler.lo src_resampler.cpp;
\
then mv -f ".deps/src_resampler.Tpo" ".deps/src_resampler.Plo";
else rm -f ".deps/src_resampler.Tpo"; exit 1; fi
/bin/sh ../../../libtool --silent --tag=CXX --mode=link
x86_64-pc-linux-gnu-g++ -O2 -march=athlon64 -pipe -Wl,-O1
-Wl,--as-needed -o libakode_src_resampler.la -rpath /usr/lib64 -module
-avoid-version -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined src_resampler.lo ../../lib/libakode.la
-lsamplerate
make[4]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler'
make[4]: Entering directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
make[3]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
Making all in akodeplay
make[3]: Entering directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/akodeplay'
if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../..
-I../../akode/lib -I../../akode/lib -I../../akode/lib -O2
-march=athlon64 -pipe -MT akodeplay.o -MD -MP -MF ".deps/akodeplay.Tpo"
-c -o akodeplay.o akodeplay.cpp; \
then mv -f ".deps/akodeplay.Tpo" ".deps/akodeplay.Po"; else rm
-f ".deps/akodeplay.Tpo"; exit 1; fi
/bin/sh ../../libtool --silent --tag=CXX --mode=link
x86_64-pc-linux-gnu-g++ -O2 -march=athlon64 -pipe -Wl,-O1
-Wl,--as-needed -o akodeplay akodeplay.o ../lib/libakode.la
x86_64-pc-linux-gnu-g++: ../lib/.libs/libakode.so: No such file or
directory
make[3]: *** [akodeplay] Error 1

> (FWIW, I'm not going to discount the reasons many still run kde3, as
> until 4.4 and better, 4.5, despite official kde announcements to the
> contrary, kde4 was simply too bug riddled to be reasonably usable, and
> I spent well over 100 hours finding workaround, often scripting my
> own, and otherwise making an otherwise broken kde-4.2.4 work for me
> when I switched so I KNOW this to be true, but one thing I *DO*
> appreciate about kde4 is how much more effectively it parallel builds
> in comparison to kde3, therefore taking about half the build time on a
> 4-core including my dual-dual-core system, compared to kde3. It's
> NICE to be able to do a kde4 upgrade in the 4 hours or so it takes
> now, depending on how much is new code and how much is not in ccache,
> compared to the entire day, 6-8 hours, if there weren't other
> problems, it'd take to do the same with kde3.)

Yeah, but the problem with it to me is it just isn't the same desktop
anymore. Most of it seems to be imitating Windows Vista/7, with a few
things derived from MacOS/X here and there (like the new Control Panel,
which strongly resembles the Mac's System Preferences app). KDE 3 used
to let you make desktops that were totally different.

My own desktop actually resembles -- and this will probably puzzle some
people -- CDE from HP-UX. I'm one of those strange people who actually
like an X11 desktop to look like an X11 desktop. I find that most
"modern" desktops from Microsoft look and feel like a credit card
advertisement, while most modern desktops from Apple look like a 70's
car stereo (brushed chrome everywhere!). It seems to be very out of
fashion now to prefer one's computer look and act like...gasp!...a
computer, but that's what I like, and up until KDE 4, KDE was providing
a very nice CDE emulation. (Actually, KDE 3's imitation of CDE is quite
a bit more functional that real CDE...no shock there, I suppose.)

Plus there's the fact that KDE 4, even now that it's more stable, seems
to use resources like we had them to burn. Actually, on modern
machines, that might be true, but I run studio recording apps, which is
a genre of application where more bandwidth equals more tracks, more
plugins, more disk i/o, etc. It's one of the few remaining types of
apps these days that are *not* just leaving your system idle most of the
time, and really do want all you can give them. People who are running
pro audio apps do not have CPU/RAM to burn, ever, even on a fast
machine! If you are running such programs, and your machine has more to
give, you want to give it to the apps, not the desktop, no matter how
*much* more that is.

So in general, KDE 4 has turned me away. I'll pass on its Windows Vista
look and feel, its enormous resource footprint, and the way they made
keeping any semblance of my current CDE-ish KDE desktop unsupportable.

> So for testing and to work around the issue yourself until it's fixed
> in the ebuild, use the env file. Once either a proper fix or at least
> the MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the
> ebuild, you can remove the env file workaround. No more having to
> change global make.conf settings for a single package, then having to
> change them back! =:^)

Thanks for the help, but that didn't seem to fix it. I never use '-j'
options anyway. I'll probably start if they ever start working all the
time.

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

On 21 August 2010 18:37, Brent Busby <brent@keycorner.org> wrote:
> On Sat, 21 Aug 2010, Duncan wrote:
>
>> Brent Busby posted on Fri, 20 Aug 2010 13:37:15 -0500 as excerpted:
>>
>>> As an addendum to the above, I found this thread:
>>>
>>> http://forums.gentoo.org/viewtopic-t-831467.html?
>>
>> sid=8182796e790caf6a0c9dd589570c8a4f
>>>
>>> It looks like the build for akode is trying to find libakode.so before
>>> it's actually been finished compiling.  I still don't know what to do
>>> about that, or why it would be happening now under GCC 4.4 when it
>>> wasn't before, unless it's a libtool "--as-needed" related thing.
>>
>> IIRC, I had decided I didn't actually need akode for my usage long before
>> I ever switched to kde4, and thus haven't compiled it in... years, now.  I
>> believe I was running into issues that lead to that investigation and
>> conclusion, that may be similar to what you're running into now.  (FWIW, I
>> run ~arch and often unmask and run the latest gcc well before it's even
>> unmasked to ~arch, and am running gcc-4.5.1 now, so I'd have seen gcc-4.4
>> issues quite some time ago, tho I think this was long before that,
>> possibly as far back as the gcc-3.5 era.)
>>
>> But, you mention a "new machine", presumably a multi-core machine, that
>> you're taking advantage of with MAKEOPTS=-jX, with X>1.  While your
>> previous machines may also be multi-core, for various reasons they may
>> have used a different make job scheduling order and thus not run into the
>> problem.  Or, perhaps it's a combination of that and --as-needed.
>
> Actually, the new machine plus the two previous machines have all had SMP.
>  But I've never used a -j option on any of them, because the fact that
> parallel compilation doesn't always work right has always scared me away
> from it and made me worry I could be causing myself unnecessary grief in the
> future with hard-to-diagnose issues.  I'd love to use it to get builds done
> faster, but the extra speed has never been worth it to me if I can't
> entirely trust it.
>
> So, I've never used any '-j' setting in MAKEOPTS on any system.  Is it
> possible that with GCC 4.4 I'm getting some kind of implied parallel
> execution anyway though, requiring me to set '-j1' to override it for this
> package?
>
>> I've also been
>> running --as-needed in my LDFLAGS, since 2006 or 2007 I'd guess, so it's
>> indeed quite conceivable that I'd have run into parallel make issues,
>> perhaps related to --as-needed, perhaps not, way back when I /was/ still
>> building akode, if the package is wont to trigger them, as it seems to be.
>
> This is the first machine I've installed from scratch since '--as-needed'
> became part of the desktop policy.  It's never seen a libtool environment
> that doesn't use it -- I don't know if that has anything to do with this
> problem or not though.
>
>> So... try building the package with MAKEOPTS=-j1 and see if that works.
>> If so, it's a workaround; the makefile dependencies should really be fixed
>> properly, but that takes some make file (and possibly other) knowledge few
>> folks have, apparently even at the Gentoo developer level.  A lot of the
>> time, therefore, such issues are simply worked around, with the ebuild
>> hard-coding MAKEOPTS=-j1.  So assuming it works, that's likely the change
>> that'll happen -- make the ebuild hardcode MAKEOPTS=-j1.
>
> Just tried it, unfortunately, it did the same thing:
>
> Making all in src_resampler
> make[4]: Entering directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler'
> if /bin/sh ../../../libtool --silent --tag=CXX --mode=compile
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../..
> -I../../../akode/lib -I../../../akode/lib -I../../../akode/lib -I./mppdec
>   -O2 -march=athlon64 -pipe  -MT src_resampler.lo -MD -MP -MF
> ".deps/src_resampler.Tpo" -c -o src_resampler.lo src_resampler.cpp; \
>        then mv -f ".deps/src_resampler.Tpo" ".deps/src_resampler.Plo"; else
> rm -f ".deps/src_resampler.Tpo"; exit 1; fi
> /bin/sh ../../../libtool --silent --tag=CXX --mode=link
> x86_64-pc-linux-gnu-g++  -O2 -march=athlon64 -pipe   -Wl,-O1 -Wl,--as-needed
> -o libakode_src_resampler.la -rpath /usr/lib64 -module -avoid-version
> -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined
> src_resampler.lo ../../lib/libakode.la -lsamplerate
> make[4]: Leaving directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins/src_resampler'
> make[4]: Entering directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
> make[4]: Nothing to be done for `all-am'.
> make[4]: Leaving directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
> make[3]: Leaving directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/plugins'
> Making all in akodeplay
> make[3]: Entering directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/akodeplay'
> if x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../akode/lib
> -I../../akode/lib -I../../akode/lib     -O2 -march=athlon64 -pipe  -MT
> akodeplay.o -MD -MP -MF ".deps/akodeplay.Tpo" -c -o akodeplay.o
> akodeplay.cpp; \
>        then mv -f ".deps/akodeplay.Tpo" ".deps/akodeplay.Po"; else rm -f
> ".deps/akodeplay.Tpo"; exit 1; fi
> /bin/sh ../../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++
>  -O2 -march=athlon64 -pipe   -Wl,-O1 -Wl,--as-needed -o akodeplay
>  akodeplay.o ../lib/libakode.la
> x86_64-pc-linux-gnu-g++: ../lib/.libs/libakode.so: No such file or directory
> make[3]: *** [akodeplay] Error 1
>
>> (FWIW, I'm not going to discount the reasons many still run kde3, as until
>> 4.4 and better, 4.5, despite official kde announcements to the contrary,
>> kde4 was simply too bug riddled to be reasonably usable, and I spent well
>> over 100 hours finding workaround, often scripting my own, and otherwise
>> making an otherwise broken kde-4.2.4 work for me when I switched so I KNOW
>> this to be true, but one thing I *DO* appreciate about kde4 is how much more
>> effectively it parallel builds in comparison to kde3, therefore taking about
>> half the build time on a 4-core including my dual-dual-core system, compared
>> to kde3.  It's NICE to be able to do a kde4 upgrade in the 4 hours or so it
>> takes now, depending on how much is new code and how much is not in ccache,
>> compared to the entire day, 6-8 hours, if there weren't other problems, it'd
>> take to do the same with kde3.)
>
> Yeah, but the problem with it to me is it just isn't the same desktop
> anymore.  Most of it seems to be imitating Windows Vista/7, with a few
> things derived from MacOS/X here and there (like the new Control Panel,
> which strongly resembles the Mac's System Preferences app).  KDE 3 used to
> let you make desktops that were totally different.
>
> My own desktop actually resembles -- and this will probably puzzle some
> people -- CDE from HP-UX.  I'm one of those strange people who actually like
> an X11 desktop to look like an X11 desktop.  I find that most "modern"
> desktops from Microsoft look and feel like a credit card advertisement,
> while most modern desktops from Apple look like a 70's car stereo (brushed
> chrome everywhere!).  It seems to be very out of fashion now to prefer one's
> computer look and act like...gasp!...a computer, but that's what I like, and
> up until KDE 4, KDE was providing a very nice CDE emulation.  (Actually, KDE
> 3's imitation of CDE is quite a bit more functional that real CDE...no shock
> there, I suppose.)
>
> Plus there's the fact that KDE 4, even now that it's more stable, seems to
> use resources like we had them to burn.  Actually, on modern machines, that
> might be true, but I run studio recording apps, which is a genre of
> application where more bandwidth equals more tracks, more plugins, more disk
> i/o, etc.  It's one of the few remaining types of apps these days that are
> *not* just leaving your system idle most of the time, and really do want all
> you can give them.  People who are running pro audio apps do not have
> CPU/RAM to burn, ever, even on a fast machine!  If you are running such
> programs, and your machine has more to give, you want to give it to the
> apps, not the desktop, no matter how *much* more that is.
>
> So in general, KDE 4 has turned me away.  I'll pass on its Windows Vista
> look and feel, its enormous resource footprint, and the way they made
> keeping any semblance of my current CDE-ish KDE desktop unsupportable.
>
>> So for testing and to work around the issue yourself until it's fixed in
>> the ebuild, use the env file.  Once either a proper fix or at least the
>> MAKEOPTS=j1 workaround (assuming it fixes the problem) is in the ebuild, you
>> can remove the env file workaround.  No more having to change global
>> make.conf settings for a single package, then having to change them back!
>> =:^)
>
> Thanks for the help, but that didn't seem to fix it.  I never use '-j'
> options anyway.  I'll probably start if they ever start working all the
> time.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>

Can you post the full build log as an attachment or URL? All I can
tell from the current output is that libakode.la is not being produced
by something earlier in the build.

If this is an as-needed issue, the problem is likely to be that akode
was implicitly relying on a dependent library bringing in another
library it needs and it no longer does that because of as-needed.
I've already seen patches going into the mainline packages to fix such
issues (may be worth checking if you have any pending updates). I hit
at least one issue like this when rebuilding after the --as-needed
change went in.

Adding stuff like --as-needed may help the occasional libpng upgrade,
but it means packages may be being built in a way that isn't being
tested regularly by its developers.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:

> Can you post the full build log as an attachment or URL? All I can
> tell from the current output is that libakode.la is not being produced
> by something earlier in the build.
>
> If this is an as-needed issue, the problem is likely to be that akode
> was implicitly relying on a dependent library bringing in another
> library it needs and it no longer does that because of as-needed.
> I've already seen patches going into the mainline packages to fix such
> issues (may be worth checking if you have any pending updates). I hit
> at least one issue like this when rebuilding after the --as-needed
> change went in.
>
> Adding stuff like --as-needed may help the occasional libpng upgrade,
> but it means packages may be being built in a way that isn't being
> tested regularly by its developers.

Okay, here is the whole build log as an attachment.

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Hello,

I have actually seen this bug before and resolved it somehow (possibly
with USE=-akode), before --as-needed is being used.

It seemed to me like autotools bug, since it just did not resolve
dependecies right (libakode.so is not produced in time). When I build
libakode.la manually, it worked (I remember that the makefiles did
_not_ contained the libtool call to create it -- again seems to me
like automake bug).

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Sun, Aug 22, 2010 at 2:51 AM, Brent Busby <brent@keycorner.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
>> Can you post the full build log as an attachment or URL?  All I can
>> tell from the current output is that libakode.la is not being produced
>> by something earlier in the build.
>>
>> If this is an as-needed issue, the problem is likely to be that akode
>> was implicitly relying on a dependent library bringing in another
>> library it needs and it no longer does that because of as-needed.
>> I've already seen patches going into the mainline packages to fix such
>> issues (may be worth checking if you have any pending updates).  I hit
>> at least one issue like this when rebuilding after the --as-needed
>> change went in.
>>
>> Adding stuff like --as-needed may help the occasional libpng upgrade,
>> but it means packages may be being built in a way that isn't being
>> tested regularly by its developers.
>
> Okay, here is the whole build log as an attachment.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky

Brent Busby posted on Sat, 21 Aug 2010 12:37:40 -0500 as excerpted:

> Actually, the new machine plus the two previous machines have all had
> SMP. But I've never used a -j option on any of them, because the fact
> that parallel compilation doesn't always work right has always scared
> me away from it and made me worry I could be causing myself unnecessary
> grief in the future with hard-to-diagnose issues. I'd love to use it
> to get builds done faster, but the extra speed has never been worth it
> to me if I can't entirely trust it.
>
> So, I've never used any '-j' setting in MAKEOPTS on any system. Is it
> possible that with GCC 4.4 I'm getting some kind of implied parallel
> execution anyway though, requiring me to set '-j1' to override it for
> this package?

FWIW, the type of breakage parallel make issues cause is, AFAIK, always a
build-time breakage. If it builds fine but fails at run-time, it's not
due to parallel make, but due to some other reason.

Given that, you should be able to enable parallel make without worrying
about it. The time it saves is well worth the occasional breakage with
resulting halted merge, and then having to test and add a MAKEOPTS var to
the appropriate /etc/portage/env file. Additionally, any errors you do
run into are likely to be pretty well front-loaded. That is, you'll get
them the first time you recompile that package after you enable parallel
make, but after testing and finding that's the problem once (and hopefully
checking for and reporting a bug if there's not one already filed), you
can stick MAKEOPTS=-j1 in the appropriate env file, and won't have to
worry about it again (unless you want to test to see if it's fixed, a few
versions later), as the system will always use the env file setting for
that package from then on. So after you've rebuilt your system a time or
two, you'll seldom have the issue any more (unless upstream introduced a
new bug), as all the problem packages will have -j1 already set in their
env file, and will thus build without issue.

Certainly, that's what I've found here. But the problem is much rarer
than it was at least on mainline packages anyway (meaning I have fewer
such env files than I used to, as I filed bugs, which eventually got fixed
or at least worked around with a -j1 in the ebuild), as the ones with
problems have all long since been reported and fixed or worked around by
now. You may still find the occasional issue with a freshly introduced
bug on an upgrade (tho it's unlikely on stable since ~arch will have
likely caught it), and may find it on occasional obscure packages that
nobody's bugged yet, but most definitely, the issue's FAR less common than
it was, back before multi-cores became popular and I was one of the few
running a dual CPU system, as there's FAR more wide testing for it, these
days, and the bugs have for the most part been fixed by now.


> This is the first machine I've installed from scratch since
> '--as-needed' became part of the desktop policy. It's never seen a
> libtool environment that doesn't use it -- I don't know if that has
> anything to do with this problem or not though.

FWIW, I installed Gentoo/~x86 from stages on my netbook, only a few months
ago. I stuck --as-needed (plus a couple other select LDFLAGS I use) on
it before the first build, so I /have/ actually done it.

But as mentioned, I've already switched to kde4, and installed it
directly, so that machine never saw kde3. Given the overlay situation,
all of kde3 would definitely qualify as "obscure packages" that won't have
had the testing that mainline stuff, including kde4, has had. So I can't
say it'd surprise me to find that kde3 had a few packages that didn't like
--as-needed.

>> So... try building the package with MAKEOPTS=-j1 and see if that works.

> Just tried it, unfortunately, it did the same thing:

Well, that one shot down, unfortunately!

>> (FWIW, I'm not going to discount the reasons many still run kde3, as
>> until 4.4 and better, 4.5, despite official kde announcements to the
>> contrary, kde4 was simply too bug riddled to be reasonably usable, and
>> I spent well over 100 hours finding workaround, often scripting my own,
>> and otherwise making an otherwise broken kde-4.2.4 work for me when I
>> switched so I KNOW this to be true, but one thing I *DO* appreciate
>> about kde4 is how much more effectively it parallel builds in
>> comparison to kde3, therefore taking about half the build time on a
>> 4-core including my dual-dual-core system, compared to kde3. It's NICE
>> to be able to do a kde4 upgrade in the 4 hours or so it takes now,
>> depending on how much is new code and how much is not in ccache,
>> compared to the entire day, 6-8 hours, if there weren't other problems,
>> it'd take to do the same with kde3.)
>
> Yeah, but the problem with it to me is it just isn't the same desktop
> anymore. Most of it seems to be imitating Windows Vista/7, with a few
> things derived from MacOS/X here and there (like the new Control Panel,
> which strongly resembles the Mac's System Preferences app). KDE 3 used
> to let you make desktops that were totally different.

Keeping in mind what I said about not discounting anyone's reasons for
still running kde3... May it continue to serve you well as long as you
continue to choose it!

I've never met a desktop environment that I liked in default config. FWIW,
that's one of the reasons I'm a kde guy, as the lack of proper config
options for gnome drives me crazy.

And kde4 is now actually even more configurable than kde3 was, including
ways to turn much of the "bling" off (and reset the desktop to the
traditional single desktop folder icon based view), making it much like
kde3. It's still some work reconfiguring stuff, but that can be expected
from any upgrade of that size, and with 4.5, in general it's now only what
one would expect to have to reconfigure with a major version bump upgrade,
with little remaining of the the 100+ hour hell of additional brokenness
workarounds, etc, that I had to do back with 4.2.4.

> My own desktop actually resembles -- and this will probably puzzle some
> people -- CDE from HP-UX. I'm one of those strange people who actually
> like an X11 desktop to look like an X11 desktop. I find that most
> "modern" desktops from Microsoft look and feel like a credit card
> advertisement, while most modern desktops from Apple look like a 70's
> car stereo (brushed chrome everywhere!). It seems to be very out of
> fashion now to prefer one's computer look and act like...gasp!...a
> computer, but that's what I like, and up until KDE 4, KDE was providing
> a very nice CDE emulation. (Actually, KDE 3's imitation of CDE is quite
> a bit more functional that real CDE...no shock there, I suppose.)

Well, I don't know /what/ mine resembles. Certainly no defaults I've ever
seen, anywhere, that's for SURE! But it fits my style well, almost like a
custom fitted glove, now, mostly because it /is/ custom fitted, now, and
that's the important thing for me.

> Plus there's the fact that KDE 4, even now that it's more stable, seems
> to use resources like we had them to burn. Actually, on modern
> machines, that might be true, but I run studio recording apps, which is
> a genre of application where more bandwidth equals more tracks, more
> plugins, more disk i/o, etc. It's one of the few remaining types of
> apps these days that are *not* just leaving your system idle most of the
> time, and really do want all you can give them. People who are running
> pro audio apps do not have CPU/RAM to burn, ever, even on a fast
> machine! If you are running such programs, and your machine has more to
> give, you want to give it to the apps, not the desktop, no matter how
> *much* more that is.

You have a good point. But as I said, while that might be the default, a
lot of that can be turned off, now.

And if you're /really/ serious about slimming your resource usage, you'd
be running xfce or lighter, not kde or gnome either one, in any version
(that'll still compile on a modern system, anyway, kde1 and gnome1...
might be light enough, if you could get them to build).

> So in general, KDE 4 has turned me away. I'll pass on its Windows Vista
> look and feel, its enormous resource footprint, and the way they made
> keeping any semblance of my current CDE-ish KDE desktop unsupportable.

CDE-ish shouldn't be an issue. You simply customize it the way you did
kde3. It's still possible. Same with Windows Vista look and feel.
That's purely customizable. And if you keep effects off and do a few
other config tweaks, resource usage shouldn't be terribly much more than
3.5.10, either.

FWIW, I'm on both this list and the kde general and kde-linux lists.
kde3 /is/ likely to get harder to run, over time, so your clock is ticking
on it. When you /do/ decide you've had enough, be that tomorrow or two
years from now, do give kde4 an honest shot before giving up on it. It
really /is/ surprisingly flexible, now, and while the defaults are indeed
quite blingy and resource heavy especially on older graphics hardware, as
I said, I know what it's like to not like any default desktop I've ever
seen, and one of the reasons I continued with kde4 despite all those
problems I had, was that I realized that they /would/ pass, kde4 as it
was /would/ get better, and when it was all said and done, I'd be a whole
lot better off remaining with kde where the policy /does/ favor giving the
user the tools to customize, as compared to desktops where customization
options are actively removed as too complex and confusing for the user.
Each desktop has its users comfortable with that approach, but one thing
that you /cannot/ accurately fault kde for is failing to make available
the customization tools for those who do /not/ find default desktops to
their liking. (At least, not after they get going on a version. Early
kde4 was as pretty much everyone agrees now, simply a mess. 4.4 is a
reasonable release candidate, and 4.5 is honestly the first 4.x version I
can without qualms recommend to pretty much anyone and everyone.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Sun, 22 Aug 2010, Duncan wrote:

> FWIW, the type of breakage parallel make issues cause is, AFAIK, always a
> build-time breakage. If it builds fine but fails at run-time, it's not
> due to parallel make, but due to some other reason.

That's excellent to hear! Well, I've enabled '-j3' then on two of my
machines. They're both quad cores, and I'd like to always leave at
least one core completely free. Thanks for the tip.

> I've never met a desktop environment that I liked in default config. FWIW,
> that's one of the reasons I'm a kde guy, as the lack of proper config
> options for gnome drives me crazy.

Even Linus Torvalds has griped about Gnome on that issue (which must
have been very embarrassing for the Gnome devels...). I find myself
using Gnome a lot at work though instead of KDE, because when I have all
those desktop options, it makes me want to tweak them all day, and I
can't help myself. At least with Gnome, my hands are tied, so then I
can get some work done. :)

> Early
> kde4 was as pretty much everyone agrees now, simply a mess. 4.4 is a
> reasonable release candidate, and 4.5 is honestly the first 4.x version I
> can without qualms recommend to pretty much anyone and everyone.)

I'll try it out again sometime... From what I've heard, Phonon actually
works with pro audio apps a lot better than artsd ever did. (Actually
what pro audio apps do with artsd is ignore and bypass it.) The last I
tried KDE 4, I think they were at 4.2, and they didn't even have Konsole
at a point where it didn't feel like a handicapped version with most of
its features stripped. I thought that if they couldn't even make the
terminal emulator work, what's the point. I'll give it another shot
though.

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

On 22 August 2010 01:51, Brent Busby <brent@keycorner.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
>> Can you post the full build log as an attachment or URL?  All I can
>> tell from the current output is that libakode.la is not being produced
>> by something earlier in the build.
>>
>> If this is an as-needed issue, the problem is likely to be that akode
>> was implicitly relying on a dependent library bringing in another
>> library it needs and it no longer does that because of as-needed.
>> I've already seen patches going into the mainline packages to fix such
>> issues (may be worth checking if you have any pending updates).  I hit
>> at least one issue like this when rebuilding after the --as-needed
>> change went in.
>>
>> Adding stuff like --as-needed may help the occasional libpng upgrade,
>> but it means packages may be being built in a way that isn't being
>> tested regularly by its developers.
>
> Okay, here is the whole build log as an attachment.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky

Thanks. Seems I get the same error if I try and emerge akode too and
it's definitely not down to parallel make. The problem is that
libakode.so.2.0.0 (the actual library) is never produced. The last
line of the lib build is:

/bin/sh ../../libtool --tag=CXX --silent --mode=link
x86_64-pc-linux-gnu-g++ -O2 -pipe -march=core2 -ggdb
-mno-tls-direct-seg-refs -fPIC -Wl,-O1 -o libakode.la -rpath
/usr/lib64 -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -version-info 2:0:0 bytebuffer.lo
audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
make[1]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'

If you take out the --silent in the Makefile, you get:

/bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++
-O2 -pipe -march=core2 -ggdb -mno-tls-direct-seg-refs -fPIC -Wl,-O1
-o libakode.la -rpath /usr/lib64 -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -version-info 2:0:0 bytebuffer.lo
audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
(cd .libs && rm -f libakode.so.2 && ln -s libakode.so.2.0.0 libakode.so.2)
(cd .libs && rm -f libakode.so && ln -s libakode.so.2.0.0 libakode.so)
creating libakode.la
(cd .libs && rm -f libakode.la && ln -s ../libakode.la libakode.la)
make[1]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'

So libtool creates the symlinks and the la file, thus satisfying the
Makefile requirements, but never actually invokes gcc to build the
library, so the symlinks are to a non-existent library. The libtool
being used is an old in-tree version:

# ../../libtool --version
ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)

If just 'libtool' is invoked instead,

# libtool --version
libtool (GNU libtool) 2.2.10

/bin/sh libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2
-pipe -march=core2 -ggdb -mno-tls-direct-seg-refs -fPIC -Wl,-O1 -o
libakode.la -rpath /usr/lib64 -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -version-info 2:0:0 bytebuffer.lo
audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
libtool: link: rm -fr .libs/libakode.la .libs/libakode.lai
.libs/libakode.so .libs/libakode.so.2
libtool: link: x86_64-pc-linux-gnu-g++ -shared -nostdlib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/crtbeginS.o .libs/bytebuffer.o
.libs/audiobuffer.o .libs/pluginhandler.o .libs/decoderpluginhandler.o
.libs/resamplerpluginhandler.o .libs/sinkpluginhandler.o
.libs/encoderpluginhandler.o .libs/fast_resampler.o .libs/crossfader.o
.libs/volumefilter.o .libs/localfile.o .libs/mmapfile.o
.libs/wav_decoder.o .libs/auto_sink.o .libs/void_sink.o
.libs/converter.o .libs/buffered_decoder.o .libs/player.o
.libs/magic.o -lpthread /usr/lib64/libltdl.so -ldl
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/../../.. -lstdc++ -lm -lc
-lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/../../../../lib64/crtn.o
-march=core2 -mno-tls-direct-seg-refs -Wl,-O1 -Wl,--no-undefined
-Wl,--allow-shlib-undefined -Wl,-soname -Wl,libakode.so.2 -o
.libs/libakode.so.2.0.0
libtool: link: (cd ".libs" && rm -f "libakode.so.2" && ln -s
"libakode.so.2.0.0" "libakode.so.2")
libtool: link: (cd ".libs" && rm -f "libakode.so" && ln -s
"libakode.so.2.0.0" "libakode.so")
libtool: link: x86_64-pc-linux-gnu-ar cru .libs/libakode.a
.libs/bytebuffer.o .libs/audiobuffer.o .libs/pluginhandler.o
.libs/decoderpluginhandler.o .libs/resamplerpluginhandler.o
.libs/sinkpluginhandler.o .libs/encoderpluginhandler.o
.libs/fast_resampler.o .libs/crossfader.o .libs/volumefilter.o
.libs/localfile.o .libs/mmapfile.o .libs/wav_decoder.o
.libs/auto_sink.o .libs/void_sink.o .libs/converter.o
.libs/buffered_decoder.o .libs/player.o .libs/magic.o
libtool: link: x86_64-pc-linux-gnu-ranlib .libs/libakode.a
libtool: link: ( cd ".libs" && rm -f "libakode.la" && ln -s
"../libakode.la" "libakode.la" )

the right thing is done and the library is built.

# ls .libs
audiobuffer.o crossfader.o libakode.la@
localfile.o resamplerpluginhandler.o
auto_sink.o decoderpluginhandler.o libakode.lai
magic.o sinkpluginhandler.o
buffered_decoder.o encoderpluginhandler.o libakode.so@
mmapfile.o void_sink.o
bytebuffer.o fast_resampler.o libakode.so.2@
player.o volumefilter.o
converter.o libakode.a libakode.so.2.0.0*
pluginhandler.o wav_decoder.o

Note that libakode.so.2.0.0 is now there. On x86_64, I also had to
patch the Makefile to add -fPIC to the CFLAGS otherwise the link
failed with a relocatable symbol error.

I'd be interested to know when this was last known to build, as the
in-tree libtool is clearly buggy.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:

> So libtool creates the symlinks and the la file, thus satisfying the
> Makefile requirements, but never actually invokes gcc to build the
> library, so the symlinks are to a non-existent library. The libtool
> being used is an old in-tree version:
[...]

> # ../../libtool --version
> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>
> If just 'libtool' is invoked instead,
>
> # libtool --version
> libtool (GNU libtool) 2.2.10
[...]

> the right thing is done and the library is built.

That explains why Ladislav said earlier he was able to build the library
manually.

> Note that libakode.so.2.0.0 is now there. On x86_64, I also had to
> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
> failed with a relocatable symbol error.

In general terms (not specific to this particular package), what do you
do in the Makefile to fix that? I've been trying to fix the ebuild for
games-fps/quakeforge on x86_64 (bug #294388), which seems to run into
the same problem trying to build a shared object without -fPIC. There
might be a lot of older packages that need this out there, and I'd like
to know what the basic idea is to fix them myself.

> I'd be interested to know when this was last known to build, as the
> in-tree libtool is clearly buggy.

It worked for me earlier this year on x86_64, but using GCC 4.3, and
before the policy switch to libtool with '--as-needed'. I don't know if
it was the compiler switch or the new libtool options that made the
difference, but I'd imagine it's the latter, since GCC 4.3 and 4.4 are
supposed to act about 99% the same.

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Hey thanks! This fixes it, but I'm not sure how to fix it properly. A
simple solution is to just call libtool directly (everyone should have
it installed), but I don't think it's right:

I just tried it and make file with error:
kangaroo lib # make
make all-am
make[1]: Entering directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
/bin/sh libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++
-O2 -pipe -march=prescott -Wl,-O1 -Wl,--as-needed -o libakode.la
-rpath /usr/lib -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -version-info 2:0:0 bytebuffer.lo
audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crti.o: No such file or
directory
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtbeginS.o: No such file or
directory
i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtendS.o:
No such file or directory
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or
directory
make[1]: *** [libakode.la] Error 1
make[1]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
make: *** [all] Error 2

This is correct, those files does not exist, since I don't have gcc
4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config
and it still throws this error. After rebuilding libtool, it worked
like a charm. So this leads me to think that gcc version is somehow
hardcoded in libtool? But that's just stupid, it can't be.

Do you have any suggestions?

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Sun, Aug 22, 2010 at 7:41 PM, Brent Busby <brent@keycorner.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
>> So libtool creates the symlinks and the la file, thus satisfying the
>> Makefile requirements, but never actually invokes gcc to build the
>> library, so the symlinks are to a non-existent library.  The libtool
>> being used is an old in-tree version:
>
> [...]
>
>> # ../../libtool --version
>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>>
>> If just 'libtool' is invoked instead,
>>
>> # libtool --version
>> libtool (GNU libtool) 2.2.10
>
> [...]
>
>> the right thing is done and the library is built.
>
> That explains why Ladislav said earlier he was able to build the library
> manually.
>
>> Note that libakode.so.2.0.0 is now there.  On x86_64, I also had to
>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
>> failed with a relocatable symbol error.
>
> In general terms (not specific to this particular package), what do you do
> in the Makefile to fix that?  I've been trying to fix the ebuild for
> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the
> same problem trying to build a shared object without -fPIC.  There might be
> a lot of older packages that need this out there, and I'd like to know what
> the basic idea is to fix them myself.
>
>> I'd be interested to know when this was last known to build, as the
>> in-tree libtool is clearly buggy.
>
> It worked for me earlier this year on x86_64, but using GCC 4.3, and before
> the policy switch to libtool with '--as-needed'.  I don't know if it was the
> compiler switch or the new libtool options that made the difference, but I'd
> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99%
> the same.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>

On 22 August 2010 18:41, Brent Busby <brent@keycorner.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
>> So libtool creates the symlinks and the la file, thus satisfying the
>> Makefile requirements, but never actually invokes gcc to build the
>> library, so the symlinks are to a non-existent library.  The libtool
>> being used is an old in-tree version:
>
> [...]
>
>> # ../../libtool --version
>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>>
>> If just 'libtool' is invoked instead,
>>
>> # libtool --version
>> libtool (GNU libtool) 2.2.10
>
> [...]
>
>> the right thing is done and the library is built.
>
> That explains why Ladislav said earlier he was able to build the library
> manually.
>
>> Note that libakode.so.2.0.0 is now there.  On x86_64, I also had to
>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
>> failed with a relocatable symbol error.
>
> In general terms (not specific to this particular package), what do you do
> in the Makefile to fix that?  I've been trying to fix the ebuild for
> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the
> same problem trying to build a shared object without -fPIC.  There might be
> a lot of older packages that need this out there, and I'd like to know what
> the basic idea is to fix them myself.
>

It depends a lot on the build. With akode, I just hacked it into
CXXFLAGS in the
already-generated Makefile but to do it properly you'd need to patch
akode/lib/Makefile.am
to set AM_CXXFLAGS="-fPIC".

>> I'd be interested to know when this was last known to build, as the
>> in-tree libtool is clearly buggy.
>
> It worked for me earlier this year on x86_64, but using GCC 4.3, and before
> the policy switch to libtool with '--as-needed'.  I don't know if it was the
> compiler switch or the new libtool options that made the difference, but I'd
> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99%
> the same.
>

The problem is that it never even calls gcc. From running strace on
the libtool call:

# cat /tmp/strace |grep 'execve('|awk '{print $2}'|sort|uniq
execve("/bin/expr",
execve("/bin/grep",
execve("/bin/ln",
execve("/bin/rm",
execve("/bin/sed",
execve("/bin/sh",
execve("/bin/tr",

No gcc. I've been through the libtool script quite a bit (with the
help of adding --debug to the call) but can't stop why it's choosing
not to call gcc to do the actual link.

> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>



--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

On 22 August 2010 19:26, Ladislav Laska <ladislav.laska@gmail.com> wrote:
> Hey thanks! This fixes it, but I'm not sure how to fix it properly. A
> simple solution is to just call libtool directly (everyone should have
> it installed), but I don't think it's right:
>
> I just tried it and make file with error:
> kangaroo lib # make
> make  all-am
> make[1]: Entering directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
> /bin/sh libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++
> -O2 -pipe -march=prescott   -Wl,-O1 -Wl,--as-needed -o libakode.la
> -rpath /usr/lib -no-undefined -Wl,--no-undefined
> -Wl,--allow-shlib-undefined -version-info 2:0:0  bytebuffer.lo
> audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
> resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
> fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
> mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
> buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
> i686-pc-linux-gnu-g++:
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crti.o: No such file or
> directory
> i686-pc-linux-gnu-g++:
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtbeginS.o: No such file or
> directory
> i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtendS.o:
> No such file or directory
> i686-pc-linux-gnu-g++:
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or
> directory
> make[1]: *** [libakode.la] Error 1
> make[1]: Leaving directory
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
> make: *** [all] Error 2
>
> This is correct, those files does not exist, since I don't have gcc
> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config
> and it still throws this error. After rebuilding libtool, it worked
> like a charm. So this leads me to think that gcc version is somehow
> hardcoded in libtool? But that's just stupid, it can't be.
>

It is. Re-emerging libtool fixed the same issue for me.

libtool is rarely used directly like this. Usually a libtool script
is generated for the particular setup. This is why you don't see the
same libtool failure in normal portage builds.

The one in akode is generated by admin/ltmain.sh

> Do you have any suggestions?
>
> Regards Ladislav Laska
> S pozdravem Ladislav Laska
> ---
> xmpp/jabber: ladislav.laska@jabber.cz
>
>
>
> On Sun, Aug 22, 2010 at 7:41 PM, Brent Busby <brent@keycorner.org> wrote:
>> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>>
>>> So libtool creates the symlinks and the la file, thus satisfying the
>>> Makefile requirements, but never actually invokes gcc to build the
>>> library, so the symlinks are to a non-existent library.  The libtool
>>> being used is an old in-tree version:
>>
>> [...]
>>
>>> # ../../libtool --version
>>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>>>
>>> If just 'libtool' is invoked instead,
>>>
>>> # libtool --version
>>> libtool (GNU libtool) 2.2.10
>>
>> [...]
>>
>>> the right thing is done and the library is built.
>>
>> That explains why Ladislav said earlier he was able to build the library
>> manually.
>>
>>> Note that libakode.so.2.0.0 is now there.  On x86_64, I also had to
>>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
>>> failed with a relocatable symbol error.
>>
>> In general terms (not specific to this particular package), what do you do
>> in the Makefile to fix that?  I've been trying to fix the ebuild for
>> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the
>> same problem trying to build a shared object without -fPIC.  There might be
>> a lot of older packages that need this out there, and I'd like to know what
>> the basic idea is to fix them myself.
>>
>>> I'd be interested to know when this was last known to build, as the
>>> in-tree libtool is clearly buggy.
>>
>> It worked for me earlier this year on x86_64, but using GCC 4.3, and before
>> the policy switch to libtool with '--as-needed'.  I don't know if it was the
>> compiler switch or the new libtool options that made the difference, but I'd
>> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99%
>> the same.
>>
>> --
>> + Brent A. Busby         + "We've all heard that a million monkeys
>> + UNIX Systems Admin     +  banging on a million typewriters will
>> + University of Chicago  +  eventually reproduce the entire works of
>> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
>> + James Franck Institute +  we know this is not true." -Robert Wilensky
>>
>>
>
>



--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

On 22 August 2010 20:19, Dr Andrew John Hughes
<gnu_andrew@member.fsf.org> wrote:
> On 22 August 2010 18:41, Brent Busby <brent@keycorner.org> wrote:
>> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>>
>>> So libtool creates the symlinks and the la file, thus satisfying the
>>> Makefile requirements, but never actually invokes gcc to build the
>>> library, so the symlinks are to a non-existent library.  The libtool
>>> being used is an old in-tree version:
>>
>> [...]
>>
>>> # ../../libtool --version
>>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>>>
>>> If just 'libtool' is invoked instead,
>>>
>>> # libtool --version
>>> libtool (GNU libtool) 2.2.10
>>
>> [...]
>>
>>> the right thing is done and the library is built.
>>
>> That explains why Ladislav said earlier he was able to build the library
>> manually.
>>
>>> Note that libakode.so.2.0.0 is now there.  On x86_64, I also had to
>>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
>>> failed with a relocatable symbol error.
>>
>> In general terms (not specific to this particular package), what do you do
>> in the Makefile to fix that?  I've been trying to fix the ebuild for
>> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the
>> same problem trying to build a shared object without -fPIC.  There might be
>> a lot of older packages that need this out there, and I'd like to know what
>> the basic idea is to fix them myself.
>>
>
> It depends a lot on the build.  With akode, I just hacked it into
> CXXFLAGS in the
> already-generated Makefile but to do it properly you'd need to patch
> akode/lib/Makefile.am
> to set AM_CXXFLAGS="-fPIC".
>
>>> I'd be interested to know when this was last known to build, as the
>>> in-tree libtool is clearly buggy.
>>
>> It worked for me earlier this year on x86_64, but using GCC 4.3, and before
>> the policy switch to libtool with '--as-needed'.  I don't know if it was the
>> compiler switch or the new libtool options that made the difference, but I'd
>> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99%
>> the same.
>>
>
> The problem is that it never even calls gcc.  From running strace on
> the libtool call:
>
> # cat /tmp/strace |grep 'execve('|awk '{print $2}'|sort|uniq
> execve("/bin/expr",
> execve("/bin/grep",
> execve("/bin/ln",
> execve("/bin/rm",
> execve("/bin/sed",
> execve("/bin/sh",
> execve("/bin/tr",
>
> No gcc.  I've been through the libtool script quite a bit (with the
> help of adding --debug to the call) but can't stop why it's choosing
> not to call gcc to do the actual link.
>

It's not the libtool version but something to do with how the build is
generating the script.
Using the system 2.2.10 works but altering the build (comment out dnl
AM_PROG_LIBTOOL and add LT_INIT in admin/acinclude.m4.in then run make
-f admin/Makefile.common; libtoolize and configure again) to generate
a 2.2.10 script rather than 1.5 still fails.

>> --
>> + Brent A. Busby         + "We've all heard that a million monkeys
>> + UNIX Systems Admin     +  banging on a million typewriters will
>> + University of Chicago  +  eventually reproduce the entire works of
>> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
>> + James Franck Institute +  we know this is not true." -Robert Wilensky
>>
>>
>
>
>
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>



--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:

[...]
>> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or
>> directory
>> make[1]: *** [libakode.la] Error 1
>> make[1]: Leaving directory
>> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
>> make: *** [all] Error 2
>>
>> This is correct, those files does not exist, since I don't have gcc
>> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config
>> and it still throws this error. After rebuilding libtool, it worked
>> like a charm. So this leads me to think that gcc version is somehow
>> hardcoded in libtool? But that's just stupid, it can't be.
>>
>
> It is. Re-emerging libtool fixed the same issue for me.
>
> libtool is rarely used directly like this. Usually a libtool script
> is generated for the particular setup. This is why you don't see the
> same libtool failure in normal portage builds.
>
> The one in akode is generated by admin/ltmain.sh

I may not have understood correctly, but I tried re-emerging the system
package for libtool, and it didn't help with the akode problem. It
sounds like you're saying that the source tarball for akode ships with
its own bundled (and old) version of libtool, but if it would just use
the newer version provided by the system, the build would succeed.

How did you fix that by re-emerging the system libtool though?

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

No.

The akode ships its own, old, version (generated specifically for
akode) which is buggy. We have tried to hack the makefile to use
system version of libtool - this works most of the time (in case gcc
was updated after libtool was merged, in my case libtool failed
because of it - in this case, re-emergin libtool fixed the problem and
the hack worked).

However, I don't know where is the problem and neither Andrew seems to know.

As Andrew found out, it seems to be a bug in configuration, since
regenerating libtool script does not help (I'm not an expert, but it
seems that if you run system's libtool, it does not read scripts in
project directory and 'just does something') - that's why hack works
and anything else doesn't. Unfortunately, we can't use this hack in
ebuild, since it requires libtool rebuild in most cases.

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Fri, Aug 27, 2010 at 8:41 PM, Brent Busby <brent@keycorner.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
> [...]
>>>
>>> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or
>>> directory
>>> make[1]: *** [libakode.la] Error 1
>>> make[1]: Leaving directory
>>> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
>>> make: *** [all] Error 2
>>>
>>> This is correct, those files does not exist, since I don't have gcc
>>> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config
>>> and it still throws this error. After rebuilding libtool, it worked
>>> like a charm. So this leads me to think that gcc version is somehow
>>> hardcoded in libtool? But that's just stupid, it can't be.
>>>
>>
>> It is. Re-emerging libtool fixed the same issue for me.
>>
>> libtool is rarely used directly like this.  Usually a libtool script
>> is generated for the particular setup.  This is why you don't see the
>> same libtool failure in normal portage builds.
>>
>> The one in akode is generated by admin/ltmain.sh
>
> I may not have understood correctly, but I tried re-emerging the system
> package for libtool, and it didn't help with the akode problem.  It sounds
> like you're saying that the source tarball for akode ships with its own
> bundled (and old) version of libtool, but if it would just use the newer
> version provided by the system, the build would succeed.
>
> How did you fix that by re-emerging the system libtool though?
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>

Ladislav Laska posted on Fri, 27 Aug 2010 22:28:54 +0200 as excerpted:

> Unfortunately, we can't use this hack in ebuild, since it requires
> libtool rebuild in most cases.

No longer a kde3 user, but...

One thing you /could/ do (maybe it's there already?) is to put something
in the messages about trying a libtool remerge if merging akode fails
(maybe if it fails with a specific error), before trying anything else.

I've seen other ebuilds do that...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Sat, 28 Aug 2010, Duncan wrote:

> Ladislav Laska posted on Fri, 27 Aug 2010 22:28:54 +0200 as excerpted:
>
>> Unfortunately, we can't use this hack in ebuild, since it requires
>> libtool rebuild in most cases.
>
> No longer a kde3 user, but...
>
> One thing you /could/ do (maybe it's there already?) is to put something
> in the messages about trying a libtool remerge if merging akode fails
> (maybe if it fails with a specific error), before trying anything else.
>
> I've seen other ebuilds do that...

The thing is, I'm not sure in what circumstances I'd have to be in for
that to work for me. I've already tried just remerging libtool. Would
I have to remerge gcc too? (This machine has always used gcc 4.4.)

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Well, you need to re-emerge libtool only if you have upgraded gcc
(even 4.4.3->4.4.4). Tomorrow I will try to commit some ebuild for
testing, to have at least hacked & working akode ebuild until we
figure out the correct way.

On 8/28/10, Brent Busby <brent@keycorner.org> wrote:
> On Sat, 28 Aug 2010, Duncan wrote:
>
>> Ladislav Laska posted on Fri, 27 Aug 2010 22:28:54 +0200 as excerpted:
>>
>>> Unfortunately, we can't use this hack in ebuild, since it requires
>>> libtool rebuild in most cases.
>>
>> No longer a kde3 user, but...
>>
>> One thing you /could/ do (maybe it's there already?) is to put something
>> in the messages about trying a libtool remerge if merging akode fails
>> (maybe if it fails with a specific error), before trying anything else.
>>
>> I've seen other ebuilds do that...
>
> The thing is, I'm not sure in what circumstances I'd have to be in for
> that to work for me. I've already tried just remerging libtool. Would
> I have to remerge gcc too? (This machine has always used gcc 4.4.)
>
> --
> + Brent A. Busby + "We've all heard that a million monkeys
> + UNIX Systems Admin + banging on a million typewriters will
> + University of Chicago + eventually reproduce the entire works of
> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
> + James Franck Institute + we know this is not true." -Robert Wilensky
>
>


--
Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz

On Sat, 28 Aug 2010, Ladislav Laska wrote:

> Well, you need to re-emerge libtool only if you have upgraded gcc
> (even 4.4.3->4.4.4). Tomorrow I will try to commit some ebuild for
> testing, to have at least hacked & working akode ebuild until we
> figure out the correct way.

Did anyone ever find out how to get akode to build on gcc 4.4, even with
a dumb kludge?

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Hello,

no, I don't think so. I've even tested it on another machine and my
hack seemed not efficient. Still have no clue :-(

Anyway, I hope it may be fixed in trinity, and kde-trinity 3.5.12
should be released in about 3 weeks, so we shall see then.

(Since trinity is rebuilding some of the scripts involved, I suspect
using up-to-date versions, the chance is reasonable high)

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Fri, Sep 10, 2010 at 8:06 PM, Brent Busby <brent@keycorner.org> wrote:
> On Sat, 28 Aug 2010, Ladislav Laska wrote:
>
>> Well, you need to re-emerge libtool only if you have upgraded gcc (even
>> 4.4.3->4.4.4). Tomorrow I will try to commit some ebuild for testing, to
>> have at least hacked & working akode ebuild until we figure out the correct
>> way.
>
> Did anyone ever find out how to get akode to build on gcc 4.4, even with a
> dumb kludge?
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>

On Fri, 10 Sep 2010, Ladislav Laska wrote:

> no, I don't think so. I've even tested it on another machine and my
> hack seemed not efficient. Still have no clue :-(
>
> Anyway, I hope it may be fixed in trinity, and kde-trinity 3.5.12
> should be released in about 3 weeks, so we shall see then.
>
> (Since trinity is rebuilding some of the scripts involved, I suspect
> using up-to-date versions, the chance is reasonable high)

Will users who are currently using kde-sunset have to migrate to Trinity
at some point? It sounds like it's a fairly monolithic KDE build. Will
it respect Gentoo's USE flags, or individual KDE packages that we
already have installed? There may be some potential for some users to
have to pull out there entire KDE install to replace it with Trinity,
unless we're going to have the old ebuilds in the overlay as well.

(The reason I worry about this is because the existing ebuilds are
working find on my GCC 4.3 machines.)

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

I don't think so. Timothy Pearson promised 3.5.12 will be split like
.10, so we will be able to use all our split ebuilds and dependecies,
with only minor adjustments (tqt interface, and so on), and I guess he
will help out if we need some mor splitting (I was thinking app-based,
instead of module-based, so we wouldn't need partial unpacking in
eclass - but I'm not sure if it is possible and will get more info
about that). Anyway, anyone who doesn't like .12 will be able to mask
it and keep original .10 release.

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Fri, Sep 10, 2010 at 9:11 PM, Brent Busby <brent@keycorner.org> wrote:
> On Fri, 10 Sep 2010, Ladislav Laska wrote:
>
>> no, I don't think so. I've even tested it on another machine and my hack
>> seemed not efficient. Still have no clue :-(
>>
>> Anyway, I hope it may be fixed in trinity, and kde-trinity 3.5.12 should
>> be released in about 3 weeks, so we shall see then.
>>
>> (Since trinity is rebuilding some of the scripts involved, I suspect using
>> up-to-date versions, the chance is reasonable high)
>
> Will users who are currently using kde-sunset have to migrate to Trinity at
> some point?  It sounds like it's a fairly monolithic KDE build.  Will it
> respect Gentoo's USE flags, or individual KDE packages that we already have
> installed?  There may be some potential for some users to have to pull out
> there entire KDE install to replace it with Trinity, unless we're going to
> have the old ebuilds in the overlay as well.
>
> (The reason I worry about this is because the existing ebuilds are working
> find on my GCC 4.3 machines.)
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>

It's been a long time since I last checked on the kde-sunset overlay, so
I tried again to build it on a machine that had no existing KDE 3
install. This was the same machine that was having trouble several
months ago compiling akode.

It still had the same build error with akode as before, which I remember
many people had tried to diagnose. I gave up on akode, and disabled
arts as well. On a machine with a modern alsa implementation, it's
probably better to do without all these sound frontends anyway. So I'm
installing with direct alsa support.

That was going well, but there's a much more serious problem:

The main Gentoo Portage has now upgraded OpenSSL to 1.0.0d. The
kde-sunset overlay seems to get itself confused, trying to install
0.9.8r in a slot, but then not using it, and trying to link to 1.0.0d.
The build fails while compiling kde-base/kdelibs-3.5.10-r6:

ksslsettings.cc: In member function 'QString
KSSLSettings::getCipherList()':
ksslsettings.cc:157: error: no matching function for call to
'KOpenSSLProxy::sk_num(_STACK*)'
./kopenssl.h:538: note: candidates are: int KOpenSSLProxy::sk_num(int*)
ksslsettings.cc:159: error: 'class KOpenSSLProxy' has no member named
'sk_value'
make[5]: *** [ksslcertificate.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
kssl.cc: In member function 'void KSSL::setPeerInfo()':
kssl.cc:616: error: 'class KOpenSSLProxy' has no member named 'sk_dup'
make[5]: *** [ksslsettings.lo] Error 1
make[5]: *** [kssl.lo] Error 1
make[5]: Leaving directory
`/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kio/kssl'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kio/kssl'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kio/kssl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kio'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10'
make: *** [all] Error 2
emake failed


Is there a way to make the overlay build correctly with the new OpenSSL?

--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky