Re: [Chicken-users] CMake: "make install" crashes on bad reference to chicken.html

[John Cowan]

Brandon J. Van Every scripsit:

> I was going to Google about what 
> constitutes best practices for Cygwin nomenclature, the lib- vs. the 
> cyg- conventions.  I haven't.  Can I goad you into doing that homework 
> for us?

Well, I'll tell you what I know about it, and you tell me if it's useful
to you, and what more you need to know.

Background: On early Unix systems, there were only static libraries.
At link time, these were bound into executables and that was that.
By convention, the foo library was named libfoo.a, and the linker has
switches to specify places to look for libraries.

Later, Unix gained dynamic link capabilities as well, so the libraries
were split into an import library, still named libfoo.a, and a dynamic
link library named libfoo.so.  Dynamic link libraries can either be
specified with an absolute pathname or located by searching the path
specified in the environment variable LD_LIBRARY_PATH.

The original design of Cygwin followed this pattern with two exceptions:
the extension of the dynamic link library had to be .dll, not .so; and
there was no support in Windows for LD_LIBRARY_PATH.  Changing either of
these would require building a Cygwin-specific dynamic linking mechanism,
which was rather more effort than anyone wanted to undertake.

The difficulty arose when a Cygwin program and a regular Windows
(specifically, GnuWin32) program used from the Cygwin shell used
the same underlying library.  As long as you use only Cygwin or only
Windows programs, there's no problem, but it's not uncommon to use
Windows programs from Cygwin and even Cygwin programs from Windows.
The result is hybrid PATHs.  Both the Cygwin and the Windows programs
will search PATH to find libfoo.dll, but the two DLLs are incompatible
and one program gets the wrong one and dies.  This led to random results
depending on the order of directories in PATH.

Consequently, the Cygwin convention for DLLs (but nothing else) was
changed from libfoo.dll to cygfoo-N.dll (where N is a version number that
is changed when a backward-incompatible change is made to the library).
The Cygwin core libraries (which are Windows DLLs that provide the
illusion of the Posix environment) were already using the cyg- prefix,
so extending it to other libraries was no problem.

In that way, libfoo.dll and cygfoo-0.dll can coexist in PATH without
difficulty, and the GNU linker was extended to handle either naming
convention depending on the --dll-search-prefix switch.  Furthermore,
Cygwin programs can share DLLs easily without a DLL-hell problem, thanks
to the explicit version number.

To make matters worse, the libchicken library is loaded both at startup
and when a unit is used.  It has to have the same name on both occasions.
So the build process must produce cygchicken-0.dll when building for
Cygwin, nothing else.

-- 
Newbies always ask:                             John Cowan
  "Elements or attributes?                      http://www.ccil.org/~cowan
Which will serve me best?"                      address@hidden
  Those who know roar like lions;
  Wise hackers smile like tigers.                   --a tanka, or extended haiku