Mail Archives: djgpp-workers/2001/10/11/07:33:02
> > Well duh :-)
> > Try "grep version include/dos.h |less".
> I tried this and it worked. The output I got was:
> DJGPP_204 D:\dj204>grep version include/dos.h |less
> extern unsigned short _os_trueversion;
> unsigned short _get_dos_version(int);
>
> I suspect an old exe in the bin directory. Check to see that the exe file
> dates are from this month and if not then unzip the binary package again. If
Well, this seems _very_ unlikely, as I started from an empty dir and
extracted packges there. So the less and grep executables are the ones
found in the binary packages I downloaded from clio.
> this doesn't fix it then I don't knwo what it could be. Does grep and less
> work standalone?
They do. "grep blah <file>" works, and so does 'less file'.
> The updated Bash 2.05 at clio has the read issue fixed.
Good - I'll download it and see about configuring perl.
> > The $'foo' thing, right? Still seems odd; bash only emits these
> > things in a way it can read back, so unless you mix bash versions,
> > there should be no problem. May try this later.
> Yes this is the issue. I am now comparing Bash 2.04 and 2.05 output from GCC
> build to see if it is fixed, but preliminary test failed and I am testing
> again just in case.
A thought occurs - configure uses $CONFIG_SHELL (which defaults to
$SHELL, I think) to run config.status.
So if you run "bash205 ./configure --prefix=/dev/env/DJDIR ..." (with
bash205.exe a bash 2.05 executable), bash 2.05 will be used for the
configure script, but $SHELL (probably /dev/env/DJDIR/bin/bash.exe) will
be used to run config.status. So if $DJDIR/bin/bash.exe is bash 2.04,
you do end up mixing versions.
> > > 5) Grep configuration issue - can't rebuild using config.bat,
> > > can build using pre-configured makefile
> > What was the problem here? config.bat simply sets up grep for
> > a regular 'configure' run, doesn't it?)
> It can't guess the host type.
Oh right. Didn't updating config.guess/config.sub help?
I thought it was only perl's Configure that still had issues there?
> > > a make install seems to create /dev/env, not /dev
> > > and ./env. This may simply be a change in the library.
> >
> > This is a completely separate thing, not specific to bash at all.
> > Basically,
> > mkdir /dev
> > mkdir /dev/env
> > creates /dev and ./env using 2.03; with the CVS libc, you get
> > /dev/env (as you might expect). I think this is simply a CVS
> > libc change, so probably needn't be listed here;
> Shouldn't the creation of these be surpressed?
That depends on your viewpoint. I agree with you that we should just
take /dev into our own, virtual, namespace, hiding (NOT modifying) a
physical /dev directory if it exists.
Eli feels that we should be as unintrusive as possible and support a
physical /dev directory normally, with only /dev/env handled specially.
The former solution avoids creating /dev/env with every make install, as
the mkinstalldirs script creates leading dirs if they don't exist, while
the latter allows users to have a /dev directory. So it's really a
judgment call.
> > > 11) bash 2.04 is unable to run autoconf; m4 complains
> > > d:djgpptmp/t1234.567/traces.m4: no such file ...
> > > Apparently, it somehow gets a path with backslashes.
> > > bash 2.05 does not have this problem.
> Could you try again with the updated Bash 2.05 from clio and let me know how
> you get on.
Bash 2.05 didn't have the problem, so I expect it still doesn't.
Will try it though (might be during the weekend instead of tonight).
- Raw text -