On Tue, Nov 14, 2023 at 04:23:58AM +0100, Bruno Haible wrote:
> Hi,
>
> Apparently some optimization options were still in effect. And indeed,
> the file tp/Texinfo/XS/config.status contains these lines:
>
> S["PERL_CONF_optimize"]="-O2 -g"
>
> Per the GNU Coding Standards [1], when I specify
On Tue, Nov 14, 2023 at 12:50 AM Jeffrey Walton wrote:
>
> On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote:
> >
> > Sam James wrote:
> > > It appears that the obstack gnulib module is the culprit.
> >
> > When I compile texinfo-7.1 in such a way that is uses the obstack facility
> > from
On Mon, Nov 13, 2023 at 10:37 PM Bruno Haible wrote:
>
> Sam James wrote:
> > It appears that the obstack gnulib module is the culprit.
>
> When I compile texinfo-7.1 in such a way that is uses the obstack facility
> from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
> bus
Sam James wrote:
> It appears that the obstack gnulib module is the culprit.
When I compile texinfo-7.1 in such a way that is uses the obstack facility
from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same
bus error as in a build where the obstack facility comes from gnulib.
Hi,
I'm trying to build texinfo-7.1 on Linux/sparc64, in order to debug a problem.
I configured the package with
CC="gcc -fsanitize=undefined" \
CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" \
gl_cv_func_obstack=yes \
../configure --prefix=$HOME/prefix64 \
Gavin Smith writes:
> On Sun, Nov 12, 2023 at 12:41:58PM +0100, John Paul Adrian Glaubitz wrote:
>
>> > diff tree.c.old tree.c -u
>> > --- tree.c.old 2023-11-04 16:15:13.632755680 +
>> > +++ tree.c 2023-11-04 16:16:36.211072521 +
>> > @@ -43,7 +43,10 @@
>> >if
On Sun, Nov 12, 2023 at 12:41:58PM +0100, John Paul Adrian Glaubitz wrote:
> > diff tree.c.old tree.c -u
> > --- tree.c.old 2023-11-04 16:15:13.632755680 +
> > +++ tree.c 2023-11-04 16:16:36.211072521 +
> > @@ -43,7 +43,10 @@
> >if (obs_element_first)
> > obstack_free
On Mon, Nov 13, 2023 at 10:28:35AM +0100, Patrice Dumas wrote:
> According to your mail
> https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html
>
> char32_t is less portable, and indeed, the solaris automatic build sees
> to fail because of char32_t is not available, while
On Sat, Nov 11, 2023 at 11:54:52PM +0100, Bruno Haible wrote:
>
> These types are all identical. Therefore you don't even need to cast.
>
> - char32_t comes from (ISO C 11 or newer).
> - ucs4_t comes from GNU libunistring.
> - uint32_t comes from .
According to your mail
