[tlbuild] asy on Macintosh

Richard Koch koch at uoregon.edu
Fri Mar 29 12:39:53 CET 2019


Mojca,

Here are comments on your email about asy. I go on and on because I don't know enough to leave stuff out.



1) Boehm Garbage Collector

I tried compiling asy in the TeX Live Build System on both Sierra and Mojave, and both failed with the same error. So I downloaded the stand alone asy code from  Bowman's site and it also failed to compile with these errors. The errors involve C++, which I know nothing about.

------------------------

Build/include/gsi -I/Users/koch/AsymptoteBuild/include/readline -I. -Igc-8.0.2/include -I/usr/include/tirpc -std=c++11 -g -O3 -o util.o -c util.cc
g++ -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC  -D_THREAD_SAFE -pthread -DFFTWPP_SINGLE_THREAD -I/Users/koch/AsymptoteBuild/include -I/Users/koch/AsymptoteBuild/include/gsi -I/Users/koch/AsymptoteBuild/include/readline -I. -Igc-8.0.2/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:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/map:1577:27: error: no matching member function for call to
      'select_on_container_copy_construction'
          __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();
       ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:1582:9: note: candidate function not viable: no known
      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 *>>' for 1st argument
        select_on_container_copy_construction(const allocator_type& __a)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:1723:9: note: candidate function not viable: requires 2
      arguments, but 1 was provided
        select_on_container_copy_construction(true_type, const allocator_type& __a)
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:1727:9: note: candidate function not viable: requires 2
      arguments, but 1 was provided
        select_on_container_copy_construction(false_type, const allocator_type& __a)
        ^
1 error generated.
make: *** [settings.o] Error 1

-------------------

I looked at memory.h, which turned out to refer to the Boehm garbage collector, and it loaded "map" from the Mac. This is the information I sent to John Bowman, who wrote back that he had hoped issues with the garbage collector were fixed and he could update, but perhaps not. Then he gave me a flag to revert to the earlier Boehm version and these errors did not occur.

I don't know what might be different in MacPorts because I deliberately don't install non-Mac compiling stuff on this machine. I did look at the Boehm site and was surprised that I didn't find notes about this compile problem.

That's all I know about it. If there is a better grip on why I ran into this problem, then I'd be happy to test, but I'm hoping to spend time on more fruitful issues(!!).
Note that 10.6 is a long time ago; it would not be surprising if Apple's system got more picky about C++ issues.




2) Building GLEW. 

As far as I understand, GLEW doesn't add new features to OpenGL, but is simply a Library to determine if features are present. John wrote me a short note suggesting that it could be removed from the build code. Here's that note.

------------------
Yes, I remember seeing those same posts about glew under MacOS. It could well be that you can simply omit the header, library linking, and this code from glrender.cc:

glewExperimental = GL_TRUE;

  int result = glewInit();

  if (result != GLEW_OK) {
    cerr << "GLEW initialization error." << endl;
    exit(-1);
  }

If that works, that would be easier than for Mac users to have to install libGLEW. Let me know if you have a chance to test this.
---------------------

But by that time I had the library code, so I didn't bother.

Building was simple. I downloaded the code from http://glew.sourceforge.net. I then tried "./configure", but there was no such thing. So I just ran "Make" and then "sudo make install". All this worked in a straightforward way. The only trouble was that the results ended up in /usr/local. I had renamed all the folders there, so I easily saw that this operation only produced new folders named /include and /lib.

Some time ago, Karl suggested that it would be easier to keep the libraries I build for asy in a folder in my home directory, and that's what I do. Then I only have to rebuild these libraries once a year, and I know that they don't interfere with other Mac software. So I copied the GLEW files from /usr/local to that folder in my home directory, erased the GLEW folders in /usr/local, and renamed everything else. I only kept the static library, libGLEW.a, and placed it in /lib in my local folder. The includes were slightly trickier. They were in /include/GL and there are three files. I moved this entire GL folder to my local /include, but that didn't work. For some reason, I decided to rename the folder OpenGL and that worked. So those three include files are in /include/OpenGL in my local stuff.


3) Other issues:

I see that you haven't run into glrender.cc:1266 yet. It has an easy fix. I also see that you ran into -lgccpp and fixed it as I did, with help from John. I still have no idea what that library does.


Richard Koch
koch at uoregon.edu






More information about the tlbuild mailing list