| Summary: | app-arch/xz-utils-5.0.4-r1: Abort when shared libraries cannot be build | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=934370 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
emerge.info ppc64-emerge.info |
||
|
Description
Dennis Schridde
2013-01-05 18:12:35 UTC
Created attachment 334556 [details]
build.log
Created attachment 334558 [details]
emerge.info
Created attachment 334560 [details]
ppc64-emerge.info
NOTE: This is in a cross-compilation environment with CBUILD=x86_64 and CHOST=powerpc64.
Found the issue: checking whether the /mnt/ppc64/etc/crossdev/gcc -std=gnu99 linker (/mnt/ppc64/etc/crossdev/ld -m elf64ppc) supports shared libraries... no Is there a way for portage to force configure to abort in this case? The bad linker (wrong value for LD) was my fault. Would be nice of portage could somehow make econf/autoconf/configure bail out early in this case, i.e. force shared or static linking. that makes no sense. there are targets which don't support dynamic linking. (In reply to comment #6) > that makes no sense. there are targets which don't support dynamic linking. But in the case of xz-utils, it obviously requires shared-object support. So IMO it would make sense... (In reply to comment #7) no, it doesn't. it depends entirely on the target whether a shared lib is used. (In reply to comment #8) > no, it doesn't. it depends entirely on the target whether a shared lib is > used. Apparently the app-arch/xz-utils-5.0.4-r1 ebuild calls gen_usr_ldscript, which needs a shared library? (In reply to comment #9) for some targets, yes. but not all. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=25171b1f5847b461145906ac2bc230c462f62c21 commit 25171b1f5847b461145906ac2bc230c462f62c21 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-15 22:41:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-15 22:45:26 +0000 app-arch/xz-utils: workaround libtool bug preventing shared library build * Fix detection of `file` with libtool-2.5.0 (which xz-5.4.7, xz.5.6.2 had dist tarballs created with). This only affects some targets. See bug #934370. See https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=9a4a02615c9e7cbcfd690ed31874822a7d6aaea2. * Add a sanity check for targets which support shared libraries where we verify liblzma.so is in the image. Use tc-is-static-only to handle the concern from bug #450436. Bug: https://bugs.gentoo.org/450436 Closes: https://bugs.gentoo.org/934370 Signed-off-by: Sam James <sam@gentoo.org> app-arch/xz-utils/xz-utils-5.4.7-r1.ebuild | 155 ++++++++++++++++++++++ app-arch/xz-utils/xz-utils-5.6.2-r1.ebuild | 203 +++++++++++++++++++++++++++++ app-arch/xz-utils/xz-utils-9999.ebuild | 15 +++ 3 files changed, 373 insertions(+) We've actually had tc-is-static-only since... commit a1defa9181f4284b81ec27a87b6d6eaf2bcba1cf Author: Fabian Groffen <grobian@gentoo.org> Date: Sun May 24 07:25:48 2009 +0000 |
