Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3AFEE27F.33C3BD51@phekda.freeserve.co.uk>
Date: Sun, 13 May 2001 20:37:35 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Fileutils 4.0 and symlinks
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

I've just built Fileutils 4.0 against DJGPP CVS. More tests in the test
suite pass now, mostly to do with symlinks. ;) There were a couple of
changes needed in addition to including config.h in djstart.c & djutils.c:
one to lib/lchown.h and some to the test suite to use symlink-enabled
'ln'.

So the release of Fileutils 4.0 will build out-of-the-box with DJGPP CVS.

I had a lot of trouble building Fileutils against DJGPP CVS. I found some
rather strange problems. At first I tried to configure using:

    CFLAGS="-g -O2 -nostdinc -I$CVSDIR/include" \
        LDFLAGS="-g -O2 -nostdlib -L$CVSDIR/lib" \
        LIBS=-lc \
        ./configure --disable-nls

(I realise that this would not include stubs, etc. in the link stage and
that this is the wrong thing to do.) This caused the DOS box to GPF. I had
to remove '-nostdlib' to prevent a GPF, when configuring. Using
'-nostdlib' to try to generate an executable from an object file does not
cause a crash, so this seems to be related to the way configure invokes
gcc.

I'm using gcc 2.95.3, binutils 2.10, autoconf 2.13, bash 2.04.

In the end I settled on putting the include and library directories for
the DJGPP CVS area ahead of the default ones.

CFLAGS="-g -O2 -I$CVSDIR/include" \
    LDFLAGS="-g -O2 -L$CVSDIR/lib" \
    ./configure --disable-nls

I still encountered some a weird problem. When I tried to link programs, I
got errors about '-lgcc' or '-lc' not being found. This was strange
because adding '-g' to the gcc line showed that the directories containing
libgcc.a and libc.a were in the search path. I think the problem was that
there were too many open files, because another program generated the "too
many files open" error. It turned out that restarting Windows solved the
problem.

BTW Mark, bnu210b.mft contains two directories listed - man and man/cat1.
This is bad if you use 'rm -rf @bnu210b.mft' to uninstall binutils 2.10.
:(

Bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/