On Mon, Nov 06, 2023 at 07:52:40PM +0100, Andreas Schwab wrote:
> On Nov 06 2023, Gavin Smith wrote:
>
> > $ readelf -d /usr/local/lib/texinfo/ConvertXS.so | grep RUNPATH
> > 0x001d (RUNPATH)Library runpath:
> > [/usr/local/lib/texinfo]
> >
> > It still seems to be checki
On Nov 06 2023, Gavin Smith wrote:
> $ readelf -d /usr/local/lib/texinfo/ConvertXS.so | grep RUNPATH
> 0x001d (RUNPATH)Library runpath:
> [/usr/local/lib/texinfo]
>
> It still seems to be checking the other locations first, though.
Unlike DT_RPATH, DT_RUNPATH does not ov
On Mon, Nov 06, 2023 at 06:46:02PM +0100, Andreas Schwab wrote:
> On Nov 06 2023, pertu...@free.fr wrote:
>
> > It is pkglibdir. Would be easy to change Makefile.am to put them there,
> > but are we sure that the linker will find them when the dlopened *XS
> > files are loaded by perl?
>
> libto
On Mon, Nov 06, 2023 at 02:25:20PM +0100, pertu...@free.fr wrote:
> It is pkglibdir. Would be easy to change Makefile.am to put them there,
> but are we sure that the linker will find them when the dlopened *XS
> files are loaded by perl?
The straightforward way of doing this seems to me to be to
On Nov 06 2023, pertu...@free.fr wrote:
> It is pkglibdir. Would be easy to change Makefile.am to put them there,
> but are we sure that the linker will find them when the dlopened *XS
> files are loaded by perl?
libtool adds an rpath when linking against it.
--
Andreas Schwab, sch...@linux-m6
> Date: Mon, 6 Nov 2023 14:25:20 +0100
> From: pertu...@free.fr
> Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
>
> > Do these two replace the several *XS shared libraries we had until
> > Texinfo 7.1, or are they in addition to them?
>
> There are new *XS shared libraries in additions to tho
On Mon, Nov 06, 2023 at 02:37:57PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 6 Nov 2023 09:20:37 +0100
> > From: pertu...@free.fr
> > Cc: Gavin Smith , bug-texinfo@gnu.org
> >
> > libtexinfo corresponds to the 'pure' C common code that performs the
> > computations needed for texi2any, working on
> Date: Mon, 6 Nov 2023 09:20:37 +0100
> From: pertu...@free.fr
> Cc: Gavin Smith , bug-texinfo@gnu.org
>
> On Sun, Nov 05, 2023 at 09:59:44PM +0200, Eli Zaretskii wrote:
> >
> > I don't have any libtexinfo shared library here, and I don't see one
> > being built, let alone installed, as part of
On Sun, Nov 05, 2023 at 09:59:44PM +0200, Eli Zaretskii wrote:
>
> I don't have any libtexinfo shared library here, and I don't see one
> being built, let alone installed, as part of Texinfo. is this
> something new in the development sources? If so, what code is linked
> into libtexinfo?
Yes,
On Sun, Nov 05, 2023 at 09:59:44PM +0200, Eli Zaretskii wrote:
> The XS modules are installed in a directory which is usually not
> looked into by the dynamic linker. Is that what you are talking
> about? If so, we have been using "non-public libraries" since long
> ago, no? Or what am I missing
> From: Gavin Smith
> Date: Sun, 5 Nov 2023 18:12:45 +
> Cc: pertu...@free.fr, bug-texinfo@gnu.org
>
> So you know what a dynamically loaded library is; this contains a collection
> of functions and potentially data structures that can be loaded by running
> code and run as part of a computer
On Sun, Nov 05, 2023 at 07:52:53PM +0100, Andreas Schwab wrote:
> On Nov 05 2023, Gavin Smith wrote:
>
> > The dynamically loaded libraries used by texi2any (XS modules) are
> > completely different. Technically, they are loaded in the same way,
> > by the running Perl interpreter. But they are
On Nov 05 2023, Gavin Smith wrote:
> The dynamically loaded libraries used by texi2any (XS modules) are
> completely different. Technically, they are loaded in the same way,
> by the running Perl interpreter. But they are an integral part of the
> texi2any program. They are intended for the use
On Sun, Nov 05, 2023 at 07:38:27PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Sun, 5 Nov 2023 17:04:47 +
> >
> > > Maybe one day libtexinfo could be a public library, but not for now
> > > and libtexinfoxs should probably never ever be a public library.
> >
> > I agree neith
> From: Gavin Smith
> Date: Sun, 5 Nov 2023 17:04:47 +
>
> > Maybe one day libtexinfo could be a public library, but not for now
> > and libtexinfoxs should probably never ever be a public library.
>
> I agree neither of them should be a public library now.
Can someone please explain what d
On Sun, Nov 05, 2023 at 05:16:44PM +0100, Patrice Dumas wrote:
> On Sat, Nov 04, 2023 at 10:58:35PM +, Gavin Smith wrote:
> >
> > Bingo. /usr/local/lib/libtexinfo.so.0 is being run. It shouldn't even
> > be installed directly in /usr/local/lib.
>
> I could not find a way to make the libtexi
On Sat, Nov 04, 2023 at 10:58:35PM +, Gavin Smith wrote:
>
> Bingo. /usr/local/lib/libtexinfo.so.0 is being run. It shouldn't even
> be installed directly in /usr/local/lib.
I could not find a way to make the libtexinfo and libtexinfoxs libraries
'internal' only. Maybe use noinst_LTLIBRARI
I have just had a frustrating time trying to work out why none of
the changes I was making to the parsetexi module were taking effect.
For example, the same debugging messages were still being printed even
though I had effaced all instances of them from the source code.
I suspected that installed
18 matches
Mail list logo
