Message-ID: <37CC8962.D0BF0EEA@ujf-grenoble.fr> Date: Tue, 31 Aug 1999 19:03:14 -0700 From: Maurice Lombardi X-Mailer: Mozilla 4.08 [fr] (Win16; I) MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp AT delorie DOT com Subject: Re: bug in ginstall under bash ? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Reply-To: djgpp AT delorie DOT com Eli Zaretskii a écrit: > > On Mon, 30 Aug 1999, Maurice Lombardi wrote: > > > > Do you actually have ginstall.exe in the /bin directory on the current > > > drive? > > > > yes. the djgpp directory is at root level in the F: drive. ginstall.exe is in > > its %DJGPP%/bin subdirectory, and the package to compile and install is in a > > subdirectory of %DJGPP%/contrib. > > This is not /bin, this is %DJDIR%/bin. It's not the same: "/bin" > means literally that. > > > > The correct solution is to configure the package so that INSTALL is > > > replaced with "${DJDIR}/bin/ginstall -c". Then it will work > > > regardless. > > > > In this case it would be wise that running the configure script > > produced by the autoconf script of djgpp do that automatically. > > Usually, a configure script searches for an install program along the > PATH and uses that. If in your case it fails to find it, perhaps that > is the *real* problem. Or maybe the script doesn't look for it, in > which case it's a bug in the script (or in configure.in from which it > is generated). > > Or am I missing something? Well I think I finally got the point. It is an hairy consequence of the way bash translates pathnames. 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 set PATH_EXPAND=y bash -login rem cleaning environment set SYSROOT= set PATH_EXPAND= before booting, at dos prompt (>) I get (djgpp is in f:\djgpp) > PATH PATH=.\;F:\DJGPP\BIN;C:\UTIL;C:\DOS after booting, at bash prompt ($) I get $ echo $PATH ./;/bin;c:/util;c:/dos This is what is expected, in particular /bin/ginstall under bash should translate to f:\djgpp\bin\ginstall for dos. Then under bash I type $ autoconf $ configur --prefix=f:/djgpp $ make $ make install 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 (and did not worked until I understood that I had to add it to the original makefile which of course did not contained it) Now an other possibility is to work without booting bash, but by typing at the dos prompt > sh autoconf > sh configur --prefix=f:/djgpp Then during the work of configur I see on the fly INSTALL = f:/djgpp/bin/ginstall -c This is good, but configure ends by a failing: configur: /bin/sh: No such file or directory (ENOENT) and do not generate the makefiles. Of course SYSROOT is no more defined, so that /bin/sh cannot be found. By looking into configure, and the produced config.log, config.sta and config.cac, I understand that configure fails in its last line which reads test "$no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1 so I clean everything and type at dos prompt > set CONFIG_SHELL=f:\DJGPP\BIN\SH.EXE > sh autoconf > sh configur --prefix=f:/djgpp This time it works, but it is a bit strange do do ! The best would be that the expected behavior, booting bash and working exactly like in unix worked. > > Finally an other inconvenience, only when porting an unix script, is that > > ginstall do not add automatically the suffix .exe to the executables. > > I don't understand. Are you telling that "ginstall foo /bin/foo" does > NOT produce /bin/foo.exe? It should; it does for me. Please post the > details. Indeed, but I think that I also got the point: the unix makefile, which knows nothing about .exe suffix contains basically gcc -o prog prog.c this produces two files prog. and prog.exe 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. If I destubify prog.exe by exe2coff prog.exe which gives as prog. a simple COFF image then ginstall -c prog somedir creates somedir/prog.exe, with the .exe suffix and the stub added on the fly as expected. So what is wrong is that the gcc compile command adds the stub also to the file prog, which is completely unnecessary. Hope this helps -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice DOT Lombardi AT ujf-grenoble DOT fr