RE: Some fixes for cygwin

[Robert Collins]

> -----Original Message-----
> From: Charles Wilson [mailto:address@hidden 
> Sent: Monday, 3 June 2002 4:26 AM

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

Exactly. The dlpreopen capability is transparent, the user thinks they
are using dlopen... even when statically linked. I'll need to check the
failing test source to see if my suggestion makes sense there. And yes,
it would be 100% transparent. Gcc has an attribute for functions that
makes them a constructor, they get called before main() :}.


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

Hmm. I'm also not keen on this. Like the shell wrapper it only works
in-cygwin. 

Rob