dash: autoreconf cannot run libtoolize

[Tellie]

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.

[dmik]

I can confirm that. Here it may be easily reproduced with the expat port. Running its buildconf.sh successfully completes with this under ash:

Creating configure ...
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: configure.in: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'conftools'.
libtoolize: copying file 'conftools/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: running: /@unixroot/usr/bin/autoconf --force
autoreconf: running: /@unixroot/usr/bin/autoheader --force
autoreconf: configure.in: not using Automake
autoreconf: Leaving directory `.'
Installing auxiliary config files ...
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

and fails early with this under dash:

Creating configure ...
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: configure.in: tracing
autoreconf: running: libtoolize --copy --force
libtoolize:   error: cannot list files: '/@unixroot/usr/share/libtool/build-aux'
autoreconf: failed to run libtoolize: SYS0003=0x3: The system cannot find the path specified
autoreconf: libtoolize is needed because this package uses Libtool
Installing auxiliary config files ...
libtoolize:   error: cannot list files: '/@unixroot/usr/share/libtool/build-aux'

[Silvan Scherrer]

I also saw strange problems with dash as shell.
running configure on nasm gave some procdump and strange messages like: configure cannot fork

[dmik]

This problem breaks down to the following:

D:>dash -c 'cd /@unixroot/usr'
C:/USR/BIN/dash.exe: 1: cd: can't cd to /@unixroot/usr

If you use ash instead of dash, it works smoothly. There must be a built in cd command fault.

[dmik]

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.

[dmik]

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).

[dmik]

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.

[dmik]

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.

[dmik]

BTW, I missed comment:2 but it's clearly a different problem, created #113 for it.