<tr1/memory> does not exist on OSX Mavericks

[GoogleCodeExporter]

# What steps will reproduce the problem?
1. Configure a build on OSX Mavericks without "-std=c++11" in the cflags
2. Try to build

#What is the expected output? What do you see instead?
Error: <tr1/memory> file does not exist

# What version of the product are you using? On what operating system?
Alembic 1.5.1, OSX Mavericks (verison 10.9)

# Please provide any additional information below.
When forcing "-std=c++11" into the build by adding:
ADD_DEFINITIONS( "-std=c++11" )
to the CMakeLists.txt, the build starts to work, though I run into the same 
error as Issue 315 when building AbcCoreOgawa.

Original issue reported on code.google.com by blackencino on 25 Oct 2013 at 7:35

[GoogleCodeExporter]

Does a shared_ptr exist somewhere else without the "-std=c++11"

Or is this the ONLY way now to get these newer features? (without resorting to 
an external dependecy like boost)

Original comment by miller.lucas on 25 Oct 2013 at 7:45

• Changed state: Accepted

[GoogleCodeExporter]

Also, what is the default compiler with OSX Mavericks?

Original comment by miller.lucas on 25 Oct 2013 at 7:48

[GoogleCodeExporter]

Yep, anything that was in <tr1/*> is just <*>.  So use <memory>. This
should work elsewhere also.

The default compiler is clang. There is no gcc, but for a little bit of
backwards compatibility, they've made the "gcc" executable just point to
clang.   It is the same setup as the one in issue 315.

clang++ reports __cplusplus as 1997somethingish without "-std=c++11", but
201103 with "-std=c++11".

Original comment by blackencino on 25 Oct 2013 at 7:51

[GoogleCodeExporter]

Hello ,
I am having the same problem, but strangely with different arch.
I am using Xcode 5.0 and Cmake 2.8.12 . That is the actual compiler the new 
Xcode uses: 
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

If I compile against x86_64 MacOSX 10.8 it compiles without a single problem. 
If I try to compile against armv7 or i386 I get this: 

/Users/sabotage3d/DEV/libs/alembic-1.5.1/lib/Alembic/Util/Foundation.h:45:10: 
fatal error: 'tr1/memory' file not found
#include <tr1/memory>

The have attached the whole output for target AlembicUtil.

Is there a way to force std without C++11 support or boost in the Foundation.h ?

Thanks,

Alex

Original comment by sabotag...@gmail.com on 26 Oct 2013 at 12:33

Attachments:

• abcUtil.txt

[GoogleCodeExporter]

Chris' suggestion

ADD_DEFINITIONS( "-std=c++11" )

works. I also tried building with the tr1's stripped out (including the tr1 in 
the shared_ptr definition, and that works too.

Maybe the flag needs to be controlled in the configuration so end users can 
match the flag to their own application...

Original comment by Nick.Por...@gmail.com on 3 Nov 2013 at 5:32

[GoogleCodeExporter]

I take it back, that doesn't work. Only removing the tr1 works. I had to remove 
one in PyAlembic/Foundation.h, and PyAbcOpenGL/Foundation.h as well.

Hopefully someone can think of something cleaner than the hack workaround of 
deleting the tr1.

Original comment by Nick.Por...@gmail.com on 3 Nov 2013 at 6:07

[GoogleCodeExporter]

Well... the tr1 is not necessary. Either we have C++ support, in which case
we don't need tr1, or we don't have C++ support, in which case we use
boost.  It is pretty cut & dry.

Original comment by blackencino on 4 Nov 2013 at 6:22

[GoogleCodeExporter]

I've addressed Comment #6 here:

http://code.google.com/r/millerlucas-dev/source/detail?r=c5dc67461498793fea26f39
2fca76bcffb423972

I have yet to implement the logic to add:
ADD_DEFINITIONS( "-std=c++11" )

For OSX Mavericks only.

Original comment by miller.lucas on 3 Dec 2013 at 12:25

[GoogleCodeExporter]

Original comment by miller.lucas on 11 Dec 2013 at 12:48

• Added labels: Component-Build

[GoogleCodeExporter]

Hi,
if this supposed to be fixed in 1.5.2, with the check __cplusplus >= 201103L, 
it's not for me. 
I changed the two such checks in Alembic/Util/Foundation.h to also include 
`defined(__APPLE__)` as a workaround and it works now.

Original comment by marcel.r...@googlemail.com on 16 Dec 2013 at 4:42

[GoogleCodeExporter]

Hi Marcel, did you also need to define -std=c++11, or did it work without? (and 
with your __APPLE__ define)

Original comment by miller.lucas on 16 Dec 2013 at 5:23

[GoogleCodeExporter]

I'm pretty sure it worked without doing anything else (except the fixes 
described in issue 331).

However, I just tried again and added -std=c++11 to CMakeLists.txt just to see 
if that would fix the __cplusplus definition, and it apparently did. 
(I then got some other errors, which I'll describe in a new issue, but there 
were no complaints about tr1 anymore.)

To set this for Mavericks only, I replaced

SET( DARWIN FALSE )
IF( "${CMAKE_SYSTEM_NAME}" MATCHES "Darwin" )
  SET( DARWIN TRUE )
ENDIF()

in CMakeLists with 

SET( DARWIN FALSE )
IF( "${CMAKE_SYSTEM_NAME}" MATCHES "Darwin" )
  SET( DARWIN TRUE )
  IF(${CMAKE_SYSTEM_VERSION} MATCHES "13.")
       ADD_DEFINITIONS( "-std=c++11" )
  ENDIF()
ENDIF()

(Mavericks is Darwin-13.0.0). 

Original comment by marcel.r...@googlemail.com on 19 Dec 2013 at 11:33

[GoogleCodeExporter]

I think everything in this issue was fixed in Alembic 1.5.4

Original comment by miller.lucas on 25 Jun 2014 at 9:53

• Changed state: Resolved