[tlbuild] Asymptote compile errors on latest OS X (with libc++)

[Richard Koch]

Mojca,

Although I compile the rest of TeX Live on XCode 5.1 using LLVM and Clang (just for the fun of it,
not to be used in the release), I only compile asymptote on Leopard (for 32 bit Intel)
and Snow Leopard (for 64 bit intel). I don't compile a PowerPC version of asymptote.

Dick Koch

On May 12, 2014, at 3:19 PM, Mojca Miklavec <mojca.miklavec.lists at gmail.com> wrote:

> Hi,
> 
> this probably shouldn't be the showstopper as it's not in the official
> set of binaries, but just to let you know that the original asymptote
> 2.28 (as fetched from sourceforge) apparently fails to compile with
> XCode 5.1. This is the error:
> 
> /usr/bin/clang++ -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC
> -D_THREAD_SAFE -pthread -DFFTWPP_SINGLE_THREAD -I/opt/local/include
> -pipe -Os -arch x86_64  -I . -I/opt/local/include/gc -I/usr/include/gc
> -o settings.o -c settings.cc
> In file included from picture.cc:10:
> In file included from ./picture.h:15:
> In file included from ./drawelement.h:19:
> In file included from ./prcfile.h:5:
> In file included from ./prc/oPRCFile.h:41:
> ./prc/writePRC.h:29:10: fatal error: 'ext/slist' file not found
> #include <ext/slist>
>         ^
> 
> See also
>    http://stackoverflow.com/questions/19758400/ext-slist-file-not-found-on-os-x-10-9
> 
> Apparently a valid workaround seems to be
>    export CFLAGS="-stdlib=libstdc++"
> (I don't know why CFLAGS and not CXXFLAGS – maybe it was a typo), but
> that's not the proper way to deal with the issue. The binaries should
> depend on libc++, not on libstdc++ to avoid crashes.
> 
> Sadly I'm not able to test anything as my OS is too old. Maybe Dick
> can help with this one. I find it weird though that he didn't stumble
> upon this issue already.
> 
> 
> And this is one of the many warnings (the same one as thrown by
> Solaris, see below):
> 
> In file included from texfile.cc:11:
> In file included from ./texfile.h:15:
> In file included from ./common.h:35:
> In file included from ./memory.h:39:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_map:212:5:
> warning: Use of the header <ext/hash_map> is deprecated.  Migrate to
> <unordered_map> [-W#warnings]
> #   warning Use of the header <ext/hash_map> is deprecated.  Migrate
> to <unordered_map>
>    ^
> 
> The macro GNUC_PREREQ(4,3) simply doesn't do. Probably there should be
> a ./configure-time test to check for features like this one.
> 
> Mojca
> 
> PS: In contrast to POSIX 2008, both issues here are really "please ask
> your software provider to adapt the code" rather than "please ask your
> OS provider to fix the issues" ;) ;) ;) ;)
> 
> 
> On Wed, Apr 23, 2014 at 11:49 PM, Mojca Miklavec wrote:
>> 
>> However, this error looks really creepy.
>> 
>> In file included from /opt/csw/include/c++/4.8.2/ext/hash_map:60:0,
>>                 from memory.h:27,
>>                 from common.h:35,
>>                 from genv.h:19,
>>                 from genv.cc:20:
>> /opt/csw/include/c++/4.8.2/backward/backward_warning.h:32:2: warning:
>> #warning This file includes at least one deprecated or antiquated
>> header which may be removed without further notice at a future date.
>> Please use a non-deprecated interface with equivalent functionality
>> instead. For a listing of replacement headers and interfaces, consult
>> the file backward_warning.h. To disable this warning use
>> -Wno-deprecated. [-Wcpp]
>> #warning \
>>  ^
>> 
>> It's caused by memory.h. The following chunk of code to be precise:
>> 
>> #ifndef NOHASH
>> #if __GNUC_PREREQ(4,3) || defined(__CYGWIN__)
>> #include <tr1/unordered_map>
>> #define EXT std::tr1
>> #else
>> #define EXT __gnu_cxx
>> #include <ext/hash_map>
>> #define unordered_map hash_map
>> #define unordered_multimap hash_multimap
>> #endif
>> #endif
>> 
>> And then the file "ext/hash_map" complains that it's deprecated. I'm
>> just guessing, but the code above is probably some weird heuristics
>> that could/should be fixed. I got rid of the warnings by commenting
>> everything out and leaving just
>> 
>> #include <tr1/unordered_map>
>> #define EXT std::tr1
>> 
>> but there must be other better ways.
>> 
>> Here are three suggestions:
>> http://gcc.gnu.org/ml/gcc-help/2011-04/msg00015.html. One of them
>> suggests using c++0x.
>