Mail Archives: djgpp/1999/08/31/23:40:24
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?
> An other oddity found when looking around. Trying to run install, which is a
> symlink to ginstall, did not work.
This is a known bug. The port of GNU Fileutils was produced with an
old version of DJGPP; newer versions of DJGPP solve that bug, but no
one had time yet to make a newer port of Fileutils.
> Making a fresh symlink, it works.
Yes, because you used a newer DJGPP version. The bug is in the stub
loader, and it only raises its ugly head when the target of the
``symlink'' has exactly 8 characters in the file name before the .exe
part ("ginstall" is exactly 8 characters).
> 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.
> Many thanks for your work in any case
You are welcome.
- Raw text -