Mail Archives: djgpp-workers/1997/11/21/19:44:35
On Fri, 21 Nov 1997, DJ Delorie wrote:
> > * Not all tools get made with the newly compiled libc.a, crt0.o and stub,
> > as can be seen with RCS 'ident' tool.
>
> Those are the ones that need to run on the build machine, which may
> not be MS-DOS at all.
No, I was talking about a native build, and about the binaries that
get build in {srcdir}/../bin, i.e. the final ones.
For example, here's the souped up result of an 'ident' run over the
current distribution of djdev202:
acp3bf:bin 30>ident *.exe | grep '\$Id' | sort | uniq -c
1 $Id: %s built %02d/%02d/%02d %02d:%02d:%02d by djasm $
1 $Id: DJGPP libc built Aug 31 1997 17:22:28 by gcc 2.7.2.1 $
16 $Id: DJGPP libc built Nov 2 1997 20:06:59 by gcc 2.7.2.1 $
1 $Id: DJGPP libc built Oct 31 1996 19:13:19 by gcc 2.7.2.1 $
2 $Id: DJGPP libdbg built Nov 2 1997 21:37:01 by gcc 2.7.2.1 $
1 $Id: stub.asm built 08/31/97 00:06:56 by djasm $
1 $Id: stub.asm built 09/07/97 21:18:28 by djasm $
2 $Id: stub.asm built 10/28/97 19:30:23 by djasm $
4 $Id: stub.asm built 11/02/97 21:20:08 by djasm $
13 $Id: stub.asm built 11/02/97 22:28:13 by djasm $
Looking at the distributed files, there's also a rather arbitrarily
looking distribution of file dates: half of the .exe's are dated November
15th, most others November 3rd, and go32-v2.exe from 31st of August.
> > * Due to a bug in the 'makemake' tool, you couldn't call the sub-makefiles
> > in libc, libm, and debug any more, after the corresponding library has
[...]
> Oops. I wonder why it works for me?
Can't say. But see next paragraph for a possible explanation...
[...]
> > Otherwise, passing the 14 KB long list of filenames for the libc.a
> > 'ar' command line around will break, with no visible error message but
> > 'Error -1'.
>
> It should be using the other option - the one with @makefile.rf in it.
Ooops, I was barking up the wrong tree, somewhat. The problem didn't
really occur for the 'ar' command line, it seems (or so my lossy
memory tells me, looking at the makefiles again, here at the uni).
It's the commands that build 'makefile.oh' that causes the problem.
It tries to pass $(OBJS) to 'misc.exe echo makefile.oh'.
On second thought, this could also explain why you didn't see the problem
with 'makemake': you might have a dummy 'makefile.oh' in each of the
library source dirs (libc, libm and debug), preventing this rule from
getting activated. But then, there's no 'src/libc/makefile.oh' in the
djlsr dist, so this explanation also seems to fail.
> > * It will unconditionally install all the files in '../bin', '../lib'
> > etc., relative to the 'src' directory where the build starts.
>
> This is the scheme I've been using all along. It's important to keep
> backups anyway.
But with that patch-collection available on the WWW, and advertised
to non-experts as well, I think we should strive to make it a bit
more fool-proof.
> > * Building in a separate tree, outside of $DJDIR, would help to avoid the
> > aforementioned danger, but it doesn't work, at least not unless you're
> > willing to install a second copy of djdev202 and at gcc2721b in your build
> > tree as well.
>
> You have to install at least djcrx201.zip or at most
> djdev201.zip/gcc*b.zip to get the extra files you need. This has
> always been the case.
You have to have them installed somewhere, yes, but I don't quite see why
I should be forced to install a *second* copy of them for a native build,
just because I want to do it outside the main $DJDIR location. And the fix
is rather small: just an additional -I$(DJDIR)/include, after -I../include
in the compiler flags. It won't make any difference when .. actually is
$(DJDIR), i.e. if the build is run inside the main tree.
And there's still the other possible reason for building outside $DJDIR:
harddisk space. Of course, djlsr isn't really a huge package by today's
standards, but due to the sheer number of files (~1600 in djlsr202.zip,
two or three times that much during the build), it will occupy a sizeable
fraction (of up to 10 % or so: 3000 files in 35000 clusters) of any
partition using a FAT16 filesystem. When I first tried to recompile the
DJGPP 2 libs, I couldn't do it for exactly that reason. The partition with
$DJDIR on it even had more available space than the other one, but it just
couldn't take another 3000 files because of its cluster size.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -