[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Some fixes for cygwin

From: Robert Collins
Subject: RE: Some fixes for cygwin
Date: Mon, 3 Jun 2002 09:20:45 +1000

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]