Mail Archives: djgpp/1999/10/19/06:58:59
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 <unistd.h>
#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.
- Raw text -