Date: Wed, 1 Sep 1999 12:18:55 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Maurice Lombardi cc: djgpp AT delorie DOT com Subject: Re: bug in ginstall under bash ? In-Reply-To: <37CC8962.D0BF0EEA@ujf-grenoble.fr> 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 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")