[tlbuild] Asymptote compile errors on latest OS X (with libc++)
Richard Koch
koch at math.uoregon.edu
Tue May 13 00:25:31 CEST 2014
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.
>
More information about the tlbuild
mailing list