Installing on an attached linux drive from a Mac OS X (Tiger) system fails 
because hard links are not supported.  This is attempted when trying to 
link python2.4 to python (ln python2.4 python).  If it fails, a copy should 
be performed instead.

changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/idle to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/pydoc to 755
changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/smtpd.py to 755
if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/
bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple-
darwin8.5.0/bin/python; \
else true; \
fi
(cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln 
python2.4 python)
ln: python: Operation not supported

/Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol 
which has been attached to using openapple-K (via SMB).

Logged In: YES 
user_id=1471082

Changing line 599 in Makefile.pre.in to:

(cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python
$(VERSION)$(EXE) $(PYTHON))

allowed make to complete.

Logged In: YES 
user_id=580910

Adding a -s flag to the link command should also fix this issue and has the 
advantage that all builds will be done the same way. The cost for resolving the 
symlink should be neglectible.

Logged In: YES 
user_id=21627

If we are going to support "funny" file systems, falling
back to copying looks right to me. While Apple's SMB
implementation supports symlinks on smb (through a hack),
other implementations might not.

Our Makefile still uses a hard link in two place:

libpython$(LDVERSION).so 

python$(LDVERSION)$(EXE) python$(VERSION)$(EXE))