GCL and dependencies on cygwin

[Camm Maguire]

Greetings, and thank you so much for your helpful reply!

Brian Inglis via Cygwin wrote:

> On 2025-03-09 08:16, Camm Maguire via Cygwin wrote:
> > Greetings, and thank you all for your work on this system.
> > 1) I am preparing a set of GCL releases, both of which basically work on
> > latest cygwin, but the signal handling seems to have been recently
> > broken.  Specifically, GCL can trap and handle SIGFPE when these
> > exceptions are enabled.  Under gdb, the signal appears, but then a
> > SIGTRAP is caught in kernel.dll under secure_getenv(), and the handler
> > is never called.  Thoughts?
> 
> Which release?
> 
>                       $ uname -srvmo
> 
> If current stable 3.5.7, try the latest 3.6.0-0.42?.g* test releases, which have 
> a number of signal handling fixes and improvements, still being reworked to 
> conform to more specs and expected operation, with hundreds of 
> processors/threads, and thousands of concurrent processes/threads used at some 
> large European research institutes.
>

This was stable (3.5.7), but I've retried with latest testing (.423) and
the problem persists.  Given secure_getenv in the backtrace, I'm
wondering if there is some sort of permissions issue here?  Don't know
if there is a direct analog of su/sudo, but tried opening a terminal or
emacs as 'administrator' and no luck.  As I mentioned before, as memory
serves, this worked in the past, i.e. several years ago.

> > 2) I am considering volunteering as a maintainer.  I see the docs
> > describing the procedure.  I maintain some packages for Debian, and
> > wondering if there was any simplification in avoiding duplicate work
> > here.
> 
> Some Cygwin packagers/maintainers also develop or support the packages on other 
> distros.
> 
> Cygwin has some common heritage from Fedora like policies, similar to DFSG, 
> package naming, and usages like -devel and -debuginfo vs -dev or -dbg, but 
> *cygport* is closer to Gentoo portage ebuilds, implemented in bash, and for some 
> packages can do a lot of rote grunt work for you, that you have to explicitly 
> define for Debian etc.
> 
>                       https://cygwin.com/git/cygwin-packages/
> 
> for example:
> 
>                       https://cygwin.com/git/?p=git/cygwin-packages/clisp.git;a=summary
> 
>                       https://cygwin.github.io/cygport/toc_index.html
> 
> or install cygport and access:
> 
>                       $ cygstart /usr/share/doc/cygport/html/manual/toc_index.html
> 
> which should open the docs in your default Windows browser.
> 
> For new ports or modernizing adopted packages, I hacked a script to check Fedora 
> and OpenSuSE sources for spec files, download if not already available locally, 
> and do a "good enough" ~90% conversion to cygport.
> 
> So far, for only a few Debian sources, I found it easier to download the debian/ 
> directory, cat or cp the relevant files (mostly dsc, control, and rules) then 
> cygport-ize or Cygwin-ize the contents.
> But you may find it helps you adapt if you hack your own download and conversion 
> script in your favourite associative memory language.
> 
> I have also found Fedora, OpenSuSE, and Debian sources useful for patches.
> 
> In general, these topics are best discussed on cygwin-apps, to which all 
> packagers, maintainers, and contributors are expected to subscribe.
>

Thanks so much -- I will carry this conversation there.  But in general
the first step is the same, i.e. to upload sources to a pubic area and
get approval from an existing maintainer?

Take care,
-- 
Camm Maguire			     		    camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah