On Sat, Oct 10, 2026 at 10:34:12AM +0200, [email protected] wrote: > On Fri, Oct 09, 2026 at 05:27:32PM +0100, Gavin Smith wrote: > > On Fri, Oct 09, 2026 at 11:11:01AM +0200, [email protected] wrote: > > > When ctexi2any is used, however, Perl is embedded, and there is a need > > > to link with libperl on GNU/Linux and Unices too (since 7.3, March 2026). > > > > As I understand, ctexi2any is still not the default implementation > > of texi2any. If it does become the default implementation, we should try > > to avoid depending on libperl when a Perl interpreter is not needed (for > > example, when a native-code converter is available, as is the case for HTML > > and Info). I am sure there are previous discussions on this so I will try > > to avoid adding more noise. > > I do not think that there are previous discussions on this. > > If "avoid depending on libperl when a Perl interpreter is not needed" > means not linking against libperl when building, but dlopening libperl > before starting the embedded interpreter, I do not think that it is > possible, at least I do not remember anything of the sort from the Perl > documentation. If it was possible, I think that it would be a bad idea, > for the same reason we link "traditionally" against other shared > libraries (iconv, gettext), to use the interface version checking > provided by the linking and shared library loading and to be sure that > the functionalities present at link time are also present at runtime. > > We do not know when we start ctexi2any if an embedded Perl interpreter > will be needed, therefore if a user wants to be able to start an > embedded Perl interpreter if needed, it is better if libperl is built > in. If a user does not want to start a Perl interpreter ever, it is > possible to use the "texistatic" executable which is not linked against > libperl, but I can't image a practical situation where it would be > relevant except maybe on minimal distributions that do not ship Perl at > all, but why would such an minimal distribution need texi2any? We could > add a configure flag such that texistatic is installed as texi2any if > the user want texi2any that does not need libperl to be installed, but > if someone wants to do that she can do it manually.
One possiblity is to detect when texi2any is built and build a restricted version if there is no embedded Perl available. texi2any could give an error message if certain features are requested (e.g. if the output format isn't supported). It may be that demanding the requirements for an embedded Perl interpreter is not onerous but we could check why some distributions didn't have these dependencies installed by default. > Linking against libperl makes sure that ctexi2any won't start if libperl > is not present and a Perl interpreter cannot be embedded when it is > needed at runtime (for init file, for DocBook...). It seems to me to be > the best situation for any user. The cost of linking against libperl is > also probably relatively low. According to my reading of callgrind, > loading of libraries is 0.4% of the texinfo manual conversion to Info > run of ctexi2any. > > -- > Pat
