Summary: | sys-devel/gettext-0.14.1 fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Nerone <mike> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | deefster, gentoo, griffon26, ndimiduk, sascha-gentoo-bugzilla |
Priority: | High | ||
Version: | 2004.3 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mike Nerone
2005-03-14 22:52:43 UTC
do the tests pass if you go into the directory and run `make check` yourself ? Currently testing that and testing using portage with sandbox disabled. Will post both results in a few minutes. Manual 'make check' is successful. Portage fails for every combination of FEATURES I've tried (including explicitly disabling all FEATURES except 'test'). Hmm...doesn't appear to be sandbox-related? *** Bug 71029 has been marked as a duplicate of this bug. *** same problem on sparc. manually running 'make check' works fine. I don't know too much about the bug, but would setting LD_LIBRARY_PATH when doing these tests fix it? Same problem is present in gettext-0.14.2 Something is going wrong in files like this one: gettext-0.14.2/autoconf-lib-link/tests/tstdir/rp3abh-build4/configure configure.ac specifies AC_LIB_LINKFLAGS([rpathz]) which in the unsuccessful case results in: configure:3030: checking how to link with librpathz configure:3419: result: /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix3/lib/librpathz.so -lrpathy -lrpathx -lc -Wl,-rpath -Wl,/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix3/lib and in the successful case in: configure:3030: checking how to link with librpathz configure:3419: result: /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix3/lib/librpathz.so -L/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib -L/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix2/lib /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix2/lib/librpathy.so /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib/librpathx.so -lc -Wl,-rpath -Wl,/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix3/lib -Wl,-rpath -Wl,/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib -Wl,-rpath -Wl,/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix2/lib To get to a point from where to debug: 1) emerge gettext and let it fail 2) edit work/gettext-0.14.2/autoconf-lib-link/tests/Makefile and modify the definition of TESTS to look like this: TESTS = rpath-3abh 3) modify work/gettext-0.14.2/autoconf-lib-link/tests/rpath-3_b to not throw away its tmpfiles at the end 4) either run make check manually from work/gettext-0.14.2/autoconf-lib-link/tests or run ebuild /usr/portage/sys-devel/gettext/gettext-0.14.2.ebuild test 5) now the interesting files should be available in work/gettext-0.14.2/autoconf-lib-link/tests/tstdir/rp3abh-build4 There's a difference in generated .la files. The ones that work have dependencies like this: dependency_libs=' -R/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib -L/var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib/librpathx.la -lc' The ones that don't, have stuff like this: dependency_libs=' /var/tmp/portage/gettext-0.14.2/work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix1/lib/librpathx.la -lc' These are the files I'm talking about: work/gettext-0.14.2/autoconf-lib-link/tests/rp3abh-prefix?/lib/librpath?.la I'm not sure what to do next. 0.14.4 work ? it passed `make check` for me ... Yup, works for me. ok, good enough for me :P If the fix for this problem comes in a newer (and, I might add, as yet unstable) ebuild, I (speaking as the reporter) don't think it's accurate to resolve this bug as WORKSFORME, thus implying that "all attempts at reproducing this bug were futile," as well as implying that I'm crazy (whereas I can assure you that only the latter of these two is the case). :P This should be resolved FIXED. You're not crazy; I also have 9 tests fail on my ppc-macos install. To get around the bug, I installed with FEATURES=-makecheck" and haven't not had any side-effect issues that I'm aware of. It's been a while since ran the install so I don't recall if my failures are identical to yours. I'll run it again this weekend and compare. the reason i didnt mark it as FIXED is because our current stable gettext is still 'broken' ... WORKSFORME can be interpreted different ways Gotcha...I was just quoting the official definition at http://bugs.gentoo.org/bug_status.html, although I understand that the real world doesn't always match the docs. ;) Just going by that page, I would think that RESOLVED FIX is appropriate here, but not yet CLOSED (until it gets marked stable - i.e. "ships"). It seems not many on this Bugzilla follow that convention, though...most of the fixed bugs never get CLOSED. Oh well...digression over. I don't care that much. :P *** Bug 94737 has been marked as a duplicate of this bug. *** |