Mail Archives: djgpp/1999/09/01/18:21:20
On Tue, 31 Aug 1999, Maurice Lombardi wrote:
> I usually first boot bash with the boot.bat dos batch file which
> comes with bash 1.14.7(2), and which contains mainly:
>
> set SYSROOT=f:\djgpp
IMHO, SYSROOT is evil (see below for one its implication); I suggest
to stop using it. You shouldn't need it, anyway, because as long as
you use DJGPP tools, they all work even if the programs are not in
/bin.
The only problems you might encounter are with shell scripts that
blindly call "/bin/rm" or put files in "/tmp". In my experience, it
is much easier to fix those few scripts (replace "/bin/rm" with
"${DJDIR}/bin/rm" or simply with "rm", and "/tmp" with "${TMPDIR}")
than to track down all those subtle problems that SYSROOT creates. At
least with "/tmp" in shell scripts you get self-explainatory error
messages that you can easily understand!
> the makefile produced by configur contains
> INSTALL = /bin/ginstall -c
> INSTALL_PROGRAM = ${INSTALL}
> INSTALL_DATA = ${INSTALL} -m 644
>
> This is what is expected, and why I was surprised that the line in
> the makefile
> $(INSTALL_PROGRAM) $(BINARIES) $(INSTALLBINARIES) ;
>
> which translates into
>
> $ /bin/ginstall -c afile adir ;
>
> needs that ; at the end
The problem is that SYSROOT is a trick that's only known to Bash;
other DJGPP programs don't know about that. So when Make invokes a
program directly, not through the shell, it tries to invoke
"/bin/ginstall" literally, and that fails.
As you might know, GNU Make tries hard to avoid calling programs
through the shell, because of the overhead, and only does that if the
command line includes some shell features, like redirection and
multiple commands. Adding the semi-colon does the trick of forcing
Make to call Bash, and that's why it works, because Bash pays
attention to SYSROOT.
But it is a very bad idea to have a setup which behaves differently
depending on how the subsidiary programs are invoked. You will have a
lot of subtle and hard-to-debug problems like this. So I suggest to
stop using SYSROOT.
If, after removing SYSROOT, you have some problems with building
packages with DJGPP tools, or any other kind of trouble, please treat
them like bugs and report them here.
> This is good, but configure ends by a failing:
>
> configur: /bin/sh: No such file or directory (ENOENT)
That's because The configure scripts usually say something like this:
SHELL=${CONFIG_SHELL-/bin/sh}
IMHO, this in itself is a bug, but to work around it, simply make sure
$CONFIG_SHELL is set in the environment when you run the configure
script (or always). For example, you could create a file config.site
in the %DJDIR%/share subdirectory and make it say this:
export CONFIG_SHELL=${CONFIG_SHELL='sh'}
Latest versions of configure scripts should automatically load a
site-specific configuration file pointed to by $CONFIG_SITE, so you
will need to define that variable accordingly to have Bash load it.
> The best would be that the expected behavior, booting bash and
> working exactly like in unix worked.
Keep dreaming ;-). Using Unix-like environment on DOS/Windows will
always need a couple of small quirks. Frankly, I'm surprised it needs
so few quirks in the DJGPP case; but then it took 10 years of hard
work (most of it not mine) to get there.
SYSROOT, in my opinion, is one quirk you should NOT use.
> the unix makefile, which knows nothing about .exe suffix contains basically
>
> gcc -o prog prog.c
>
> this produces two files prog. and prog.exe
This is a feature: it is essential to produce `prog', because
otherwise Make will be confused (it expects the target of a rule to be
created by the commands of that rule); but DOS/Windows shells refuse
to run a program if it doesn't have the .exe extension. Producing
both makes everybody happy.
> but they are identical: prog. is not simply the COFF image, it
> contains also the stub.
>
> then
> ginstall -c prog somedir
> simply copies prog into somedir, without addind the suffix.
Okay, this is a known problem. It is caused by the fact that you use
the djgpp.djl file supplied with the GCC distribution (as opposed to the
one which comes with djdev202.zip). The linker script in the GCC
distribution causes the linker to produce stubified programs, whereas
the version from djdev does not.
The next port of GNU install will handle this case correctly, but in
the meantime, you can edit your djgpp.djl file to have this line:
OUTPUT_FORMAT("coff-go32-exe")
say this instead:
OUTPUT_FORMAT("coff-go32")
- Raw text -