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