compilation of alembic 0.9 fails on macosx 10.6 about alembic

[GoogleCodeExporter]

Hi Simon, that's really strange.  I see that you have an include directive for 
HDF5 in the compile line.  The declaration of H5Aexists() is in the HDF5 header 
file H5Apublic.h, which should be on your system in 
/Users/shaegler/Documents/procedural/libs/hdf5-1.8.5-patch1-macosx64-static/incl
ude (if the -I directive there is to be believed).  That file is included by 
the main hdf5.h file, which should be in the same directory.

What are the outputs of the following commands?:

ls -l 
/Users/shaegler/Documents/procedural/libs/hdf5-1.8.5-patch1-macosx64-static/incl
ude

grep H5Aexists 
/Users/shaegler/Documents/procedural/libs/hdf5-1.8.5-patch1-macosx64-static/incl
ude/*

grep H5Apublic 
/Users/shaegler/Documents/procedural/libs/hdf5-1.8.5-patch1-macosx64-static/incl
ude/*

Original comment by [email protected] on 4 Nov 2010 at 5:15

• Added labels: FoundBy-Community, Priority-NULL
• Removed labels: Priority-Medium

[GoogleCodeExporter]

hi, thanks for looking into this

ls -l hdf5.../include
-> see attachment

$ grep H5Aexists hdf5-1.8.5-patch1-macosx64-static/include/*
hdf5-1.8.5-patch1-macosx64-static/include/H5Apublic.h:H5_DLL htri_t 
H5Aexists(hid_t obj_id, const char *attr_name);
hdf5-1.8.5-patch1-macosx64-static/include/H5Apublic.h:H5_DLL htri_t 
H5Aexists_by_name(hid_t obj_id, const char *obj_name,

$ grep H5Apublic hdf5-1.8.5-patch1-macosx64-static/include/*
hdf5-1.8.5-patch1-macosx64-static/include/H5Apublic.h:#ifndef _H5Apublic_H
hdf5-1.8.5-patch1-macosx64-static/include/H5Apublic.h:#define _H5Apublic_H
hdf5-1.8.5-patch1-macosx64-static/include/H5Apublic.h:#endif /* _H5Apublic_H */
hdf5-1.8.5-patch1-macosx64-static/include/hdf5.h:#include "H5Apublic.h"     /* 
Attributes              */

Original comment by [email protected] on 4 Nov 2010 at 5:24

Attachments:

• hdf5-include.txt

[GoogleCodeExporter]

Huh!  That is really strange.  On my machine (Linux), the compile line is 
almost the same as yours, but you're missing a '-fPIC' argument to /usr/bin/c++ 
(which is probably something I need to fix in the top-level CMakeLists.txt 
file):

cd /home/jardent/alembic_build/lib/Alembic/AbcCoreHDF5 && /usr/bin/c++   
-DNDEBUG=1 -DPLATFORM_LINUX -DPLATFORM=LINUX -Wreturn-type -Werror -O3 -DNDEBUG 
-I/usr/local/include/boost-1_44 -I/usr/local/ilmbase-1.0.1/include/OpenEXR 
-I/usr/local/hdf5-1.8.5-patch1/include -I/home/jardent/alembic/lib   -UDEBUG 
-O3 -fPIC -o CMakeFiles/AlembicAbcCoreHDF5.dir/AprImpl.cpp.o -c 
/home/jardent/alembic/lib/Alembic/AbcCoreHDF5/AprImpl.cpp

What is the output of "/usr/bin/c++ -v"?

What is the output of the following command (all one line):

echo '#include <iostream>\nint main( int, char** ) { std::cout << sizeof( 
size_t ) << std::endl; return 0; }' > foo.cpp ; c++ foo.cpp ; ./a.out ; rm 
foo.cpp a.out

?  It should be '8'.

Though, these are possibly spurious leads to chase.  My fear is that the 
contents of hdf5.h are getting snipped by the pre-processor due to header 
guards, and the fact that hdf5.h is included everywhere indirectly via 
AbcCoreHDF5/Foundation.h.

If we can't get this figured out, I'll look into procuring a Mac and trying to 
replicate (right now, we are essentially Linux-only, though we have had this 
built on Macs before).

Original comment by [email protected] on 4 Nov 2010 at 5:59

• Changed state: Accepted

[GoogleCodeExporter]

$ /usr/bin/c++ -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5664~105/src/configure --disable-checking 
--enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- 
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10 
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)

the one-liner returns "8".

i will try on linux too. should this library also build on windows?

Original comment by [email protected] on 4 Nov 2010 at 9:18

[GoogleCodeExporter]

Well, I'll say this: it definitely SHOULD build on Linux, since I do that 
multiple times a day :)  It probably WON'T build on Windows, for a variety of 
reasons, but mostly due to the fact that we've not even tried.  There will 
probably be some unknown types, though we've tried to only use the greatest 
common denominator for sized types or promote explicitly-sized types (eg, 
int32_t) from Boost.  I'm also pretty sure there will be some potentially 
troublesome or unavailable headers (eg, zlib.h, though nothing in Alembic 
includes that directly).  Basically, there's nothing in our source that 
explicitly accounts for Windows (eg, no "#ifdef WINDOWS ..."), but we are aware 
of the need for that.

On our wiki, we have a document where we call out the areas where we know we 
currently have holes, and Windows support is one of them:

http://code.google.com/p/alembic/wiki/Feedback

Anyway, returning to the immediate problem at hand you're facing, I have a 
couple more questions:

1) How did you acquire the HDF5 library? From the directory name, it looks like 
a pre-compiled binary package.

2) If you did not compile it yourself, can you download the source from 
http://www.hdfgroup.org/HDF5 and build it as described here:

http://code.google.com/p/alembic/source/browse/doc/HDF5-howtobuild.txt

?  Obviously, you can change the install location and whatnot, and you may need 
to change the arguments given to the "--with-prthread=" flag.  Following those 
instructions yields a fairly minimal instance of HDF5, which here has the twin 
benefits of removing potentially confounding factors as well as proving that 
you are able to compile something Alembic-related on your system.

Original comment by [email protected] on 4 Nov 2010 at 11:25

[GoogleCodeExporter]

1) i downloaded this prebuilt package:
http://www.hdfgroup.org/ftp/HDF5/current/bin/macosx/hdf5-1.8.5-patch1-macosx64-s
tatic.tar.gz

2) i built hdf5 myself successfully according to the instructions you mention, 
but the alembic build still fails with the exact same error message... which 
gcc version do you use on linux? i also think the problem is preprocessor 
related...

Original comment by [email protected] on 5 Nov 2010 at 7:37

[GoogleCodeExporter]

So strange...

My day-to-day is built using gcc 4.1.2.  However, I've built it with 4.3.5, and 
I believe our partners at Sony use 4.4.

Again strangely, a friend of mine just built it on his 10.6 Macbook.  He did it 
using Makefiles/make, as generated by the cmake system in Alembic.  Is that 
what you are doing, or are you using XCode?

Original comment by [email protected] on 5 Nov 2010 at 8:17

[GoogleCodeExporter]

yes, i used bootstrap and cmake/make.

in the meantime, i sucessfully managed to build alembic on my linux64 box... 
i'll look into the osx issue again later. minor remark: i noticed, that alembic 
fails to build on linux when hdf5 is built with mpi support.

Original comment by [email protected] on 5 Nov 2010 at 8:58

[GoogleCodeExporter]

That's interesting (MPI).  We may look into that, but I'm not promising 
anything at the moment.

Original comment by [email protected] on 5 Nov 2010 at 9:39

[GoogleCodeExporter]

Ah, regarding MPI in HDF5, "threadsafe" and MPI are not compatible (thanks 
Lucas Miller from Sony for pointing this out):

http://www.hdfgroup.org/hdf5-quest.html#p5thread

Threadsafety is also why we don't compile HDF5 with C++.

But, returning to your issue, I have a couple things maybe you could try:

1) Is it possible you have some file somewhere else that's getting picked up 
automatically by your compiler?  What's the output of "locate hdf5.h" or 
"locate H5Apublic.h"?

2) Can you attach the output of the following command:

/usr/bin/c++ -I/opt/local/include -I/opt/local/include/OpenEXR 
-I/Users/shaegler/Documents/procedural/libs/hdf5-1.8.5-patch1-macosx64-static/in
clude -I/Users/shaegler/Documents/procedural/libs/Alembic_0.9.0/lib -E -c 
/Users/shaegler/Documents/procedural/libs/Alembic_0.9.0/lib/Alembic/AbcCoreHDF5/
AprImpl.cpp | egrep "hdf5\.h|H5Apublic\.h"

?  That should tell us if you're picking up the right hdf5 headers or not.  It 
shouldn't be too much output; it's only 27 lines on my system.

3) Just for completeness, can you run the same command, but instead of piping 
the output to grep, redirect to a file, then gzip it, and attach that to this 
bug?  When I do that on my system, the resulting file is over 70k lines and 2 
megabytes, but it compresses down to 240 kilobytes.

Anyway, I'm sorry this is giving you so much trouble.  There's definitely 
something goofy going on with your system, though: this same source code has 
been built many times without this issue on OS X 10.6.  But I'd like to get to 
the bottom of this.

Original comment by [email protected] on 5 Nov 2010 at 10:44

[GoogleCodeExporter]

As another data point, I'm using the same compiler as you: gcc version 4.2.1 
(Apple Inc. build 5664) and I don't have a problem compiling.

One difference is that my hdf5 headers are installed under /usr/local/include.

Though with the info you've provided I'm not sure why it's not finding the 
headers for you.

Original comment by miller.lucas on 6 Nov 2010 at 4:10

[GoogleCodeExporter]

thanks for your help, i finally managed to build alembic on osx. problem was an 
older hdf5 installation with macports in /opt/local... stupid me :)

Original comment by [email protected] on 6 Nov 2010 at 11:50

[GoogleCodeExporter]

Huzzah! Glad you got it worked out. And to think we don't even officially 
support OS X :)

Original comment by [email protected] on 6 Nov 2010 at 5:45

• Changed state: Resolved