Mail Archives: djgpp/1999/09/01/01:41:11
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 -