* Re: guile 3.0.8: readline does not work - patch with also other fixes
2022-10-04 23:07 ` Mike Gran
@ 2022-10-06 19:13 ` Hannes Müller
2022-10-08 7:30 ` Brian Inglis
0 siblings, 1 reply; 4+ messages in thread
From: Hannes Müller @ 2022-10-06 19:13 UTC (permalink / raw)
To: Mike Gran; +Cc: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread