Re: Some fixes for cygwin

[Charles Wilson]

Robert Collins wrote:

> 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.


Perhaps.  But that would need to be transparent to the user AND 
developer: we don't want to force Joe Developer to change his code to 
explicitly dlpreopen the modules...so it would have to be some sort of 
constructor thing...

However, I'm sure there are issues that I don't know about -- having 
never really used libtool's modules.

> 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...


Yep, both are ugly.  Perhaps this is a packager issue?  "Since my_toy 
uses modules, and installs those modules into /usr/share/my_toy, you 
must extend your PATH on windows to include /usr/share/my_toy".  This 
can be an end-user issue (and thus the my_toy mailing list gets a new 
FAQ), or Joe Developer can bundle a PATH-fixer when he makes a (cygwin? 
windows?) binary of my_toy available.

E.g. on cygwin, the my_toy package would include this additional file:

  /etc/profile.d/my_toy.sh

which cotains

  export PATH=${PATH}:/usr/share/my_toy

That's kinda what my proposed patch to mdemo-inst.test: we adjust the 
path from "outside" of the executable...

--Chuck