RE: Some fixes for cygwin

[Robert Collins]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden On 
> Behalf Of Charles Wilson
> > mdemo-inst (mdemo-conf and mdemo-shared):
> > -------------------
> > 
> > modules are not installed in the path, nor are they in 
> > the same directory as the executable.  So, the test 
> > fails because windows can't find the installed DLL.  
> > This is a testing error, not a real error.  Setting the 
> > $PATH appropriately, and the test succeeds.  Should we
> > install wrapper scripts into _inst/bin, or should 
> > mdemo-inst.test explicitly set the PATH before attempting 
> > to run the executable?
> 
> 
> Whaddaya think?  I lean towards "fixing" mdemo-inst.test to 
> set the PATH 
> (sample -- but untested -- patch attached) Implication: in 
> "real life", 
> after installing a program that hides its modules in 
> /usr/share/my_prog/, the user must add /usr/share/my_prog/ to 
> her PATH, 
> since my_prog relies on the windows runtime loader to "find" 
> the modules 
> (dlls) and PATH is the only way to tell the loader where to look(*). 
> This is awkward, true -- but the alternative is to install wrapper 
> scripts for "my_prog" that set the path -- but then the 
> wrapper script 
> can't be executed from Windows Explorer, while a "normal" exe can.
> 
> 
> (*) or, we could always install modules into bindir on 
> windows, which is 
> where the executable will (presumably) be installed, thus 
> guaranteeing 
> that the windows runtime loader will find the modules even if 
> "bindir" 
> isn't in the path.  But that's so **ugly**.  The point of 
> modules is to 
> hide them somewhere OTHER than the main bindir...
> 
> Or (urgh) the "wrapper script" could be a wrapper *executable* that 
> depends on no special libraries, but merely sets the PATH (by 
> appending 
> the compiled-in moduledir) and then exec's the real executable?  This 
> wrapper *exe* could be run from Windows Explorer...

If the modules are really modules, why can't the program dlpreopen them?
Or does dlpreopen depend on the system linker? If dlpreopen does depend
on the system linker, then perhaps we should patch dlpreopen for win32
platforms to use a C style constructor to call dlopen -before- main(),
thus preopening the files, but with LDPATH/known module paths honoured.

As I've stated before, a shell wrapper really is unappealing, and a .exe
wrapper is uggggly. For starters you'll have to forward export every
symbol in the real .exe...

Rob