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

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

[Hannes Müller]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

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.

With attached proposed 3.0.8-2.src, I fixed not only readline support
but also:
- gettext-devel and libgc-devel added to BUILD_REQUIRES
- libgmp-devel added to libguile3_0_devel_REQUIRES
- Removed --includedir=/usr/include/guile/3.0 from CYGCONF_ARGS since
it resulted in /usr/include/guile/3.0/guile/3.0. So in fact --
includedir should be only /usr/include, which is the default

Since I personally prefer implicit over explicit, I also removed all
default settings from CYGCONF_ARGS. But this fully depends on your
point of view.

Since I found no related Cygwin git package repository for guile3.0,
attached a related tar.gz file.

Thanks!

Hannes

[-- Attachment #2: guile3.0-3.0.8-2.src.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 4287 bytes --]

Re: 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

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

[Hannes Müller]

[-- Attachment #1: Type: text/plain, Size: 6667 bytes --]

Hello Mike,

Really interesting to get your contact!

The short answer to your questions is, for guile-readline in fact '-
avoid-version' is the appropriate fix. The related Makefile.am has no
'-version-info' or '-release' option, so always the same shared library
file name will be generated. Futhermore, the related library is
installed in usr/lib/guile/3.0/extensions and so it already resides
under guile 'major-version.minor-version'.  All other shares libraries
generated within guile 3.0 are already with '-avoid-version', so this
one was missing.

But in fact libtool support could be better. Unfortunately the related
real shared library name in general cannot be generated from the
provided name in dynamic-link etc. itself. So in fact additional
information is required. To have a backward compatible interface, in
the attached test suite in README I made a detailed proposal how this
can be solved. The idea is to provide optional arguments #:lt-version
or  #:lt-release to e.g. dynamic-link, load-extension, load-foreign-
library. The test suite should allow to run on all platform and you can
directly see the effect of '-version-info' or '-release' option. I hope
the information contained fully answers your questions. Otherwise come
back to me. The test suite gives no implementation of the modified
interface, but allows to test it. Implementation in guile should be
straightforward. File names to be generated are unambiguous, no
fallsbacks etc. are required.

I ported guile 3.0.8 to MSYS
(https://packages.msys2.org/package/guile?repo=msys&variant=x86_64). Th
ere are some additional MSYS specific patches (03*). But these are not
required to be upstream. MSYS is in the process to behave like Cygwin,
so hopefully in not too far future these patches will become obsolete.
By the way the 0101* patch extends your lib->cyg also by lib->msys. But
also this should become obsolete in the future.

What I really care, is to bring the 000* patches upstream. I know some
people consider '-Wconversion' not usefull, but compiler folks provide
it, I like it too and guile 1.8 - 2.2 give no related warnings.
Therefore, I argue guile 3.0 should show the same behavior. I consider
also 02* patches should be considered/reviewed to be upstream.
 
I struggled some time to compile guile 3.0 on MSYS, so I took a look at
Cygwin. The following line looks quite like a 'hack' but it was the
solution to my problems to fix Makefiles:

# workaround since both --enable-lto and --disable-lto fail
find . -name Makefile -exec sed -i -e "s/-flto//" {} \;

Do you know the reason behind? And will there be a cleaner solution
using standard techniques to get this compiled?

Greetings,
Hannes

Content of README from attached .tar.gz:

Proposal for guile cross platform libtool support:
Extend dynamic-link, load-extension, load-foreign-library etc. since
libtool modifies shared library file names depending on -version-info
and
-release platform specific. So the only portable solution is to provide
this
information as optional arguments. 

This is a test suite to test a related modified guile.

autoreconf
./configure && make && make check || cat ./test-suite.log

Proposal as follows:
So far only libfoo1 passed on e.g. Cygwin, but all on Linux due to
symlinks.
With the an inferface as follows, all platforms should be able to pass.
(dynamic-link ".libs/libfoo1")
(dynamic-link ".libs/libfoo2" #:lt-version "3:12:1")
(dynamic-link ".libs/libfoo3" #:lt-release "20.21.22")
(dynamic-link ".libs/libfoo4-20.21" #:lt-version "3:12:1")

File names generated are as follows:
libfoo1_la_LDFLAGS = -avoid-version
# cygwin: cygfoo1.dll
# mingw: libfoo1.dll
# linux: libfoo1.so

libfoo2_la_LDFLAGS = -version-info 3:12:1
# cygwin: cygfoo2-2.dll
# mingw: libfoo2-2.dll
# linux: libfoo2.so.2.1.12, 
 libfoo2.so -> libfoo2.so.2.1.12 
 libfoo2.so.2 -> libfoo2.so.2.1.12

libfoo3_la_LDFLAGS = -release 20.21.22
# cygwin: cygfoo3-20-21-22.dll
# mingw: libfoo3-20-21-22.dll
# linux: libtest-ffi-20.21.22.so
 libtest-ffi.so -> libtest-ffi-20.21.22.so

syntactically is should be also accepted
'#:lt-version "3:12"' or '#:lt-version "3"'
'#:lt-release "20"' or '#:lt-release "20.21.22.1.2.3.4.5.6"' i.e.
points will be
converted to minus on Cygwin, MinGW 

Info:
https://www.gnu.org/software/libtool/manual/libtool.html#Versioning

-version-info current[:revision[:age]]
Default value for current, revision and age is 0.

The actual file name for the shared librariy is calculated as follows:
x = current - age
y = age
z = revision

resulting in file names on e.g. Linux:
libfoo.so -> libfoo.so.x.y.z
libfoo.so.x -> libfoo.so.x.y.z
libfoo.so.x.y.z

and on Cygwin: cygfoo-x.dll
on MinGW: libfoo-x.dll


Am Dienstag, dem 04.10.2022 um 16:07 -0700 schrieb 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


[-- Attachment #2: guile-foo-foreign-0.0.2.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 375577 bytes --]

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

[Brian Inglis]

Hi folks,

On my system with over 2K Cygwin packages installed, of which over 900 
are named lib..., there are over 750 simple cygP-[0-9]+.dll including 
cygPV-[0-9]+.dll, over 250 compound version cygPV-M-m.dll, and about 80 
with no -, including about 64 semantic versions:

cygicudata56...70.dll
cygicui18n56...70.dll
cygicuio56...70.dll
cygicuuc56...70.dll
cygicule56.dll
cygicule57.dll
cygiculx56.dll
cygiculx57.dll
cygicutest70.dll
cygicutu70.dll
cygperl5_32.dll
cygruby260.dll

about 16 likely current - age ABI versions:

cygcatgets1.dll
cygfreebl3.dll
cygfreeblpriv3.dll
cyghistory7.dll
cygnspr4.dll
cygnss3.dll
cygnssdbm3.dll
cygnssutil3.dll
cygplc4.dll
cygplds4.dll
cygreadline7.dll
cygsmime3.dll
cygsoftokn3.dll
cygssl3.dll
cygusb0.dll

about a half dozen with no versions:

cyggvfscommon.dll
cyggvfsdaemon.dll
cygnativeGLthunk.dll
cygregina.dll
cygtxc_dxtn.dll
cygz.dll

and the one to rule them all:

cygwin1.dll

The intensely curious can download over 170GB compressed tars and scan 
the over 12000 binary packages available for DLLs. ;^>

-- 
La perfection est atteinte,
non pas lorsqu'il n'y a plus rien à ajouter,
mais lorsqu'il n'y a plus rien à retirer.
	-- Antoine de Saint-Exupéry