[arch-dev-public] grep breakage in staging
Hey, Long story short, udev wouldn't build against staging and bailed with a really strange library-not-found error. I was able to reduce it down to libtool flaking out because it hardcodes paths to grep: 92 # A grep program that handles long lines. 93 GREP="/bin/grep" 94 95 # An ERE matcher. 96 EGREP="/bin/grep -E" 97 98 # A literal string matcher. 99 FGREP="/bin/grep -F" And sure enough, the rebuild of grep moved the binaries out of /bin: - ./configure --prefix=/usr --bindir=/bin --without-included-regex + ./configure --prefix=/usr --without-included-regex Do we: * revert the ./configure change? * farm symlinks? * tell libtool upstream to go to hell? (please?) d
On 07.02.2012 20:23, Dave Reisner wrote:
Hey,
Long story short, udev wouldn't build against staging and bailed with a really strange library-not-found error. I was able to reduce it down to libtool flaking out because it hardcodes paths to grep:
92 # A grep program that handles long lines. 93 GREP="/bin/grep" Do we: * tell libtool upstream to go to hell? (please?)
+1 $PATH is there for a reason and if they think it might not contain /bin, they can just add it at the end. If the reason is "performance" (I did hear that one somewhere already) they shouldn't use a shell script. Forking is worse than a few (likely cached) file system lookups. Until it's fixed upstream, I suggest to just patch it. PS: Just saw that the variables for gcc, strip, ln -s, ar, as, printf, tr and objdump do not contain a hardcoded path but just the executable name. Go figure. -- Florian Pritz
On Tue, Feb 07, 2012 at 08:49:36PM +0100, Florian Pritz wrote:
On 07.02.2012 20:23, Dave Reisner wrote:
Hey,
Long story short, udev wouldn't build against staging and bailed with a really strange library-not-found error. I was able to reduce it down to libtool flaking out because it hardcodes paths to grep:
92 # A grep program that handles long lines. 93 GREP="/bin/grep" Do we: * tell libtool upstream to go to hell? (please?)
+1
$PATH is there for a reason and if they think it might not contain /bin, they can just add it at the end.
If the reason is "performance" (I did hear that one somewhere already) they shouldn't use a shell script. Forking is worse than a few (likely cached) file system lookups.
POSIX specifies the 'hash' builtin for /bin/sh, meaning that you do a path lookup once and then never again. There's literally no reason not to trust in a sane PATH.
Until it's fixed upstream, I suggest to just patch it.
PS: Just saw that the variables for gcc, strip, ln -s, ar, as, printf, tr and objdump do not contain a hardcoded path but just the executable name. Go figure.
-- Florian Pritz
On 08/02/12 05:23, Dave Reisner wrote:
Hey,
Long story short, udev wouldn't build against staging and bailed with a really strange library-not-found error. I was able to reduce it down to libtool flaking out because it hardcodes paths to grep:
92 # A grep program that handles long lines. 93 GREP="/bin/grep" 94 95 # An ERE matcher. 96 EGREP="/bin/grep -E" 97 98 # A literal string matcher. 99 FGREP="/bin/grep -F"
And sure enough, the rebuild of grep moved the binaries out of /bin:
- ./configure --prefix=/usr --bindir=/bin --without-included-regex + ./configure --prefix=/usr --without-included-regex
Do we:
* revert the ./configure change? * farm symlinks? * tell libtool upstream to go to hell? (please?)
* rebuilt libtool... (being done now) Allan
participants (3)
-
Allan McRae
-
Dave Reisner
-
Florian Pritz