guile 3.0.8: readline does not work - patch with also other fixes

[Mike Gran]

On Tue, Oct 04, 2022 at 08:06:00PM +0200, Hannes M�ller wrote:
> Hi Guile-Maintainer,
> Hi Marco Atzeri,
> 
> with e.g. guile 3.0.8-1 I noticed serveral problems.
> 
> Most important one is not working readline support. You may check in
> guile via e.g.:
> (begin (use-modules (ice-9 readline))(activate-readline))
> 
> With e.g. guile3.0-3.0.8-1.src the shared library guile-readline-0.dll
> is created on Cygwin but guile-readline.dll is expected. This results
> from guile since 3.0.6 does not load foreign libraries via libltdl.

Hannes-

Hi. I can speak speak for upstream Guile on that, I guess.  When the
core Guile maintainers dumped libltdl, I was the one that wrote the
Guile code that converted GNU/Linux shared object names to Cygwin DLL
names, and I forgot to properly account for version numbers in Cygwin
DLL names.

 The code that does "libfoo.so" to "cygfoo.dll"...

On Linux, "libfoo.so" is usually a link to a more specific
"libfoo.so.x" so Guile doesn't have to search for the most recent
revision.

I could change that code so that the code that searches for "libfoo.so"
actually searches for anything named "cygfoo.dll" and "cygfoo-??.dll",
but I'd need someone on Cygwin to explain to me how that search should
be.  Is the '??' in cygfoo-?? always numeric?  How many digits can
it be?  I'm assuming the highest number has priority.

Should "cygfoo.dll" outrank "cygfoo-1.dll", or is it the opposite?

Is there some Cygwin library function that will do this search for me
that I should know about?

As for the other patches to upstream Guile, if no one else is
working on it, I'll see what I can do.

But in the meantime, if Cygwin wants to incorporate your patch
to '-avoid-version' in guile-readline, that's the best solution
for 3.0.8.

Thanks,

Mike Gran