Cygwin can't load Chicken units properly on my system

[johnwcowan]

$ csi -R srfi-4

CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.0
windows-cygwin-x86 [ manyargs dload ptables ]
compiled 2012-12-27 on LNGNYCL-FDB00M1 (CYGWIN_NT-5.1)

; loading library srfi-4 ...

Error: (load-library) unable to load library
srfi-4
"No such process"

Call history:

<syntax> (##core#require-extension (srfi-4) #t)
<syntax> (##core#begin (##core#begin (##sys#load-library (quote srfi-4) #f)) (##core#undefined))
<syntax> (##core#begin (##sys#load-library (quote srfi-4) #f))
<syntax> (##sys#load-library (quote srfi-4) #f)
<syntax> (quote srfi-4)
<syntax> (##core#quote srfi-4)
<syntax> (##core#undefined)
<eval> (##sys#load-library (quote srfi-4) #f) <--

It also fails in 4.8.0 and the Git head.

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

[Christian Kellermann]

I cannot reproduce this with a clean install (just one chicken version) built with cygwin on Windows 7:

$ csi -R srfi-4

CHICKEN
(c) 2008-2013, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.8.0.1 (stability/4.8.0) (rev 54c391c)
windows-cygwin-x86 [ manyargs dload ptables ]
compiled 2013-01-17 on aeryn.xorinia.dim (Darwin)

; loading /usr/local/lib/chicken/6/srfi-4.import.so ...
; loading library srfi-4 ...
#;1>

Can you retry this on a clean slate? Maybe the loader does not like core units that have been mixed between different versions under the same binary version? (although this should be fine)

[johnwcowan]

I tried this on my nifty new clean-slate Windows 7 system, and yes, it's still the same. I'm using 4.8.0.4 and 32-bit Cygwin (which until recently was the only kind of Cygwin).

[sjamaan]

Let's see if we can fix this before 4.9.0

[sjamaan]

I've ran a check on a fresh Windows 7 (the one from modern.ie), both on 4.8.0.5 and today's git master (7718c808aae118ee49ad0271772c4b7ab282a01c). I installed with PREFIX=~/chickens/test and it worked.

However, installing to /usr/local causes an error upon loading srfi-4, but not the one John got. It panics with "nursery is too small". If I increase the nursery with -:s it just hangs.

[sjamaan]

This may have something to do with the obscure DLLSINPATH flag, or the strange C_TARGET_RUN_LIB_HOME which defaults to bin and not lib under Cygwin.

[sjamaan]

This is too obscure to fix, unless someone is willing to dive in deep. I think our priority lies with getting 4.9.0 out the door. Cygwin works in normal situations.

[johnwcowan]

4.9.0 has come and gone, and I just installed Chicken on a clean Windows 7 system, and the problem persists, now in the form of the "nursery is too small" panic reported by sjamaan above. What is worse, the workaround of setting LD_LIBRARY_PATH does not work on this system, nor does the idea of copying cygchicken-0.dll from /usr/local/bin to /usr/local/lib.

Cygwin does *not* work in "normal" situations, unless it is normal to avoid the built-in units such as srfi-1, srfi-4, etc.

[sjamaan]

I give up. We'll need someone who truly groks this stuff to weigh in.

[sjamaan]

Another zombie ticket that probably nobody is going to fix...

[sjamaan]

See also #1054; I think this could be fixable with assemblies, but that means dropping <= Vista support

[sjamaan]

Maybe we can drop Vista support with CHICKEN 5. Doing it with CHICKEN 4 seems a bit premature.

[sjamaan]

I was tempted to select "insane", but for someone willing to dig into Windows this should be merely hard. For someone with actual knowledge about Windows, it would even be easy (if it can be done at all, that is)

[johnwcowan]

This problem has apparently gone away, for whatever reason, in Chicken 4.10.0 (the current bundled version of Chicken on the Cygwin repos). I have some dim memory that the problem exists when you try to run csi in its own build directory.

Everyone can breathe out now.