| Summary: | gnuconfig fails with USE=uclibc and sys-devel/libtool-1.5.2-r5 (and QA faults) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Daniel Black (RETIRED) <dragonheart> |
| Component: | Current packages | Assignee: | Aron Griffis (RETIRED) <agriffis> |
| Status: | RESOLVED INVALID | ||
| Severity: | blocker | CC: | embedded |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | gnuconfig-test.patch | ||
|
Description
Daniel Black (RETIRED)
2004-07-19 01:34:57 UTC
* Using GNU config files from /usr/share/gnuconfig
* Can't read /usr/share/gnuconfig//var/tmp/portage/libtool-1.5.2-r5/work,
^ Key thing about this.
Same thing happens with misc other ebuild where we want to use gnuconfig_update <param> such as module-init-tools or any ebuild using the following gnuconfig_update ${WORKDIR}
This probably means the gnuconfig.eclass could probably use some logic rereview.
I see that this was entered on the 19th, but I'm fairly certain this bug was fixed a couple days ago. Mind checking? No sorry - just did resync and emerge and got the same result. Have changed portage config to http://oc12.net/~solar/gentoo/uclibc/x86/etc.portage-20040719.tgz. Here is what it does on my system: * Using GNU config files from /usr/share/libtool * Updating libtool-1.3.5/config.sub [ ok ] * Updating libtool-1.5.2/libltdl/config.sub [ ok ] * Updating libtool-1.5.2/config.sub [ ok ] * Updating libtool-1.3.5/config.guess [ ok ] * Updating libtool-1.5.2/libltdl/config.guess [ ok ] * Updating libtool-1.5.2/config.guess [ ok ] I'm not using uclibc though. Please try this: grep Header /usr/portage/eclass/gnuconfig.eclass My output is # $Header: /var/cvsroot/gentoo-x86/eclass/gnuconfig.eclass,v 1.23 2004/07/13 21:43:28 agriffis Exp $ uCsimple portage # grep Header /usr/portage/eclass/gnuconfig.eclass # $Header: /var/cvsroot/gentoo-x86/eclass/gnuconfig.eclass,v 1.23 2004/07/13 21:43:28 agriffis Exp $ I know this might seem odd to you but it's what's happening. This may provide you some insight to the "why" uCsimple libtool # ls -l /usr/share/libtool/ total 192 lrwxrwxrwx 1 root root 25 Jul 3 03:45 config.guess -> ../gnuconfig/config.guess lrwxrwxrwx 1 root root 23 Jul 3 03:45 config.sub -> ../gnuconfig/config.sub drwxr-xr-x 2 root root 4096 Jul 3 03:45 libltdl -rw-r--r-- 1 root root 185428 Jul 3 03:45 ltmain.sh ------------------------ The function gnuconfig_findnewest() returns both /usr/share/libtool in a uclibc and a glibc environment. [ ! -r /usr/share/libtool/config.sub ] && echo ok Also seem to yeild the same results. What makes this bug even odder to me is that I just made it into a script and run it from comamnd line and all seems kosher. I'm stumped atm on this one atm ;/ Created attachment 36158 [details, diff]
gnuconfig-test.patch
How about trying the attached patch? It's a shot in the dark really.
* Generate ltmain.sh ...
gnuconfig_update arg1 = [/var/tmp/portage/libtool-1.5.2-r5/work]
* Using GNU config files from /usr/share/libtool
Ok great libtool merged.
-----------------------------------------------------------
Now let's try that module-init-tools one.
First run as is. (FAILS)
Then with
Index: module-init-tools-3.0-r2.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/sys-apps/module-init-tools/module-init-tools-3.0-r2.ebuild,v
retrieving revision 1.6
diff -u -b -B -w -p -r1.6 module-init-tools-3.0-r2.ebuild
--- module-init-tools-3.0-r2.ebuild 13 Jul 2004 21:55:26 -0000 1.6
+++ module-init-tools-3.0-r2.ebuild 26 Jul 2004 03:53:19 -0000
@@ -51,13 +51,12 @@ src_unpack() {
rm -f missing
export WANT_AUTOMAKE=1.6
automake --add-missing
-}
-
-src_compile() {
# If running mips64, we need updated configure data
- gnuconfig_update
+ gnuconfig_update ${WORKDIR}
+}
+src_compile() {
local myconf=
filter-flags -fPIC
* Applying modutils-2.4.22-no-above-below.patch... [ ok ] * Applying module-init-tools-0.9.15-legacy-modext-support.patch... [ ok ] * Applying generate-modprobe-assume-kernel.patch... [ ok ]configure.in: installing `./missing'
gnuconfig_update arg1 = [/var/tmp/portage/module-init-tools-3.0-r2/work]
* Using GNU config files from /usr/share/libtool
* Updating module-init-tools-3.0/config.sub [ ok ] * Updating modutils-2.4.26/config.sub [ ok ] * Updating module-init-tools-3.0/config.guess [ ok ] * Updating modutils-2.4.26/config.guess
---
Ok great so now module-init-tools merges.
ok so..
From looking at this patch it does seem to actually do anything other than print
your **argv array to the command line so I reverted it and rebuilt
module-init-utils a few times and umm.. shoot me.. It no longer seems to be a problem. Anyway gnuconfig_update ${WORKDIR} seems to work like a charm now.
dragonheart can you confirm this please?
solar, my patch made one other change, look closely ;-) I don't know if that part has anything to do with it, though. I was just guessing that for some reason in the uclibc environment there might be bogus characters on the front of $1 prior to the /. I couldn't see any other reason for it to be failing. + for ((x = 1; x <= $#; x = x + 1)); do
+ echo "gnuconfig_update arg$x = [${!x}]"
+ done
Unless I'm getting blind/dense must be blind cuz this is all I see it doing.
What am I missing?
- if [[ $1 == /* ]]; then + if [[ $1 == */* ]]; then Ok, this is assigned to me, and even with my change it appears to work. I'm marking resolved unless one of you re-opens with more information. |