Date: Sat, 22 Nov 1997 01:44:15 +0100 (MET) From: Hans-Bernhard Broeker To: DJ Delorie cc: djgpp-workers AT delorie DOT com Subject: Re: alpha-971114: Makefiles revisited In-Reply-To: <199711212349.SAA00757@delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.