Mail Archives: djgpp-workers/1999/09/15/06:22:12
On Tue, 14 Sep 1999, Laurynas Biveinis wrote:
> rmdir: $(rmdir_OBJECTS) $(rmdir_DEPENDENCIES) ln
> $(LINK) $(rmdir_LDFLAGS) $(rmdir_OBJECTS) $(rmdir_LDADD) $(LIBS)
> ./ln -s $@ grmdir
> stubedit grmdir.exe argv0=rmdir
>
> It will be broken with new .exe symlink code - guess which file stubedit
> will update.
One way to fix this would be to replace "ln -s" with "stubify -g".
The last two lines of the rule are added by the DJGPP-specific
configuration scripts, so they are easily changed.
> 1) Are there places like above in other GNU code ported to DJGPP?
Perhaps; I don't remember. Sh-utils create some ``symlinks'' like
this (e.g., gecho.exe that runs echo.exe), but they use stubify
directly, so as not to depend on `ln' being installed.
> 2) Is it acceptable solution for symlink() generate _both_ foo, which
> is the real symlink and foo.exe, which is good ol' DJGPP .exe symlink?
I'm afraid generating two files foo and foo.exe will have unwanted
side effects. For example, the order in which the directories are
searched for the program will become significant. Thus, invoking a
program as "foo" and "../foo" might cause a different file to be run.
So I think using "stubify -g" is a much better alternative. These
gFOO symlinks are solely to allow the programs to be invoked from the
DOS prompt, to work around internal commands of COMMAND.COM and its
ilk. For this to work transparently, argv[0] must be the original
name of the program, and real symlinks don't (and shouldn't) support
that.
- Raw text -