Message-ID:	<37CC8962.D0BF0EEA@ujf-grenoble.fr>
Date:	Tue, 31 Aug 1999 19:03:14 -0700
From:	Maurice Lombardi <Maurice DOT Lombardi AT ujf-grenoble DOT fr>
X-Mailer:	Mozilla 4.08 [fr] (Win16; I)
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp AT delorie DOT com
Subject:	Re: bug in ginstall under bash ?
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 990831094953 DOT 9517N-100000 AT is>
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

- Raw text -