Mail Archives: djgpp-workers/2000/04/26/15:56:39
> Date: Tue, 25 Apr 2000 06:58:04 +0500
> From: Prashant TR <prashant_tr AT yahoo DOT com>
This is a longish message, sorry.
> The DJGPP port of the Sh-utils pretest is available on v2gnu/beta on Simtel.
Thanks for working on this.
I downloaded and built the package. Some comments/gripes/questions I
have are listed below.
> 1> I've enabled NLS support during compilation. Is it necessary that I
> have the .mo files in the binary distribution?
I don't think it makes any sense to build a package with NLS support,
unless you supply the *.gmo files in the binary distribution.
But for that to work with DJGPP, you need to decide (or we need to
discuss here and make up our mind) what DOS codepage to use for
recoding each of the *.po files. Otherwise, you will risk producing
*.gmo files that would be unusable.
> Any comments on this?
Plenty ;-)
1) The packaging has some minor problems:
- There's no need to put the various *.texi files into the info/
subdirectory in shl20gb.zip. They don't belong to a binary
distribution.
- The man pages in the binary distro are unformatted. This would
require users to install Groff to read them. I'd recommend to
format them (and put them into man/cat1 instead of man/man1).
- Why are the files fnchange.* and README.in in the binary distro?
- It is best not to include top-level directories such as bin/,
gnu/, lib/, and manifest/ in the distribution and in the *.mft
files. Someone might say "rm -rf @shl20gb.mft" and accidentally
nuke their entire DJGPP tree!
- It's probably a good idea to add DSM files to the distribution.
- Are the binaries stripped? They seem too large.
- The *d.zip distribution, if you want to prepare one, should
include the DVI and PostScript versions of the docs.
2) The source distribution configures and builds okay on Windows 98
and on DOS, except for the following problems:
- It would be better if users were not required to run the
configure script if they don't need to. Is it possible to
distribute a configured package? If not, why not?
- When configuring on DOS, the configure script complains:
d:/foo/gnu/sh-util2.0g/conftest.sym.exe: No such file or directory
This happens when it checks whether lstat derefrences a symlink
specified with a trailing slash. The problem is, of course,
that "ln -s" tries to create conftest.sym.exe which is an
invalid name on DOS.
However, the upshot is that the test fails, as it should, so I'm
not sure you need to bother about this (especially since the
solution is messy ;-).
- Configuring from another directory fails if the source directory
is given with a drive letter, like this:
d:\foo\gnu\sh-util2.0g\djgpp\config d:/foo/gnu/sh-util2.0g
The error message printed by ./configure is this:
creating Makefile
configure: error: cannot find input file `e'
(E: is the drive letter where I ran this.)
As far as I could see, this happened because the $@#&*! Autoconf
have changed the produced script so that the following fragment
of the config.sed script no longer does its magic:
# Switch the order of the two Sed commands, since DOS path names
# could include a colon
/ac_file_inputs=/s,\( -e "s%\^%\$ac_given_srcdir/%"\)\( -e "s%:% $ac_given_srcdir/%g"\),\2\1,
I suggest to leave this snippet alone, but add another one which
does work with the changed configure script. (To find how the
offending line looks today, search the configure script for the
string "ac_file_inputs".)
- When building the package, GCC complains like this:
gcc -DLIBDIR=\"c:/bin/gcc/lib\" -DHAVE_CONFIG_H -I.. -I. -I../intl -g -O2 -c -o makepath.o makepath.c
makepath.c:114: warning: redefinition of `uid_t'
c:/bin/gcc/include/sys/types.h:37: warning: `uid_t' previously declared here
makepath.c:115: warning: redefinition of `gid_t'
c:/bin/gcc/include/sys/types.h:22: warning: `gid_t' previously declared here
This is due to this snippet from makepath.c:
#ifdef __MSDOS__
typedef int uid_t;
typedef int gid_t;
#endif
makepath.c is not used in Sh-utils, but warnings aren't nice,
IMHO. I have makepath.c from Fileutils 3.16, where it says
thusly:
#if defined(__MSDOS__) && !defined(HAVE_CONFIG_H)
typedef int uid_t;
typedef int gid_t;
#endif
Which does The Right Thing, since the configure script already
tests for the correct declaration of uid_t and gid_t. I'm
guessing that this is a relic from some ancient DOS port.
3) "make check" fails for me in several ways:
- It complains about "/bin/sh" and (if I arrange for /bin/sh to
exist) about Perl, although I definitely have Perl installed.
As far as I could see, the reason is that several Makefile's in
the test suite (and elsewhere) use a colon as a PATH separator.
There's a fragment in djgpp/config.sed that is supposed to take
care of this, but it somehow isn't working. I didn't have time
to look closer at this, so I simply replaced : with ";" manually
in those Makefile's. Then the test suite started running, but
some of tests failed, as described below.
- The tests which test failure messages don't pass because DJGPP
programs have their full path in argv[0], while the test suite
expects a relative path. Thus, the test suite expects to see,
e.g., "basename: too many arguments", but our port prints
"d:\foo\bar\basename.exe: too many arguments". The tests which
fail like that are basename/basic and factor/basic.
- The tests for the `date' utility all fail. I think this is
because all the *.X files have Unix-style end-of-line format,
while the corresponding *.O files are generated with DOS-style
CRLF end-of-line format, and the test suite uses `cmp' to
compare them.
The solution is either to use `diff' for comparison or to run
`utod' on *.X files inside edtests.bat.
- The stty tests fail because they try to use a file named
`.saved-state' which is invalid on DOS.
- The last test, for `nice' either wedges my machine or reboots
it. The problem is that the test tries to run the command
"nice nice", but there's a shell script called `nice' in
the same directory, and our `execvp' looks in the current
directory first...
I solved this by replacing "nice" with "nice.exe" in the test
script tests/nice.
After this, the test for `nice' simply fails because we don't
inherit the nicety level to child programs. (If we do want to
inherit it, we will have to export an environment variable and
modify `nice' in the library to pay attention to that variable.)
I wonder if the test suite worked for you, and if so, how.
4) The following fragment you added to djgpp/config.bat should IMHO
be rethought:
Rem workaround for bug in ported BASH.
cp -f %XSRC%/lib/Makefile %XSRC%/lib/Makefile.orig1
sed -e "s|\`test -f .*\`||g" %XSRC%/lib/Makefile.orig1 > %XSRC%\lib\Makefile
cp -f %XSRC%/src/Makefile %XSRC%/src/Makefile.orig1
sed -e "s|\`test -f .*\`||g" %XSRC%/src/Makefile.orig1 > %XSRC%\src\Makefile
The problem with this is that it replaces files in the source
directory. This will fail if the source directory is on a CD-ROM.
If possible, it is better to find a solution that copies the files
into the working directory and modifies them there.
5) Why is the file djgpp/finish.sh needed? (Yes, I see the part of
djgpp/README that mentions it, but I still don't get it. Perhaps
I don't understand why charset.alias is required.)
6) The test suite requires Perl and Awk. I suggest to mention this
in djgpp/README.
7) What is the file djgpp/renfiles.bat for?
8) It's probably a good idea to mention any DOS-specific issues in
sh-utils.texi. For example, several programs print an error
message because the underlying functionality doesn't exist; this
should be in the docs, IMHO. (Btw, pinky doesn't seem to be
documented there?)
9) Some of the changes I did when porting Sh-utils 1.12 didn't make
it into this port. Is there any reason for not including them?
Here's a list of my changes I didn't find in your port (you can
see them all in the file DIFFS in shl112s.zip):
- the addition of DOS shells to default_shells[], and the special
environment variable for the location of /etc/shells in
lib/getusers.c
- support for drive letters in lib/stripslash.c
- binary I/O mode from/to pipes/files in tee.c
- additional check for FOO.exe if FOO is not found in test.c,
when the -x switch is given
- su.c omits quite a few of my old changes; does that mean any
change in functionality, or did you find an easier way of
achieving the same goal?
10) As a general comment about your changes: DJGPP-specific changes
should be conditioned on __DJGPP__, not __MSDOS__. One example is
use of __dosexec_find_on_path in su.c.
- Raw text -