Date: Tue, 19 Oct 1999 10:19:52 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Juan Manuel Guerrero, Student, FB05" cc: djgpp AT delorie DOT com Subject: Re: bzip2-0.9.5d port for djgpp In-Reply-To: <8E844DD12F8@HRZ1.hrz.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 18 Oct 1999, Juan Manuel Guerrero, Student, FB05 wrote: > i don't know if this job has already been done > so i post here my port of bzip2-0.9.5d in the > hope that it would be useful. Thanks. Please consider packaging the modified sources and binaries into zip files and uploading them to SimTel.NET. That would make it much easier for others to benefit from your work. Detailed instructions about what to do to upload DJGPP packages to SimTel are available at this URL: http://www.delorie.com/djgpp/howto/simtel-upload.html > At compression time: > filename -> filename.b > filename.e -> filename.eb > filename.ex -> filename.exb > filename.ext -> filename.exb > filename.tar -> filename.tbz I think it would be better to be compatible to previous ports of bzip2. They did this during compression on non-LFN platforms: filename.ext -> filename_ext.bz2 (if filename_ext was more than 8 characters, some of filename letters would be lost). Some ports of packages that invoke bzip2 rely on this behavior to detect bzip2-compressed files, so I think changing it might break something. > At decompression time: > filename.b -> filename > filename.eb -> filename.e > filename.exb -> filename.ex > filename.tbz -> filename.tar > filename -> filename.out Doesn't bzip2 record the original name in the compressed one, like gzip does? If it does, then the original name should be restored. > ! CFLAGS=-Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce I don't think it's a good idea to change the default value of CFLAGS (or any other variable set by a Makefile), unless they make no sense at all for DJGPP, which is not the case here. People who want different CFLAGS can always say "make CFLAGS=whatever". > ! all: libbz2.a bzip2 bzip2recover test Why did you need to change this line to bzip2.exe etc.? DJGPP doesn't require such changes; "gcc -o foo" should generate both `foo' and `foo.exe', unless you changed the lib/specs file. Can you explain the need for these changes? In general, I think that porting a package should do as few changes as possible to the original files, because that makes it simpler to port future versions of the same package. > ! LDFLAGS=-s DJGPP ports usually follow the GNU standards, whereby the binaries are by default not stripped. This helps those who need to debug the program after they build it. Programs are stripped before packaging them into the *b.zip archives that get uploaded to SimTel, not when they are built. > ! MAKEINFOFLAGS=--no-split --force Why is --force a good idea? I think if the Texinfo sources have errors, the Info file shouldn't be produced from them until the errors are corrected. The Right Thing to do is to fix the sources, not to force makeinfo to ignore the errors. > + int _stklen = 524288; /* DPMI stack */ v2.02 and later uses 512K stack by default, so why did you need this? > + # define HAS_EXTENSION(filename) (strchr ((filename), '.') != NULL) [snip] > ! if (HAS_EXTENSION (outName)) > ! { > ! register IntNative extStart = (IntNative)(strchr (outName, '.') - outName); Unless I'm missing something, outName may include the leading directories, like in d:/foo/bar/filename.ext. If so, then calling `strchr' might find a dot in one of the leading directories. What happens with a file d:/foo.bar/baz/filename, for example? > + #ifdef __DJGPP__ > + #define HAVE_LFN_SUPPORT (_USE_LFN) > + #define NO_LFN_SUPPORT (!HAVE_LFN_SUPPORT) There's a more portable way of testing for LFN support: use the library function `pathconf', like this: #include #define HAVE_LFN_SUPPORT(filename) (pathconf (filename, _PC_NAME_MAX) > 12) `pathconf' is a POSIX function, so this would get rid of all those ugly "#ifdef __DJGPP__" hacks.