I fyou look at the current tarball of GNU M4, located here:
http://www.lrde.epita.fr/~akim/download/m4-1.4q.tar.gz or .bz2
you'll see that make distcheck fails, while make check passes.
distcheck fails in a simple way, corresponding to this:
~/src/m4/m4-1.4q/=build/tests % echo 'esyscmd(m4 --version)' | PATH=`pwd`:$PATH m4
m4: error while loading shared libraries: m4.so.0: cannot open shared object file: No
such file or directory
What's wrong?
What is wrong is that the PATH is not the one I passed:
~/src/m4/m4-1.4q/=build/tests % echo 'esyscmd(echo $PATH)' | PATH=`pwd`:$PATH m4
/home/akim/src/m4/m4-1.4q/=build/src/.libs:/home/akim/src/m4/m4-1.4q/=build/tests:/home/akim/bin:/home/akim/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
and therefore, it is not the m4 I wanted to run that is run:
~/src/m4/m4-1.4q/=build/tests % echo 'esyscmd(which m4)' | PATH=`pwd`:$PATH m4
/home/akim/src/m4/m4-1.4q/=build/src/.libs/m4
Which apparently, didn't get the variables it wanted.
This is because of the following lines in ltmain,.sh:
$echo >> $output "\
# Export the path to the program.
PATH=\"\$progdir:\$PATH\"
export PATH
exec \$program \${1+\"\$@\"}
Why not running directly the program? Well, because:
1997-01-28 Gordon Matzigkeit <[EMAIL PROTECTED]>
* ltmain.sh.in (link): Export the PATH variable in order to find
the program, rather than giving a full path. This helps give the
program a less confusing value for argv[0].
but this is no longer relevant!!! Just look at the poor name reported
by the program:
remo% ./m4 --help | sed 1q
Usage: lt-m4 [OPTION]... [FILE]...
the name is already broken by the fact that lt- is prepended.
So, because playing with PATH (and with any user var actually) is a
bad idea, I vote for the replacement of the code above by:
$echo >> $output "\
exec \$progdir/\$program \${1+\"\$@\"}
Comments?
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
