Re: [Chicken-users] Re: cygchicken

[John Cowan]

To avoid further proliferation, I'm going to reply to several messages
at once.

Brandon J. Van Every scripsit:

> I have no idea if [cygwin1.dll is] either huge or slow.  It's certainly 
> larger than 
> what MinGW offers.

It is larger and somewhat slower because it has to take precautions
that aren't needed in the common case but are required in corner cases
where Win32 semantics differ from Posix ones, like select() only working
with sockets (it works on any open file selector in Posix and Cygwin)
or being able to delete open files.  Obviously there is also some
overhead just from wrapping Win32 system calls.

> Yes it does.  Cygwin is a Windows avoidance solution.   

It's the most lightweight reasonably complete solution for getting a Posix
environment when due to circumstances beyond my control I have to run a
Windows kernel.  UWin and WSfU are less messy but much less complete,
and CoLinux and VMWare are also less messy but much more heavyweight.
IMHO Cygwin provides the best set of compromises.

> If there's a Cygwin pundit out there, they can happily take
> responsibility for those aspects of the build, and I will work with
> them on it.

Well, I will attempt to masquerade as such a pundit.

> What's stupid, is to install a MinGW from www.mingw.org, in its own
> tree, then install a Cygwin shell, and install Cygwin GCC, and expect
> the MinGW is going to work when invoked under Cygwin.  It's also stupid
> to install a Cygwin shell and say you're going to forego Cygwin GCC.
> All sorts of stuff in Cygwin packages rely on Cygwin GCC, you're
> probably not going to get away with it.

Agreed.

> Installing Cygwin only, with Cygwin GCC, and invoking its own "MinGW" 
> via -mno-cygwin isn't stupid.  It's just misguided, and an invitation to 
> spurious support burdens.

It also has its uses, as I've tried to point out.  In particular, if
you already use Cygwin, and you are developing software that you want
to run with or without Cygwin, then -mno-cygwin is the way to do it.
Chicken is not such a case, since it's not developed under Windows at all.

> Another variation of DLL Hell.  Now what if the application actually 
> wishes to know about and manipulate the names?  Now they've gotta do 
> everything special for Cygwin.

Alas, yes.  (I could retort that people who do that deserve to lose.)

>    * Generic GCC is hard-coded to always look in /usr/lib and /lib when 
> searching for libraries. This is a problem when using "mingw" mode 
> because Cygwin libraries are installed in /usr/lib. The linker should 
> never search in the Cygwin-specific lib directory when linking "mingw" 
> binaries. However, since the Cygwin-specific lib directory is the same 
> directory as one of GCC's hard-coded directories, this has the potential 
> to happen and cause problems.
> 
>    * Whether in "cygwin" or "mingw" mode, Cygwin GCC's linker adds the 
> "cyg" prefix to DLL basenames during its library search phase. This 
> should not happen in "mingw" mode.
> 
> The solution to the first problem involves moving files around and 
> fixing GCC's specs file. The solution to the second problem is a simple 
> fix to the specs file.

Since you seem to understand this problem, can you push the report
upstream to the Cygwin people?  If you won't or can't, I'll try to,
but you obviously know more about than I do.

> The Cygwin CMake build of csi, does "csi -R srfi-1" just fine.  So it 
> seems that either cygwin-default-dynamic-load-libraries is not being 
> utilized, or that something somewhere is happy enough to use / convert 
> to "lib" as the prefix.

The units are inside libchicken; they are separate only from the point
of view of the Scheme programmer, who needs to use (aka require-extension)
them explicitly so that they don't contaminate the Scheme interaction
namespace.  This is very different from the eggs, which are DLLs.

> I do not know who should take responsibility for DLL Hell.  I think most 
> Windows developers deal with this by being careful to keep their own 
> "known good" DLLs in their own application directories.  Renaming 
> libraries isn't typically the Windows way, but then, Cygwin isn't 
> Windows.

That works well at run time, but is not so good at link time, as
The cyg- prefix is an ugly compromise made necessary because
Cygwin-MinGW cross-compiling is not treated entirely separately,
as other kinds of cross-compilers are.

> Since my motive was just to ensure the Cygwin CMake build 
> works, and it appears to do so, perhaps it's best to let sleeping dogs 
> lie.  At least until a Cygwin culturalist is on hand to make a decision 
> and do the work for Cygwin.

Fair enough.

-- 
"The serene chaos that is Courage, and the phenomenon   address@hidden
of Unopened Consciousness have been known to the        John Cowan
Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan
Brandon J. Van Every scripsit:
> Brandon J. Van Every wrote:
> >felix winkelmann wrote:
> >>
> >>
> >>Here a patch for parameters.scm:
> >>
> >>79,80c79,80
> >>< (define-constant cygwin-default-dynamic-load-libraries 
> >>'("cygchicken-0"))
> >>< (define-constant mingw-default-dynamic-load-libraries 
> >>'("libchicken-0"))
> >>---
> >>>(define-constant cygwin-default-dynamic-load-libraries '("cygchicken"))
> >>>(define-constant mingw-default-dynamic-load-libraries '("libchicken"))
> >>
> >
> >I've pulled this and the other stuff from Darcs.  I've built with 
> >CMake using Cygwin, and the resulting filenames are called 
> >"libchicken".  Probably for the excellent reason that I force that 
> >name on all platforms.  :-)  Is "cyg" instead of "lib" some kind of 
> >common Cygwin convention I'm unaware of, with tools automatically 
> >performing it or some such.  Otherwise, the name "cygchicken" strikes 
> >me as an incorrect convention.  It assumes that Cygwin should be 
> >treated differently than the rest of the universe as far as 
> >nomenclature.  I can imagine historical motives, but are there any 
> >currently valid technical motives?  There are now 2 ways to build on 
> >Cygwin and I don't want to special-case the CMake code unless there's 
> >a good reason.
> >
> >If "cygchicken" is expunged, I assume changes to the ./configure build 
> >will be necessary.
> >
> 
> The Cygwin CMake build of csi, does "csi -R srfi-1" just fine.  So it 
> seems that either cygwin-default-dynamic-load-libraries is not being 
> utilized, or that something somewhere is happy enough to use / convert 
> to "lib" as the prefix.
> 
> I do not know who should take responsibility for DLL Hell.  I think most 
> Windows developers deal with this by being careful to keep their own 
> "known good" DLLs in their own application directories.  Renaming 
> libraries isn't typically the Windows way, but then, Cygwin isn't 
> Windows.  Since my motive was just to ensure the Cygwin CMake build 
> works, and it appears to do so, perhaps it's best to let sleeping dogs 
> lie.  At least until a Cygwin culturalist is on hand to make a decision 
> and do the work for Cygwin.
> 
> 
> Cheers,
> Brandon Van Every
> 
> 
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
> 

-- 
John Cowan                                address@hidden
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR