Dave Korn wrote:
Roumen Petrov wrote:
I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.
As I explained to Eric, this function implements 'abspath', not 'realpath',
and given that we can't assume any of the directories even exist when we have
to do this at link time, before installation, I don't see how we could hope to
do any different.
You may test you function with following example:
----------------------------------------
(
P=/work/tmp/test/test-links
rm -rf $P
mkdir $P
cd $P
mkdir -p a/1/2
mkdir -p b/2
(cd b; ln -s ../a/1)
cd b/2
D=../1/../
touch $D/test
func_normal_abspath $D
echo $func_normal_abspath_result
/bin/ls -l $func_normal_abspath_result/
/bin/ls -l $D
)
----------------------------------------
I think the whole of GNU configure expects the tree under $prefix/ to be
real and there are a lot of other things that will break if you try to use
symlinks to make the physical directory structure different from the apparent
structure, for example gcc tries to execute ld by starting at the
$prefix/lib/gcc/$target/$version directory where cc1 lives and invoking
../../../../bin/ld; if you've got symlinks in there that can't be ascended
without ending up somewhere other than you expect, then the compiler isn't
going to work.
Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
prefixed binaries from <PREFIX>/<TARGET>/bin don't work for me. As
example gcc can't find cc1. May be is same issue.
To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1 XXXX ./i486-mingw32/lib/gcc -> ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1 XXXX ./i486-mingw32/libexec -> ../libexec/
So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious, is it?
So to me function like XX_abspath has to work.
cheers,
DaveK
Roumen
