Re: [Chicken-janitors] #962: Cygwin can't load Chicken units properly on my system

[Chicken Trac]

#962: Cygwin can't load Chicken units properly on my system
-------------------------+--------------------------------------------------
  Reporter:  johnwcowan  |       Owner:              
      Type:  defect      |      Status:  new         
  Priority:  major       |   Milestone:  someday     
 Component:  unknown     |     Version:  4.8.x       
Resolution:              |    Keywords:  Cygwin units
-------------------------+--------------------------------------------------

Comment(by johnwcowan):

 Okay, with help from #chicken folks I've now diagnosed this.  The trouble
 is that Cygwin is schizophrenic about DLLs; if you load them yourself with
 dlopen, then LOAD_LIBRARY_PATH and all the regular Linux machinery is
 respected; but if references are bound by the linker, then they are loaded
 by the native Windows loader, which only looks at PATH.  What's happening
 here is that cygchicken-0.dll is in $PREFIX/bin, as it needs to be to load
 csi at all, but when a (use srfi-4) is done, csi attempts to load it again
 with dlopen, which expects to find it in $PREFIX/lib.

 An immediate workaround is to set LD_LIBRARY_PATH to /usr/local/bin.
 However, setting LD_LIBRARY_PATH globally is basically Evil and Wrong,
 though I'm willing to do it just for myself.  For one thing, Cygwin is
 slow enough without making it search /usr/local/bin for every call to
 dlopen made by any application.  More locally, alias
 csi='LD_LIBRARY_PATH=/usr/local/bin csi' works, as does a wrapper script.

 Making a symbolic link from /usr/local/bin/cygchicken-0.dll to
 /usr/local/bin/cygchicken-0.dll does not work, presumably because Cygwin
 is in the end passing the file to the Windows loader, which does not
 understand Cygwin symlinks.  Just making a copy would cause the same DLL
 to be loaded twice in the same Windows process, which might very probably
 cabbage the process, if not Windows itself -- I'm not willing to even try
 that.

 Another approach would be to modify the call to ##sys#load-library-0 in
 ##sys#load-library to special-case Cygwin, passing
 $PREFIX/bin/cygchicken-0.dll directly.

 A more fundamental question: Why can't csi notice that it is trying to
 dlopen a shared library that is already loaded into the process?  If  that
 could be avoided, everything should work fine on all platforms.

 MinGW builds don't have this problem because they don't have dlopen in the
 first place.

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/962#comment:1>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.