Summary: | sys-devel/libtool has #!/bin/bash yet uses $(SHELL) to call it | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Failing build log |
Description
Michał Górny
![]() ![]() ![]() ![]() The catch lies most likely in one of ltmain.sh lines: : ${SHELL="${CONFIG_SHELL-/bin/sh}"} /usr/bin/libtool inherits its shell from PMS - it's one that was used at the time of generation. if your /bin/sh sucks, then autoconf should have detected that and used /bin/bash. so why didn't libtar do that ? please post a full build log showing the problem. libtar seems to work for me. $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jan 14 13:36 /bin/sh -> dash $ ebuild libtar-1.2.11-r5.ebuild clean unpack prepare configure compile ... /bin/bash ../libtool --mode=compile x86_64-pc-linux-gnu-gcc -O2 -march=amdfam10 -pipe -g -Wimplicit-function-declaration -I. -I.. -I. -I../compat -I../listhash -DCPPFLAGS_TEST -c -o append.lo append.c ... Created attachment 335640 [details]
Failing build log
I can reproduce it with -r4, the version which was in gx86 one year ago, when this bug was filed. libtar r5 includes a lot of patches to the build system. they have their own hand written Makefile.in instead of using automake. if the only package you can hit this problem with is libtar and it doesn't use automake, then i don't think it's worth investigating. i don't see a bug w/libtool here. libtar r5 includes a lot of patches to the build system. they have their own hand written Makefile.in instead of using automake. if the only package you can hit this problem with is libtar and it doesn't use automake, then i don't think it's worth investigating. i don't see a bug w/libtool here. |