#66 closed defect (fixed)
dash: autoreconf cannot run libtoolize
Reported by: | Tellie | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | shell | Version: | |
Severity: | low | Keywords: | |
Cc: |
Description
Hi
When i have dash installed and do a sh -c "autoreconf -f -i" its complaining that it cannot find libtoolize.
If i go back to the ash-sh all works like it should.
Change History (8)
comment:1 by , 10 years ago
Summary: | Dash dont work with autoreconf → dash: autoreconf cannot run libtoolize |
---|
comment:2 by , 10 years ago
I also saw strange problems with dash as shell.
running configure on nasm gave some procdump and strange messages like: configure cannot fork
comment:3 by , 8 years ago
This problem breaks down to the following:
D:>dash -c 'cd /@unixroot/usr/share/libtool/build-aux' C:/USR/BIN/dash.exe: 1: cd: can't cd to /@unixroot/usr/share/libtool/build-aux
If you use ash instead of dash, it works smoothly. There must be a built in cd
command fault.
comment:4 by , 8 years ago
Ok, it's rather simple, it presents the current the drive letter to /@unixroot assuming it's a root path on the drive and not the absolute path. Usual thing. I will find out where to fix it nicely.
comment:5 by , 8 years ago
The problem is bigger, things like cd /tmp
(and in fact, any path present in kLIBC path rewrite rules) will fail because dash thinks they are root paths and not absolute, so it will prepend the drive letter. We need to check the individual path for whether it's a path rewriter's rule or not.
BTW, this problem is common to all kLIBC apps using the presence of /
at the beginning of the path as an indicator that it's a root path which needs a drive letter to become absolute. In particular, Qt has the very same issues.
As a side note. Another related problem is that once the path is canonicalized with realpath
or such it loses the path rewriter part and becomes a normal path which makes the result non-portable across different systems (since on different systems path rewriter rules may point to different final paths).
comment:6 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This is fixed by r1656. Turns out that there is a rather easy way to check if the given path has a rewrite portion using __libc_PathRewrite
which allows to determine if it should be considered relative or not. Other apps should use it too when needed.
Anyway, this doesn't solve the main problem of ambiguity introduced by the whole usage of things like /@unixroot
in path rewrite rules but that's a different story.
comment:7 by , 8 years ago
Note that I checked dash
with this fix across the expat port (did the autoconf/configure/make cycle) and the results are completely identical to what we get with ash
. So it should be more or less now to use dash
as the default shell. I will do more testing after fixing #104.
I can confirm that. Here it may be easily reproduced with the
expat
port. Running itsbuildconf.sh
successfully completes with this under ash:and fails early with this under dash: