Re: [Chicken-users] more Cygwin library names

[Brandon J. Van Every]

John Cowan wrote:

Brandon J. Van Every scripsit:

  

But the only name that exists in the build for a dynamic library is 
cygchicken-0.dll.  So unless you have an old build lying around that's 
confusing things, this is not the source of the problem anymore.  How 
exactly did you crash it?  Let's see if I can reproduce your crash.
    

To reproduce is easy.  cmake, make, and make install under Cygwin;
then "csi -R srfi-1".
  

Hrm.  Yes I reproduce the nursery-is-too-small problem. 

Everything in /usr/local/bin seems to be okay, so I suspect the problem
is what gets installed in /usr/local/lib.

The autotools build installs lib(u)chicken.dll.a and lib(u)chicken.a
(plus the *.la files used by libtool, which you needn't care about).
But the CMake build loads lib(u)chicken-0.dll.a and lib(u)chicken-static.a.

If you can make CMake do what autotools does, I think I'll be in business.
IOW, the -0 is wrong 

Ok, now I see how it's supposed to be.  cygchicken-0.dll and libchicken.dll.a.  CMake 2.4.2 doesn't have a straightforward mechanism to do this, but I think I can kludge it.  Stay tuned.

and so is the -static.

  

I'm not sure this is an exhibition of wrongness.  VC++ needs it because both static libs and import stubs end in .lib.  So, it is necessary to either give libraries a unique name to distinguish them, or else keep them in separate directories.  The latter typically leads to DLL Hell, so the former is preferrable.  The nomenclature could be changed on a per-platform basis, but I do not think it is a wise practice.  I think it is probably best if all platforms use the same library names, modulo their favorite library suffixes.  I'll leave it to others to comment on the pros and cons of this.

In any event this doesn't affect dynamic loading issues.


Cheers,
Brandon Van Every