[tlbuild] Compiling asy with recent gcc

[John Bowman]

Hi Ken,

I have a cygwin installation so I updated it and checked both the usual
w32api build and the UNIX build
with gcc-9.2.0. The w32api build works fine but I was able to reproduce the
problem using a normal UNIX build.

Based on the fact that only replacing stable_sort with sort on line 286 of
arrayop.h made the error disappear
but only forcing compare2<T> to return true did not, it was starting to
look like a bug in the STL stable_sort
routine. But then I realized that I had inadvertently compiled against
version 8.0.4 of the Boehm gc garbage collector
and I know that that version doesn't work under cygwin. The latest working
version is 7.6.2, as you will
notice in the file build-scripts/build-asymptote.dos. So I recompiled with
that and everything is fine. A simple test is:

./asy -dir base
 sort(new string[][] {{"a","9"}});

Or you can just run
make check

So this is a problem with Boehm gc under cygwin; just switch to version
7.6.2 and you should be fine:

make clean
./configure --enable-gc=7.6.2

Regards,

-- John

On Thu, Mar 5, 2020 at 7:45 PM Ken Brown <kbrow1i at gmail.com> wrote:

> On 3/5/2020 6:53 PM, Nelson H. F. Beebe wrote:
> > Ken Brown <kbrow1i at gmail.com> reports a failure in building Asymptote
> > on Cygwin with gcc-9.2.0 (newly upgraded from gcc-7.4.x):
> >
> >>> When I build asy with this compiler it crashes in the sort2 test.
> >>> Running the test under gdb shows that there's a null pointer
> >>> dereference in GC_free (hhdr is null). If I build without
> >>> optimization, the problem doesn't occur.
> >
> > I just scanned all of the asy executables available at
> >
> >      http://www.math.utah.edu/pub/texlive-utah/bin
> >
> > and found that TeX Live 2020 for these files were built with a gcc-9.x
> >>> compiler:
> >
> >      amd64-clonos19/asy              GCC: (FreeBSD Ports Collection)
> 9.2.0
> >      amd64-freebsd130/asy            GCC: (FreeBSD Ports Collection)
> 9.2.0
> >      amd64-hardenedbsd13/asy         GCC: (FreeBSD Ports Collection)
> 9.1.0
> >      x86_64-arco19/asy               GCC: (GNU) 9.2.0
> >      x86_64-blackarch/asy            GCC: (GNU) 9.2.0
> >      x86_64-budgie1910/asy           GCC: (Ubuntu 9.2.1-9ubuntu2) 9.2.1
> 20191008
> >      x86_64-centos8/asy              GCC: (GNU) 9.1.1 20190605 (Red Hat
> 9.1.1-2)
> >      x86_64-fedora30/asy             GCC: (GNU) 9.2.1 20190827 (Red Hat
> 9.2.1-1)
> >      x86_64-fedora31/asy             GCC: (GNU) 9.2.1 20190827 (Red Hat
> 9.2.1-1)
> >      x86_64-kali-2/asy               GCC: (Debian 9.2.1-25) 9.2.1
> 20200123
> >      x86_64-kaos2020/asy             GCC: (GNU) 9.2.0
> >      x86_64-manjaro19/asy            GCC: (GNU) 9.2.1 20200130 GCC:
> (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130
> >      x86_64-openmandriva41-clang/asy GCC: (GNU) 9.2.1 20191109
> (OpenMandriva) GCC: (GNU) 9.2.1 20191207 (OpenMandriva)
> >      x86_64-openmandriva41/asy       GCC: (GNU) 9.2.1 20191109
> (OpenMandriva) GCC: (GNU) 9.2.1 20191207 (OpenMandriva)
> >      x86_64-opensusetw2/asy          GCC: (SUSE Linux) 9.2.1 20190903
> [gcc-9-branch revision 275330]
> >      x86_64-oracle8/asy              GCC: (GNU) 9.1.1 20190605 (Red Hat
> 9.1.1-2)
> >      x86_64-slackware15/asy          GCC: (GNU) 9.2.0
> >      x86_64-trident-void-linux/asy   GCC: (GNU) 9.1.0 GCC: (GNU) 9.2.0
> >      x86_64-ubuntu1910/asy           GCC: (Ubuntu 9.2.1-9ubuntu2) 9.2.1
> 20191008
> >      x86_64-ubuntu2004/asy           GCC: (Ubuntu 9.2.1-21ubuntu1) 9.2.1
> 20191130
> >
> > With rare exceptions, I do not supply optimization levels when I build
> > TeX Live snapshots, and I don't install a build at the above URL if
> > there are segmentation faults in the build.
> >
> > Thus, I'm surprised by Ken's report, and it looks like something that
> > we need to figure out what is happening.
> >
> > Ken's report didn't mention the Asymptote version. As of yesterday's
> > source tree update, it is 2.64.  Almost all of my builds, except for
> > the NetBSD systems, have been with Asymptote version 2.62 or 2.63.
> >
> > ----------------------------------------
> >
> > P.S. I note that gcc-8.4.0 was officially released yesterday, and many
> > O/S distributions allow installation of multiple major versions of gcc
> > and clang, without name conflicts.  I typically install all of them on
> > our test lab machiens, and I've done thousands of builds of gcc and
> > scores of clang, from source code on our systems.  Thus, that
> > compiler, if available on Cygwin, would be an alternative.  It is
> > already in the Ubuntu 20.04 package system, as I found when I updated
> > one of our 20.04 systems this morning.  Its announcement claimed
> > over 200 bug fixes compared to gcc-8.3.0.
>
> Thanks, Nelson, and thanks to everyone else who replied.  It seems that
> this
> issue is specific to the Cygwin build of gcc-9.2.0.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tlbuild/attachments/20200306/3ddce41b/attachment.html>