Re: Manual page and library file

[Gavin Smith]

On Thu, Jan 09, 2025 at 09:46:11PM +0100, Patrice Dumas wrote:
> On Thu, Jan 09, 2025 at 04:27:42PM +0000, Gavin Smith wrote:
> > On Thu, Jan 09, 2025 at 12:40:40AM +0100, Patrice Dumas wrote:
> > > > 2. In Debian we installed the .la files into /usr/lib/texinfo/ until 
> > > > version
> > > > 7.1.1 [3]. For the 7.2 packages [4] I skipped them: I could convert some
> > > > files using texi2any, so no drawbacks visible until now.
> > > > 
> > > > Are these files really needed?
> > > 
> > > I think not, on GNU/Linux and for installed libraries, the dynamic
> > > loading support and use of rpath should make sure that the libraries are
> > > correctly found and loaded even without .la, and in our code we do not
> > > error out if the .la is not found.  In-source and probably for other
> > > platforms the .la are needed.
> > 
> > I don't believe this is correct.
> > 
> > The .la files are needed for loading the XS modules (which is done by the
> > module tp/Texinfo/XSLoader.pm, in 'load_libtool_library').  For example,
> > Parsetexi.la is needed for loading Parsetexi.so.
> 
> Indeed you are right.  For some reason I had imagined that the question
> was only about the lib*.so.* files...
> 
> However, that makes me wonder if we shouldn't try to load directly the
> loadable module if we are not in source.  Indeed, my feeling is that
> dlopened object name should be $module_name.extension, with extension
> correctly guessed in the majority of cases by dl_findfile based on
> $Config{dlext}.
> 

Yes, that's the case for all the XS modules we install.


> This would only require to change load_libtool_library, such that it can
> optionally try to load the module even if the .la file was not found,
> and it would only be triggered if !$Texinfo::ModulePath::texinfo_uninstalled
> and for $module_name (not for $additional_libraries).
> 
> This would make the .la files optional after installation on most
> platforms, with .la only needed when the dlopened files have specific
> names, for instance cygwin and MinGW, I guess.

That makes sense.