On Wed, Mar 16, 2011 at 2:19 PM, Brent Busby wrote:
> On Wed, 16 Mar 2011, Alex Schuster wrote:
>
> Brent Busby writes:
>>
>> 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 no
On Wed, 16 Mar 2011, Alex Schuster wrote:
Brent Busby writes:
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 compili
Brent Busby writes:
> 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:
[...]
>
On Wed, Mar 16, 2011 at 2:31 AM, Brent Busby wrote:
> 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'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, whi
On Wed, Mar 16, 2011 at 2:39 AM, Brent Busby wrote:
> Looking back through the list archives, it looks like unmasking the -r10
> version of kdelibs and the -r1 version of kcontrol are recommended to fix
> this, however, some in the same thread have said that this breaks some
> functions of kio's
Looking back through the list archives, it looks like unmasking the -r10
version of kdelibs and the -r1 version of kcontrol are recommended to
fix this, however, some in the same thread have said that this breaks
some functions of kio's being able to use sftp:// URL's (e.g. in
Konqueror). What
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-
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.
(Sinc
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 scrip
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 ou
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 wrote:
> On Sat, 28 Aug 2010, Duncan 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 t
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 abo
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,
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
On 22 August 2010 20:19, Dr Andrew John Hughes
wrote:
> On 22 August 2010 18:41, Brent Busby 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 t
On 22 August 2010 19:26, Ladislav Laska 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 li
On 22 August 2010 18:41, Brent Busby 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.
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
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:
[.
On 22 August 2010 01:51, Brent Busby 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
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 t
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
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
On 21 August 2010 18:37, Brent Busby 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=8182796e790caf6a0c9
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 fin
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 act
28 matches
Mail list logo
