On Wed, Aug 27, 2025 at 01:30:19AM +0200, Bruno Haible wrote: > Patrice Dumas wrote: > > > I have put together some minimal test cases to show the problem. Perhaps > > > you could test them and confirm that the problem occurs, before reporting > > > to the libtool developers? > > > > I have no better mean to do that... In particular, the CI is not much > > usable for such tests. > > It is possible to use GitHub CI machines for testing of work-in-progress > code. I use it routinely in this way [1]. Basically, I've omitted the > 'build-tarball' step, and instead am committing into that scratch git > repository exactly the files and command that I wish to test.
I reused your code to do something similar. Then I added tests based on Gavin code: https://github.com/gnu-texinfo/ci-scratch It reproduces Gavin findings on OpenBSD. To reproduce the failure of cygwin (and mingw on cygwin) I added a variant where the second library is in a different directory than the dlopened library, which is more like the actual situation of Texinfo. This is consistent with what Eli explained on how libraries are found in windows. Macos also fails. For now this does not affect Texinfo CI, since the iconv on macos is found to be deficient, such that only simple XS is used, that do not need the Texinfo libraries. If this iconv issue disappears some day, most likely there will be similar failures on macos with the Perl SWIG interface. I am not sure what the next step should be. I do not know if it is interesting to report to libtool, to get their advice on what should work, and maybe try to help to have it in the libtool documentation in some way. We could also go another way, for example by postprocessing the SWIG code such that the Texinfo XS loader used instead of Dynaloader bootstrap. As a side note, I am still unconvinced that it is practical to do that in the github CI, doing the same in a shell is much easier. -- Pat
