[tlbuild] asy on Macintosh

[John Bowman]

Maybe the best solution is to add a configure check for GC_throw_bad_alloc:
              AC_CHECK_LIB([gccpp],[GC_throw_bad_alloc])
Does that work reliably for everyone?

On Fri, Mar 29, 2019 at 8:07 AM Mojca Miklavec <
mojca.miklavec.lists at gmail.com> wrote:

> Hi,
>
> On Fri, 29 Mar 2019 at 14:03, Richard Koch wrote:
> >
> > WARNING
> >
> > At Mojca's urging, I downloaded gc 8.0.4. Then I directly used
> .configure and make to build the library on the Mac. No problems.
> >
> > Then I added gc-8.0.4.tar.gz to the asy source in TeX Live and added a
> configure flag to use this version. The asy .configure log says it was used.
> >
> > When compiling, I got exactly the same C++ errors as before. Mojca seems
> to compile either using macOS 10.6 or else using MacPorts. I do not believe
> this version of gc can be used with the current code when compiled on
> current Macs (and here "current" means Sierra and beyond, so for the last
> three years). Whether gc or asy is ultimately at fault I cannot say.
>
> I tried to build on 10.13 and I get the same error now (using the same
> build script as on 10.6).
>
> I forgot to mention that I compiled with clang 7.0 on 10.6, but
> building with that compiler doesn't help on 10.13 either.
>
> Btw: libatomic_ops also has a newer version, 7.6.10.
>
> Henri posted some patches earlier, but those were for different files
> & errors, I believe.
>
> Here's the error on 10.13 (the same one as Dick experienced):
>
> /opt/local/bin/clang++-mp-7.0 -stdlib=libc++ -Wall -DHAVE_CONFIG_H
> -D_FILE_OFFSET_BITS=64 -DUSEGC  -D_THREAD_SAFE -pthread
> -DFFTWPP_SINGLE_THREAD  -I. -Igc-8.0.4/include -I/usr/include/tirpc
> -std=c++11 -g -O3 -o settings.o -c settings.cc
> In file included from settings.cc:18:
> In file included from ./common.h:35:
> In file included from ./memory.h:13:
> /opt/local/libexec/llvm-7.0/include/c++/v1/map:1664:65: error: no
> viable conversion from 'gc_allocator<std::__1::__value_type<const
> sym::symbol,
>       trans::tyEntry *>>' to 'const gc_allocator<std::__1::pair<const
> sym::symbol, trans::tyEntry *>>'
>
> __alloc_traits::select_on_container_copy_construction(__m.__tree_.__alloc()))
>
> ^~~~~~~~~~~~~~~~~~~~~
> ./memory.h:148:14: note: in instantiation of member function
> 'std::__1::multimap<const sym::symbol, trans::tyEntry *,
> std::__1::less<const sym::symbol>,
>       gc_allocator<std::__1::pair<const sym::symbol, trans::tyEntry *>
> > >::multimap' requested here
> GC_CONTAINER(multimap);
>              ^
> ./env.h:61:8: note: in instantiation of member function
> 'sym::table<trans::tyEntry *>::collapseScope' requested here
>     te.collapseScope(); ve.collapseScope();
>        ^
> gc-8.0.4/include/gc_allocator.h:152:3: note: candidate constructor not
> viable: no known conversion from
> 'std::__1::__tree<std::__1::__value_type<const
>       sym::symbol, trans::tyEntry *>,
> std::__1::__map_value_compare<const sym::symbol,
> std::__1::__value_type<const sym::symbol, trans::tyEntry *>,
>       std::__1::less<const sym::symbol>, true>,
> gc_allocator<std::__1::__value_type<const sym::symbol, trans::tyEntry
> *> > >::allocator_type' (aka
>       'gc_allocator<std::__1::__value_type<const sym::symbol,
> trans::tyEntry *> >') to 'const gc_allocator<std::__1::pair<const
> sym::symbol, trans::tyEntry
>       *> > &' for 1st argument
>   gc_allocator(const gc_allocator&) GC_NOEXCEPT {}
>   ^
> /opt/local/libexec/llvm-7.0/include/c++/v1/memory:1604:69: note:
> passing argument to parameter '__a' here
>         select_on_container_copy_construction(const allocator_type& __a)
>                                                                     ^
> 1 error generated.
>
>
> I can try to figure out what's different in case asy gets built from
> within MacPorts.
>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tlbuild/attachments/20190331/f83fc64e/attachment.html>