FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Desktop

 
 
LinkBack Thread Tools
 
Old 08-22-2010, 05:41 PM
Brent Busby
 
Default kde-sunset: new akode build problems

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
 
Old 08-22-2010, 06:26 PM
Ladislav Laska
 
Default kde-sunset: new akode build problems

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
>
>
 
Old 08-22-2010, 07:19 PM
Dr Andrew John Hughes
 
Default kde-sunset: new akode build problems

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
 
Old 08-22-2010, 07:31 PM
Dr Andrew John Hughes
 
Default kde-sunset: new akode build problems

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
 
Old 08-22-2010, 07:47 PM
Dr Andrew John Hughes
 
Default kde-sunset: new akode build problems

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
 
Old 08-27-2010, 06:41 PM
Brent Busby
 
Default kde-sunset: new akode build problems

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
 
Old 08-27-2010, 08:28 PM
Ladislav Laska
 
Default kde-sunset: new akode build problems

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
>
>
 
Old 08-28-2010, 12:30 AM
Duncan
 
Default kde-sunset: new akode build problems

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
 
Old 08-28-2010, 05:00 AM
Brent Busby
 
Default kde-sunset: new akode build problems

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
 
Old 08-28-2010, 08:43 PM
Ladislav Laska
 
Default kde-sunset: new akode build problems

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
 

Thread Tools




All times are GMT. The time now is 12:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org