Problems compiling Alembic

[joaomontenegro]

Hi guys,

I'm trying to compile Alembic in CentOS 5 64bit. I have all the
dependencies with the correct versions as specified in README.txt but
I'm getting this puzzling message:

CMake Error at CMakeLists.txt:194 (MESSAGE):
Boost version 1.42.0 found. Require 1.42.0. Check your BOOST_ROOT
environment variable.


Any clues of what can be?

Cheers,
J

[joaomontenegro]

Sorry, I spoke to soon!

If I run ./bin/mk_cmake.py from the Alembic source root dir it doesn't
show this error... but this one now appears:



CMake Error: The following variables are used in this project, but
they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
HDF5_sz_LIBRARY_DEBUG (ADVANCED)
linked by target "AlembicHDF5_Test1" in directory /home/katana/
alembic/lib/Alembic/HDF5/Tests
linked by target "AlembicHDF5_Test2" in directory /home/katana/
alembic/lib/Alembic/HDF5/Tests
linked by target "AlembicTako_Test1" in directory /home/katana/
alembic/lib/Alembic/Tako/Tests
linked by target "AlembicTakoAbstract_Test1" in directory /home/
katana/alembic/lib/Alembic/TakoAbstract/Tests
linked by target "AlembicTakoSPI_Test1" in directory /home/katana/
alembic/lib/Alembic/TakoSPI/Tests
linked by target "AlembicAsset_Test1" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicAsset_Test2" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicAsset_Test3" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicTraits_Test1" in directory /home/katana/
alembic/lib/Alembic/Traits/Tests
linked by target "AlembicTraitsGeom_Test1" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test2" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test3" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test4" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test5" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AbcStitcher" in directory /home/katana/alembic/
bin/AbcStitcher
linked by target "SimpleFsdViewer" in directory /home/katana/
alembic/bin/SimpleFsdViewer
HDF5_sz_LIBRARY_RELEASE (ADVANCED)
linked by target "AlembicHDF5_Test1" in directory /home/katana/
alembic/lib/Alembic/HDF5/Tests
linked by target "AlembicHDF5_Test2" in directory /home/katana/
alembic/lib/Alembic/HDF5/Tests
linked by target "AlembicTako_Test1" in directory /home/katana/
alembic/lib/Alembic/Tako/Tests
linked by target "AlembicTakoAbstract_Test1" in directory /home/
katana/alembic/lib/Alembic/TakoAbstract/Tests
linked by target "AlembicTakoSPI_Test1" in directory /home/katana/
alembic/lib/Alembic/TakoSPI/Tests
linked by target "AlembicAsset_Test1" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicAsset_Test2" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicAsset_Test3" in directory /home/katana/
alembic/lib/Alembic/Asset/Tests
linked by target "AlembicTraits_Test1" in directory /home/katana/
alembic/lib/Alembic/Traits/Tests
linked by target "AlembicTraitsGeom_Test1" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test2" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test3" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test4" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AlembicTraitsGeom_Test5" in directory /home/
katana/alembic/lib/Alembic/TraitsGeom/Tests
linked by target "AbcStitcher" in directory /home/katana/alembic/
bin/AbcStitcher
linked by target "SimpleFsdViewer" in directory /home/katana/
alembic/bin/SimpleFsdViewer

-- Configuring incomplete, errors occurred!


Thanks,
J

[Joe Ardent]

On Aug 10, 8:57 am, joaomontenegro <joaomontene...@gmail.com> wrote:

> Sorry, I spoke to soon!
>
> If I run ./bin/mk_cmake.py from the Alembic source root dir it doesn't
> show this error... but this one now appears:
>
> CMake Error: The following variables are used in this project, but
> they are set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the
> CMake files:
> HDF5_sz_LIBRARY_DEBUG (ADVANCED)
>     linked by target "AlembicHDF5_Test1" in directory /home/katana/

> [snip]

> -- Configuring incomplete, errors occurred!

Hi J, I'm afraid the README is slightly out of date. Do this:

1) Set the environment variable "ILMBASE_ROOT" to something like "/
usr" (this is a bug in our build setup that will be fixed shortly);
this is assuming you have ImathMatrix.h under, eg, /usr/include/
OpenEXR/.

2) Assuming your alembic source is in /home/katana/alembic, run the
command "/home/katana/alembic/build/bootstrap/alembic_bootstrap.py".
This is a build-system bootstrapping script that will ask you some
questions about your setup and attempt to find all the stuff it
needs. It will also prompt you for the location of your build
directory; it will default to "/home/katana/alembic_build".

3) Once that finishes, you should have your build root setup. cd to
the build directory, and run "make".

Feel free to ask any more questions! But I'll say off the bat that
we're still working on polishing the build process, and hopefully all
will find it much more pleasant and straightforward soon.


-Joe

[Joe Ardent]

On Aug 10, 9:46 am, Joe Ardent <ard...@gmail.com> wrote:
>
> Hi J, I'm afraid the README is slightly out of date.  Do this:
>
> 1) Set the environment variable "ILMBASE_ROOT" to something like "/
> usr" (this is a bug in our build setup that will be fixed shortly);
> this is assuming you have ImathMatrix.h under, eg, /usr/include/
> OpenEXR/.
>
> 2) Assuming your alembic source is in /home/katana/alembic, run the
> command "/home/katana/alembic/build/bootstrap/alembic_bootstrap.py".
> This is a build-system bootstrapping script that will ask you some
> questions about your setup and attempt to find all the stuff it
> needs.  It will also prompt you for the location of your build
> directory; it will default to "/home/katana/alembic_build".
>
> 3) Once that finishes, you should have your build root setup.  cd to
> the build directory, and run "make".
>
> Feel free to ask any more questions!  But I'll say off the bat that
> we're still working on polishing the build process, and hopefully all
> will find it much more pleasant and straightforward soon.
>

Ah, one more thing: the errors you were getting are because CMake
could not find your HDF5 libraries. The bootstrap script will use the
"locate" command to try to find them, and present a numbered list of
possible matches for, eg, libhdf5_hl.a, then use the location of that
file to figure out where the rest of the HDF5 libraries are (ditto
include directory by looking at the location of "hdf5.h").

-Joe

[joaomontenegro]

Hi Joe,

Thanks for your answer! It did work. I could easily specify where to
pick the libs.

But now I'm getting some internal linking issues:

Building CXX object lib/Alembic/TraitsGeom/CMakeFiles/
AlembicTraitsGeom.dir/Test.cpp.o
cd /home/katana/alembic/lib/Alembic/TraitsGeom && /usr/bin/c++ -
DNDEBUG=1 -DPLATFORM_LINUX -DPLATFORM=LINUX -O3 -DNDEBUG -I/usr/local/
include -I/usr/local/include/OpenEXR -I/home/katana/alembic_deps/
hdf5-1.8.4-patch1-linux-x86_64-shared/include -I/home/katana/alembic/
pub -I/home/katana/alembic/lib -UDEBUG -O3 -fPIC -o CMakeFiles/
AlembicTraitsGeom.dir/Test.cpp.o -c /home/katana/alembic/lib/Alembic/
TraitsGeom/Test.cpp
/home/katana/alembic/lib/Alembic/TraitsGeom/Test.cpp: In function
‘void Alembic::TraitsGeom::meshOut()’:
/home/katana/alembic/lib/Alembic/TraitsGeom/Test.cpp:159: error: no
matching function for call to
‘Alembic::Asset::OPropertyTrait<Alembic::Asset::OTypedMultiProperty<Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>,
kFloat32POD, 3ul> >, Alembic::TraitsGeom::PositionsStrait>::set(const
Alembic::Asset::V3d*, size_t&)’
/home/katana/alembic/lib/Alembic/Asset/OProperty.h:558: note:
candidates are: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, const Alembic::Util::Dimensions&) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]
/home/katana/alembic/lib/Alembic/Asset/OProperty.h:562:
note: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, size_t) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]
/home/katana/alembic/lib/Alembic/TraitsGeom/Test.cpp: In function
‘void Alembic::TraitsGeom::subdOut()’:
/home/katana/alembic/lib/Alembic/TraitsGeom/Test.cpp:305: error: no
matching function for call to
‘Alembic::Asset::OPropertyTrait<Alembic::Asset::OTypedMultiProperty<Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>,
kFloat32POD, 3ul> >, Alembic::TraitsGeom::PositionsStrait>::set(const
Alembic::Asset::V3d*, size_t&)’
/home/katana/alembic/lib/Alembic/Asset/OProperty.h:558: note:
candidates are: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, const Alembic::Util::Dimensions&) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]
/home/katana/alembic/lib/Alembic/Asset/OProperty.h:562:
note: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, size_t) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]
make[2]: *** [lib/Alembic/TraitsGeom/CMakeFiles/AlembicTraitsGeom.dir/
Test.cpp.o] Error 1
make[2]: Leaving directory `/home/katana/alembic'
make[1]: *** [lib/Alembic/TraitsGeom/CMakeFiles/AlembicTraitsGeom.dir/
all] Error 2
make[1]: Leaving directory `/home/katana/alembic'
make: *** [all] Error 2



Apparently in alembic/lib/Alembic/TraitsGeom/Test.cpp:307:

psubd->mesh().positions().set( ( const Abc::V3d * )verts, numVerts );

doesn't like (const Abc::V3d *) as the first argument of set() . I
tried to figure out what type should be passed there, but I got a bit
lost there in the Templates and the Macros... :-)



J

[joaomontenegro]

By the way, I've commented a couple of lines with this problem and
compiled successfully.

Cheers,
Joao

[Tom]

We are having the exact same problem with TraitsGeom/Test.cpp and
would like to know the proper solution. As you did, we are commenting
those lines out and continuing with the build, but we would like the
real solution so we can have working test files.

Out of curiosity, is this build process going to be simplified when
the final release is completed? There are quite a few steps and and
number of opportunities to screw things up. Anything but the default
builds, for Alembic and for all of its dependencies, really
complicates the process.

thanks!

t-

[Joe Ardent]

On Thu, Aug 12, 2010 at 4:06 PM, Tom <t....@d....com> wrote:
>
> We are having the exact same problem with TraitsGeom/Test.cpp and
> would like to know the proper solution. As you did, we are commenting
> those lines out and continuing with the build, but we would like the
> real solution so we can have working test files.
>

Hi Tom,

The proper solution is to not build or use the TraitsGeom library, as
the final public API is going to be most close to the one given in
lib/Alembic/AbcCoreAbstract. But even that one is very low-level, so
on top of that, there will be a new library (AbcGeom) plus a helper
library called AbcNice. The AbcNice + AbcGeom library will compose
into something a lot like AlembicAsset/AlembicTraitsGeom. Here's a
excerpt from a PolyMesh writing test (geometric data is coming from an
included file; the 'g' in front of 'g_verts' etc. is for "global"):

namespace Abc = Alembic::AbcNice;
namespace Ago = Alembic::AbcGeom;

//-*****************************************************************************
// Global time information
Abc::chrono_t g_secondsPerFrame = 1.0 / 24.0;
Abc::chrono_t g_timeOfSample0 = 19.0;

void Brevity_Example1_MeshOut()
{
Abc::OArchive archive( "brevityPolyMesh1.abc",
Abc::ErrorHandler::kThrowPolicy );
Ago::OTransform xform( archive, "meshy_xform",
Abc::TimeSamplingType( g_secondsPerFrame ) );
Ago::OPolyMesh mesh( xform, "meshy_shape" );
Ago::OPolyMesh::Sample mesh_samp(
Abc::OV3fArraySample( g_verts, g_numVerts ),
Abc::OIntArraySample( g_indices, g_numIndices ),
Abc::OIntArraySample( g_starts, g_numStarts ),
Abc::OV3fArraySample( g_normals, g_numNormals ),
Abc::OV2fArraySample( g_uvs, g_numUVs ) );
mesh.set( mesh_samp );

for ( Abc::index_t sampIndex = 0; sampIndex < 60; ++sampIndex )
{
Abc::chrono_t sampTime = g_timeOfSample0 +
g_secondsPerFrame * ( Abc::chrono_t ) sampIndex;

Abc::M44d mtx;
Abc::float64_t ytrans = 0.125 * ( Abc::float64_t )sampIndex;
mtx.makeIdentity();
mtx.setTranslation( Abc::V3d( 0.0, ytrans, 0.0 ) );

Ago::OTransform::Sample xform_samp( mtx );

xform.set( xform_samp,
Abc::OSampleSelector( sampIndex, sampTime ) );
}

std::cout << "Writing: " << archive.getName() << std::endl;
}

Doing tests on things like filesize, IO performance, etc. is
premature, as the binary format of Alembic files is different than
those produced by AlembicAsset.

>
> Out of curiosity, is this build process going to be simplified when
> the final release is completed? There are quite a few steps and and
> number of opportunities to screw things up. Anything but the default
> builds, for Alembic and for all of its dependencies, really
> complicates the process.
>

Short answer: "probably". We've been working on making the build
setup as polished, foolproof, and easy as possible. However, building
is a difficult general problem: ABI-incompatibilities across different
C++ compiler versions (ensuring that if you're using, say, Maya, that
you must build your Alembic libraries and plugins with the same
compiler), constructing sane link paths, etc., all conspire to make it
impossible to reduce the complexity below a certain floor.

For that reason, we are recommending certain best-practices, such as
linking statically whenever possible (eg, in the case of libz, libm,
the ilmbase libs like Half, Iex, etc.), building HDF5 as a C-only
library (eliminating C++ ABI issues), and relying on a minimum set of
non-header-only Boost libs (and with work, we may be able to eliminate
all non-header-only Boost libraries, or possibly Boost entirely if
you're using a sufficiently modern C++ compiler -- but that is not a
priority at the moment). It may be that one's setup is very standard
and unified, though, and everything will "just work". But the reality
remains that you'll need:

- Boost 1.42 or greater (1.43 is good)
- ilmbase (the foundation of OpenEXR; used to provide Imath, etc.)
- HDF5 (it's likely we'll recommend 1.8.5 at the time of release,
though we're currently using 1.8.4-patch1)

The other reality is that we'll be providing pre-built bundles in
various configurations, and hopefully, that will save most people a
lot of pain.

Anyway, thank you for your interest and enthusiasm! If you'd like, it
might be a good idea to sign up to the alembic-announce list
(http://groups.google.com/group/alembic-announce). Once we have the
final release ready to go, we'll send a message to that list (it's not
a discussion list, it's announcements only). As we state on the
project's Google Code site, we'll be releasing the "1.0" version later
this month.

-Joe

[Tom]

Thanks for the thorough reply Joe.

I have signed up for the announcement list and we await the 1.0
release. We were hoping to get a jump start by compiling this current
version, just to get our feet wet as it were. We brought down fresh
copies of everything except Boost since we already had it and compiled
everything according to your instructions (putting them in the
optional contrib area). Hopefully we will get something from the
effort, if not, it was an interesting dry run. =)

t-

[BaiLong]

Hi there,

I had also several Problems compiling but most of them I could solve
with your posts.
But this one seem to not disappear...

-- [ /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:830 ]
Boost_FOUND = FALSE
CMake Error at /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:910
(message):
Unable to find the requested Boost libraries.

Boost version: 1.42.0

Boost include path: /usr/local/include

The following Boost libraries could not be found:

boost_iostreams

Some (but not all) of the required Boost libraries were found. You
may
need to install these additional Boost libraries. Alternatively,
set
Boost_LIBRARYDIR to the directory containing Boost libraries or
BOOST_ROOT
to the location of Boost.


The weired thing is that before when I had problems that it didn't
accept something else it told me it found iostreams.
In /usr/local/include there is a folder called iostreams is that the
one it's looking for?

I use the Script "alembic/build/bootstrap/alembic_bootstrap.py"
On Ubuntu 9.10 x64
HDF5 1.85
boost 1.42
Ilmbase 1.0.1
OpenEXR 1.6.1
CMake 2.8.2

ILMBASE_ROOT is set to /usr mentioned above.
Where should BOOST_ROOT point to? I tried /usr/local/, /usr/local/
include/, /usr/local/include/boost/ and ~/boost1_42_0 as well.

Anything I forgot?

Thanks so far for all this! :)

Cheers,
--Markus

[Joe Ardent]

Hi Markus, I apologize for the late reply.

It sounds a lot like you just don't have libboost_iostreams. What is
the output of "locate libboost_iostrea"? If you're in your build
root, what is the output of "grep Boost_IOSTREAMS_LIBRARY
CMakeCache.txt"?

At any rate, we're very close to releasing a major update, so you may
just want to sit tight just a little bit longer :)

[BaiLong]

Not a problem, I just had a few days off, before the weekend. ;)

locate libboost_iostreams outputs
"/usr/lib/libboost_iostreams.so.1.40.0"
I guess that's a problem, right? It should be 1.42.0.

grep Boost_IOSTREAMS_LIBRARY CMakeCache.txt outputs
Boost_IOSTREAMS_LIBRARY_DEBUG:FILEPATH=Boost_IOSTREAMS_LIBRARY_DEBUG-
NOTFOUND
Boost_IOSTREAMS_LIBRARY_RELEASE:FILEPATH=Boost_IOSTREAMS_LIBRARY_RELEASE-
NOTFOUND
//ADVANCED property for variable: Boost_IOSTREAMS_LIBRARY_DEBUG
Boost_IOSTREAMS_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_IOSTREAMS_LIBRARY_RELEASE
Boost_IOSTREAMS_LIBRARY_RELEASE-ADVANCED:INTERNAL=1

I'm really looking forward to the release, but I'm raring to play
around. ^^

[BaiLong]

Not a problem, I just had a few days off, before the weekend. ;)

locate libboost_iostreams outputs
"/usr/lib/libboost_iostreams.so.1.40.0"
I guess that's a problem, right? It should be 1.42.0.

grep Boost_IOSTREAMS_LIBRARY CMakeCache.txt outputs
Boost_IOSTREAMS_LIBRARY_DEBUG:FILEPATH=Boost_IOSTREAMS_LIBRARY_DEBUG-
NOTFOUND
Boost_IOSTREAMS_LIBRARY_RELEASE:FILEPATH=Boost_IOSTREAMS_LIBRARY_RELEASE-
NOTFOUND
//ADVANCED property for variable: Boost_IOSTREAMS_LIBRARY_DEBUG
Boost_IOSTREAMS_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: Boost_IOSTREAMS_LIBRARY_RELEASE
Boost_IOSTREAMS_LIBRARY_RELEASE-ADVANCED:INTERNAL=1

I'm really looking forward to the release, but I'm raring to play
around. ^^

[BaiLong]

I manually changed some files and links and reinstalled
libboost_iostreams.

looks better now but still doesn't work...

[ /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:834 ] Boost_FOUND
= TRUE
-- Boost version: 1.42.0
-- Found the following Boost libraries:
-- iostreams
-- program_options
-- filesystem
-- system
-- regex
-- python
-- BOOST FOUND: TRUE
-- BOOST INCLUDE DIRS: /home/kranzlma/supportingApps/boost_1_42_0
-- BOOST LIBRARIES: /usr/lib/libboost_iostreams-mt.so;/usr/lib/
libboost_program_options-mt.a;/usr/lib/libboost_filesystem-mt.a;/usr/
lib/libboost_system-mt.a;/usr/lib/libboost_regex-mt.a;/usr/lib/
libboost_python-mt.a
-- ALEMBIC_BOOST_FOUND: 0

CMake Error at CMakeLists.txt:194 (MESSAGE):
Boost version 1.42.0 found. Require 1.42.0. Check your BOOST_ROOT
environment variable.

In the BOOST LIBRARIES it sticks out that except for the "iostreams"
the *.a files are used. The problem is that libboost_iostreams didn't
install a *.a file. Where do I get it?
Because of unsolvable dependencies to libc6 I can't install
libboost_iostreams-dev. Maybe it would work if I upgrade to ubuntu
10.04. You think that could be the issue, that I'm still on 9.10?

Thanks!

[David Hellier]

Hi

I have succeeded in compiling Boost 1.42 on 9.10. I think it's an issue that will be fixed in the net push. The cached

variables for ALEMBIC_BOOST_FOUND not being reset. In the meantime if you edit your CMakeCache.txt file and delete the line that has ALEMBIC_BOOST_FOUND: 0 then try again it might succeed. Can you tell me if the /usr/lib/libboost_iostreams-mt.so is a symlink to the 1.42 version?

David

[BaiLong]

Awesome!
Thanks a lot David, at least I got a few steps further. :)

Yes, /usr/lib/libboost_iostreams-mt.so is a symbolic link to /usr/lib/
libboost_iostreams.so.1.42.0.

Now I get those Errors:
-- ALEMBIC_BOOST_FOUND: 1
-- ILMBASE INCLUDE PATH: /usr/local/include/OpenEXR
-- HALF LIB: /usr/lib/libHalf.so
-- IEX LIB: /usr/lib/libIex.so
-- ILMTHREAD LIB: /usr/lib/libIlmThread.so
-- IMATH LIB: /usr/lib/libImath.so
-- Found Python 2.6: /usr/bin/python2.6
-- NOT SETTING HDF5_INCLUDE_DIR FROM ENVIRONMENT
-- Could NOT find HDF5 (missing: HDF5_LIBRARIES)
-- Disabling HDF5 Library!
-- GTO_SUPPORT_ZIP in da HIZZOUSE!
-- PRMan not found
-- About to include AlembicMaya.cmake
-- Maya lib root: /sww/tools/autodesk/maya2010/devkit/lib
-- Could not find Maya2010. :(
-- For some reason, MAYA_FOUND is False?

CMake Error: The following variables are used in this project, but
they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:

GLUT_Xmu_LIBRARY (ADVANCED)
linked by target "SimpleGtoViewer" in directory /home/kranzlma/
alembic/bin/SimpleGtoViewer
linked by target "GlutSkeleton" in directory /home/kranzlma/
alembic/bin/GlutSkeleton
linked by target "SimpleFsdViewer" in directory /home/kranzlma/
alembic/bin/SimpleFsdViewer

HDF5_ROOT is set.
I created a variable called HDF5_LIBRARIES (cause it seems to be
looking for it) that points to /usr/local/hdf5/lib. Doesn't change...
I rebuilded hdf5 but also no success.
Why does it think PRMan is not installed? Where does it look for it?
Why does it look in "/sww/tools/autodesk/maya2010/devkit/lib" for
Maya libs?
Where should GLUT_Xmu_LIBRARY point to?

Sorry to ask such stupid questions, I'm not much used to building
projects and I still have a flu. :)

Thank you again!
--Markus

On Aug 24, 5:34 pm, David Hellier <david.hell...@gmail.com> wrote:
> Hi
>
> I have succeeded in compiling Boost 1.42 on 9.10. I think it's an issue that
> will be fixed in the net push. The cached
> variables for ALEMBIC_BOOST_FOUND not being reset. In the meantime if you
> edit your CMakeCache.txt file and delete the line that has
> ALEMBIC_BOOST_FOUND: 0 then try again it might succeed. Can you tell me if
> the /usr/lib/libboost_iostreams-mt.so is a symlink to the 1.42 version?
>
> David
>

[David Hellier]

Hi Markus

For the GLUT Xmu problem check that you have the package libxmu-dev
installed and it should find it automatically.
We will be fixing support for compiling with Maya and Renderman in the
next push. Please try compiling without USE_MAYA and USE_PRMAN set to
true. In the mean time if you want to use Maya and Renderman you will
need to fiddle with the hard-coded paths in build/AlembicMaya.cmake
and build/AlembicPRMan.cmake, or pass the correct CMake arguments
using the alembic_bootstrap.py script. This script is also set to be
updated in the next push.
Please let us know if there's any other issues we can iron out

Thanks
David

[BaiLong]

Million thanks David!! It now configured completely. :D

-- Configuring done
-- Generating done
-- Build files have been written to: /home/kranzlma/alembic2_build

But the next issue I'm running into is when I try make.

Linking CXX executable AlembicTako_Test1
cd /home/kranzlma/alembic/lib/Alembic/Tako/Tests && /usr/local/bin/
cmake -E cmake_link_script CMakeFiles/AlembicTako_Test1.dir/link.txt --
verbose=1
/usr/bin/c++ -O3 -DNDEBUG CMakeFiles/AlembicTako_Test1.dir/
CameraTest.cpp.o CMakeFiles/AlembicTako_Test1.dir/
GenericNodeTest.cpp.o CMakeFiles/AlembicTako_Test1.dir/
HDFNodeTest.cpp.o CMakeFiles/AlembicTako_Test1.dir/Main.cpp.o
CMakeFiles/AlembicTako_Test1.dir/NurbsCurveTest.cpp.o CMakeFiles/
AlembicTako_Test1.dir/NurbsSurfaceTest.cpp.o CMakeFiles/
AlembicTako_Test1.dir/PointPrimitiveTest.cpp.o CMakeFiles/
AlembicTako_Test1.dir/PolyMeshTest.cpp.o CMakeFiles/
AlembicTako_Test1.dir/SubDTest.cpp.o CMakeFiles/AlembicTako_Test1.dir/
TransformTest.cpp.o -o AlembicTako_Test1 -rdynamic ../
libAlembicTako.a -lAlembicHDF5 ../../Util/libAlembicUtil.a -lNOTFOUND -
lpthread -Wl,-Bstatic -lz -Wl,-Bdynamic -lm
/usr/bin/ld: cannot find -lAlembicHDF5
collect2: ld returned 1 exit status
make[2]: *** [lib/Alembic/Tako/Tests/AlembicTako_Test1] Error 1
make[2]: Leaving directory `/home/kranzlma/alembic'
make[1]: *** [lib/Alembic/Tako/Tests/CMakeFiles/AlembicTako_Test1.dir/
all] Error 2
make[1]: Leaving directory `/home/kranzlma/alembic'

make: *** [all] Error 2

I'm not sure what this means.
Could that be caused by the HDF5 problems that were output while
configuring?

...

-- NOT SETTING HDF5_INCLUDE_DIR FROM ENVIRONMENT
-- Could NOT find HDF5 (missing: HDF5_LIBRARIES)
-- Disabling HDF5 Library!

...

Btw, it said Maya and PRman worked fine. Thanks also for that! :)

I already can smell we are almost there. I'm so excited! ^^

Cheers
--Markus

On Aug 25, 8:22 am, David Hellier <david.hell...@gmail.com> wrote:
> Hi Markus
>
> For the GLUT Xmu problem check that you have the package libxmu-dev
> installed and it should find it automatically.
> We will be fixing support for compiling with Maya and Renderman in the
> next push. Please try compiling without USE_MAYA and USE_PRMAN set to
> true. In the mean time if you want to use Maya and Renderman you will
> need to fiddle with the hard-coded paths in build/AlembicMaya.cmake
> and build/AlembicPRMan.cmake, or pass the correct CMake arguments
> using the alembic_bootstrap.py script. This script is also set to be
> updated in the next push.
> Please let us know if there's any other issues we can iron out
>
> Thanks
> David
>

[David Hellier]

Hi Markus

The reason AlembicHDF5 could not be found is because it couldn't find
HDF5 libraries to compile against. I'll put a guard in the CMakeLists
for the next push to check for this case. Where have you installed
HDF5? Have a look at the build/AlembicHDF5.cmake file. If you notice
it uses FIND_PACKAGE( HDF5 ) - which is a CMake command that uses the
FindHDF5.cmake module that is part of CMake. This module is a little
convoluted, however there are a number of ways to configure it:

1. Pass a CMake argument : -D
HDF5_ROOT:STRING=/usr/local/hdf5-1.8.4-patch1 (this is what the
bootstrap script does)
2. Hard code the path here: SET( HDF5_ROOT "/usr/local/hdf5-1.8.4-patch1" )
3. Set an environment variable called HDF5_ROOT pointing to where HDF5
is installed. (this is not our preferred solution)
4. Set an environment variabled called HDF5_INCLUDE_DIR pointing to
where HDF5 include directories are (this is also not our preferred
solution)

The next bootstrap script actually tests that HDF5 is found and also
that it compiles a successful test executable using the found HDF5
library.

It seems you are very close to compiling it successfully.

Thanks for your feedback.

David

[Joe Ardent]

On Thu, Aug 26, 2010 at 7:31 AM, David Hellier <david....@gmail.com> wrote:
>
> 1. Pass a CMake argument : -D
> HDF5_ROOT:STRING=/usr/local/hdf5-1.8.4-patch1 (this is what the
> bootstrap script does)
> 2. Hard code the path here: SET( HDF5_ROOT "/usr/local/hdf5-1.8.4-patch1" )
> 3. Set an environment variable called HDF5_ROOT pointing to where HDF5
> is installed. (this is not our preferred solution)
> 4. Set an environment variabled called HDF5_INCLUDE_DIR pointing to
> where HDF5 include directories are (this is also not our preferred
> solution)
>
> The next bootstrap script actually tests that HDF5 is found and also
> that it compiles a successful test executable using the found HDF5
> library.
>

The current iteration of the bootstrap script can actually find all
the HDF5 stuff needed to build without using CMake at all. This is an
excerpt from a mail sent to one of our external alpha developers who
have a goofy system setup about this:

"""
I'm pretty sure
the reason you got that message (HDF5 NOT FOUND) is that in spite of
your setting the libraries and include dir for hdf5, CMake was unable
to actually find the package HDF5, probably because the path to the
"h5cc" program was not in your $PATH, and you didn't have an HDF5_ROOT
environment variable set. h5cc just spits out information about how
you compiled hdf5, including its configured install location (so it
will be inaccurate if you did "--prefix=/foo" but actually manually
installed it to /bar; there's not a good way around this, aside from
not using cmake, or doing what I'm doing to fool it). Anyway, cmake
runs that program and parses the output to try to find where the hdf5
stuff is. I'm pretty sure this is very dumb, but again, cmake is
clunky and idiosyncratic (every "Find<foo>.cmake" script it comes with
works differently).

So, the bootstrap script will figure out a sane value for HDF5_ROOT
(by finding the longest common filepath between the hdf5 include dir
and the hdf5 lib dir), check os.environ for HDF5_ROOT, and if it's not
already there, it will do "os.environ['HDF5_ROOT']=<computed hdf5
root>". Then when CMake goes to find the hdf5 package, it will use
that to try to find the h5cc program. It can then try to do what it
does and find hdf5.

If cmake can't find hdf5, but you've used the bootstrap script to tell
it where the libraries and include dirs are, our build setup will
failover to what the bootstrapper told it. I tested a build at ILM
where I'd commented out the "FIND_PACKAGE( HDF5 )" line in
build/AlembicHDF5.cmake, and it built and tested correctly.
"""

So, there is that, and very very soon, the repo will be updated with
this. Thank you again for your patience and enthusiasm!

-Joe

[BaiLong]

Hey David, thanks for your help!
I finally did.......something. :P
I already had tried some of the HDF5 variable things, BUT I couldn't
find the FindHDF5.cmake script you mentioned on my system. So I wrote
one myself. (That already was tricky and a big thing for me! ^^ )

Now all seemed great and ran smoothly.
I 'make' the project and the problems mentioned before didn't occur.

Anyhow now at 65% I receive an error from one of the test *.cpp files,
that finally seems not to be caused by my system variables (Hooray!):

[ 65%] Building CXX object lib/Alembic/TraitsGeom/CMakeFiles/
AlembicTraitsGeom.dir/Test.cpp.o
cd /home/kranzlma/alembic2_build/lib/Alembic/TraitsGeom && /usr/bin/c+
+ -DNDEBUG=1 -DPLATFORM_LINUX -DPLATFORM=LINUX -O3 -DNDEBUG -I/usr/
local/include -I/usr/local/include/OpenEXR -I/usr/local/hdf5/include -
I/home/kranzlma/alembic2/pub -I/home/kranzlma/alembic2/lib -UDEBUG -
O3 -fPIC -o CMakeFiles/AlembicTraitsGeom.dir/Test.cpp.o -c /home/
kranzlma/alembic2/lib/Alembic/TraitsGeom/Test.cpp
/home/kranzlma/alembic2/lib/Alembic/TraitsGeom/Test.cpp: In function
‘void Alembic::TraitsGeom::meshOut()’:
/home/kranzlma/alembic2/lib/Alembic/TraitsGeom/Test.cpp:159: error: no

matching function for call to
‘Alembic::Asset::OPropertyTrait<Alembic::Asset::OTypedMultiProperty<Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>,
kFloat32POD, 3ul> >, Alembic::TraitsGeom::PositionsStrait>::set(const
Alembic::Asset::V3d*, size_t&)’

/home/kranzlma/alembic2/lib/Alembic/Asset/OProperty.h:558: note:

candidates are: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, const Alembic::Util::Dimensions&) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]

/home/kranzlma/alembic2/lib/Alembic/Asset/OProperty.h:562:

note: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, size_t) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]

/home/kranzlma/alembic2/lib/Alembic/TraitsGeom/Test.cpp: In function
‘void Alembic::TraitsGeom::subdOut()’:
/home/kranzlma/alembic2/lib/Alembic/TraitsGeom/Test.cpp:305: error: no

matching function for call to
‘Alembic::Asset::OPropertyTrait<Alembic::Asset::OTypedMultiProperty<Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>,
kFloat32POD, 3ul> >, Alembic::TraitsGeom::PositionsStrait>::set(const
Alembic::Asset::V3d*, size_t&)’

/home/kranzlma/alembic2/lib/Alembic/Asset/OProperty.h:558: note:

candidates are: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, const Alembic::Util::Dimensions&) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]

/home/kranzlma/alembic2/lib/Alembic/Asset/OProperty.h:562:

note: void
Alembic::Asset::OTypedMultiProperty<TRAITS>::set(const typename
TRAITS::value_type*, size_t) [with TRAITS =
Alembic::Asset::TypedPropertyTraits<Imath::Vec3<float>, kFloat32POD,
3ul>]
make[2]: *** [lib/Alembic/TraitsGeom/CMakeFiles/AlembicTraitsGeom.dir/

Test.cpp.o] Error 1
make[2]: Leaving directory `/home/kranzlma/alembic2_build'
make[1]: *** [lib/Alembic/TraitsGeom/CMakeFiles/AlembicTraitsGeom.dir/
all] Error 2
make[1]: Leaving directory `/home/kranzlma/alembic2_build'

make: *** [all] Error 2

Can you also help me with that? Pretty please! :)

Thanks so far!!! I could have come so far without you!!!

Cheers
--Markus

On Aug 26, 4:31 pm, David Hellier <david.hell...@gmail.com> wrote:
> Hi Markus
>
> The reason AlembicHDF5 could not be found is because it couldn't find
> HDF5 libraries to compile against. I'll put a guard in the CMakeLists
> for the next push to check for this case. Where have you installed
> HDF5? Have a look at the build/AlembicHDF5.cmake file. If you notice
> it uses FIND_PACKAGE( HDF5 ) - which is a CMake command that uses the
> FindHDF5.cmake module that is part of CMake. This module is a little
> convoluted, however there are a number of ways to configure it:
>
> 1. Pass a CMake argument : -D
> HDF5_ROOT:STRING=/usr/local/hdf5-1.8.4-patch1 (this is what the
> bootstrap script does)
> 2. Hard code the path here: SET( HDF5_ROOT "/usr/local/hdf5-1.8.4-patch1" )
> 3. Set an environment variable called HDF5_ROOT pointing to where HDF5
> is installed. (this is not our preferred solution)
> 4. Set an environment variabled called HDF5_INCLUDE_DIR pointing to
> where HDF5 include directories are (this is also not our preferred
> solution)
>
> The next bootstrap script actually tests that HDF5 is found and also
> that it compiles a successful test executable using the found HDF5
> library.
>
> It seems you are very close to compiling it successfully.
>
> Thanks for your feedback.
>
> David
>

> ...
>
> read more »

[BaiLong]

Anyone on this?

> ...
>
> read more »

[Joe Ardent]

Hi Markus, I replied privately (check your mail?), but the answer is
that that code is deprecated and will be removed very shortly. I
apologize for the state of the repo; it was a snapshot of our codebase
immediately prior to our SIGGraph demo, and represented a somewhat
disordered state. We're sorting out some non-technical issues
currently, though, and will update the main branch on the
code.google.com site as soon as that is done. Thanks again for your
patience and enthusiasm!

-Joe

[BaiLong]

Sorry Joe, I just use my google Mail account to join these code
groups. ;)
That's why I didn't saw your message.

Yesterday I played around and tried to comment all the TraitsGeom
Tests in the makefiles. It did not work because of a missing file.
But thanks to your help I re-made the project and it ran very smoothly
to a certain point. It's almost the same error I got yesterday with
`.rodata.str1.1'

[ 83%] Building CXX object maya/AlembicAbcExport/CMakeFiles/
AlembicAbcExport.dir/Transform.cpp.o
cd /home/kranzlma/alembic2_build/maya/AlembicAbcExport && /usr/bin/c+
+ -DAlembicAbcExport_EXPORTS -DNDEBUG=1 -DPLATFORM_LINUX -
DPLATFORM=LINUX -Wreturn-type -Werror -O3 -DNDEBUG -fPIC -I/usr/local/
include -I/usr/include/OpenEXR -I/usr/local/hdf5/include -I/home/
kranzlma/alembic2/ardent-latest/lib -I/home/kranzlma/alembic2/ardent-
latest/maya/AlembicAbcExport/.. -I/usr/autodesk/maya2010-x64/include
-UDEBUG -O3 -fPIC -m64 -g -pthread -pipe -D_BOOL -DLINUX -DLINUX_64 -
DREQUIRE_IOSTREAM -fPIC -Wno-deprecated -fno-gnu-keywords -o
CMakeFiles/AlembicAbcExport.dir/Transform.cpp.o -c /home/kranzlma/
alembic2/ardent-latest/maya/AlembicAbcExport/Transform.cpp

Linking CXX shared module AlembicAbcExport.so
cd /home/kranzlma/alembic2_build/maya/AlembicAbcExport && /usr/local/
bin/cmake -E cmake_link_script CMakeFiles/AlembicAbcExport.dir/
link.txt --verbose=1
/usr/bin/c++ -fPIC -Wreturn-type -Werror -O3 -DNDEBUG -shared -m64 -g
-pthread -pipe -D_BOOL -DLINUX -DLINUX_64 -DREQUIRE_IOSTREAM -fPIC -
Wno-deprecated -fno-gnu-keywords -Wl,-Bsymbolic -shared -Wl,-
soname,AlembicAbcExport.so -o AlembicAbcExport.so CMakeFiles/
AlembicAbcExport.dir/Attribute.cpp.o CMakeFiles/AlembicAbcExport.dir/
Exportable.cpp.o CMakeFiles/AlembicAbcExport.dir/ExportCmd.cpp.o
CMakeFiles/AlembicAbcExport.dir/Factory.cpp.o CMakeFiles/
AlembicAbcExport.dir/MayaUtil.cpp.o CMakeFiles/AlembicAbcExport.dir/
PolyMesh.cpp.o CMakeFiles/AlembicAbcExport.dir/Top.cpp.o CMakeFiles/
AlembicAbcExport.dir/Transform.cpp.o -L/usr/autodesk/maya2010-x64/lib -
lFoundation -lOpenMaya -lOpenMayaAnim -lOpenMayaFX -lOpenMayaRender -
lOpenMayaUI ../../lib/Alembic/AbcGeom/libAlembicAbcGeom.a ../../lib/
Alembic/AbcNice/libAlembicAbcNice.a ../../lib/Alembic/AbcCoreHDF5/
libAlembicAbcCoreHDF5.a ../../lib/Alembic/AbcCoreAbstract/
libAlembicAbcCoreAbstract.a ../../lib/Alembic/HDF5/
libAlembicHDF5.a ../../lib/Alembic/MD5Hash/libAlembicMD5Hash.a ../../
lib/Alembic/Util/libAlembicUtil.a /usr/local/hdf5/lib/libhdf5.a /usr/
local/hdf5/lib/libhdf5_hl.a /usr/local/hdf5/lib/libhdf5.a -Wl,-Bstatic
-lImath -lIlmThread -lIex -lHalf -Wl,-Bdynamic -lpthread -Wl,-Bstatic -
lz -Wl,-Bdynamic -lm /usr/local/hdf5/lib/libhdf5_hl.a -Wl,-Bstatic -
lImath -lIlmThread -lIex -lHalf -Wl,-Bdynamic -lpthread -Wl,-Bstatic -
lz -Wl,-Bdynamic -lm -Wl,-rpath,/usr/autodesk/maya2010-x64/lib:
/usr/bin/ld: /usr/local/hdf5/lib/libhdf5.a(H5.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a
shared object; recompile with -fPIC
/usr/local/hdf5/lib/libhdf5.a: could not read symbols: Bad value

After I tried something I again tried to make the project and there it
already stopped at 78%, with the same error. Could it be that
something changed the file /usr/local/hdf5/lib/libhdf5.a(H5.o)?

What also confuses me is the "recompile with -fPIC" state. The fPIC
flag is even set twice.

Sorry for bothering you so much, but I really, really appreciate your
help!!
Thanks for YOUR patience!

--Markus

[Joe Ardent]

On Wed, Sep 1, 2010 at 2:53 AM, BaiLong <teneigh...@gmail.com> wrote:
>
> Yesterday I played around and tried to comment all the TraitsGeom
> Tests in the makefiles. It did not work because of a missing file.
> But thanks to your help I re-made the project and it ran very smoothly
> to a certain point. It's almost the same error I got yesterday with
> `.rodata.str1.1'
>

> Linking CXX shared module AlembicAbcExport.so

> [snip]

> /usr/bin/ld: /usr/local/hdf5/lib/libhdf5.a(H5.o): relocation
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a
> shared object; recompile with -fPIC
> /usr/local/hdf5/lib/libhdf5.a: could not read symbols: Bad value
>
> After I tried something I again tried to make the project and there it
> already stopped at 78%, with the same error. Could it be that
> something changed the file /usr/local/hdf5/lib/libhdf5.a(H5.o)?
>
> What also confuses me is the "recompile with -fPIC" state. The fPIC
> flag is even set twice.
>

Hi Markus, it looks like your version of HDF5 was not built correctly;
the "recompile with -fPIC" is a message from the linker regarding
libhdf5.a. This is possible if you installed hdf5 via a binary
package manager.

- If you did build hdf5 yourself, did you follow the instructions in
$ALEMBIC_SRC_ROOT/contrib/HDF5.build?

- What is the output of '/usr/local/hdf5/bin/h5cc -showconfig'?

-Joe

[BaiLong]

I did build it myself, following the instructions of their files.

/usr/local/hdf5/bin/h5cc -showconfig gives me:

General Information:
-------------------
HDF5 Version: 1.8.5
Configured on: Tue Aug 17 14:35:33 CEST 2010
Configured by: root@de001pc009
Configure mode: production
Host system: x86_64-unknown-linux-gnu
Uname information: Linux de001pc009 2.6.31-20-generic #58-
Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux
Byte sex: little-endian
Libraries:
Installation point: /usr/local/hdf5

Compiling Options:
------------------
Compilation Mode: production
C Compiler: /usr/bin/gcc ( gcc (GCC) 4.1.3
20080704 )
CFLAGS:
H5_CFLAGS: -std=c99 -pedantic -Wall -Wextra -
Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-
align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-
prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-
decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-
format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -
Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-
statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -
Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-
enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -
Wvolatile-register-var -O3 -fomit-frame-pointer -finline-functions
AM_CFLAGS:
CPPFLAGS:
H5_CPPFLAGS: -D_POSIX_SOURCE -DNDEBUG -
UH5_DEBUG_API
AM_CPPFLAGS: -D_LARGEFILE_SOURCE -
D_LARGEFILE64_SOURCE -D_BSD_SOURCE
Shared Libraries: yes
Static Libraries: yes
Statically Linked Executables: no
LDFLAGS:
AM_LDFLAGS:
Extra libraries: -lz -lm
Archiver: ar
Ranlib: ranlib
Debugged Packages:
API Tracing: no

Languages:
----------
Fortran: no
C++: no

Features:
---------
Parallel HDF5: no
High Level library: yes
Threadsafety: no
Default API Mapping: v18
With Deprecated Public Symbols: yes
I/O filters (external): deflate(zlib)
I/O filters (internal): shuffle,fletcher32,nbit,scaleoffset
MPE: no
Direct VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function Stack Tracing: no
GPFS: no
Strict File Format Checks: no
Optimization Instrumentation: no
Large File Support (LFS): yes
H5dump Packed Bits: yes

Seems to differ in some parts from the HDF5.build.
I'll try to match this output to the settings in the build file. Wish
me Luck. ;)

[BaiLong]

I have rebuild HDF5 resulting in this output of h5cc:

Compiling Options:
------------------
Compilation Mode: production
C Compiler: /usr/bin/gcc ( gcc (GCC) 4.1.3
20080704 )

CFLAGS: -m64 -fPIC

H5_CFLAGS: -std=c99 -pedantic -Wall -Wextra -
Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-
align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-
prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-
decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-
format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -
Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-
statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -
Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-
enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -
Wvolatile-register-var -O3 -fomit-frame-pointer -finline-functions
AM_CFLAGS:
CPPFLAGS:
H5_CPPFLAGS: -D_POSIX_SOURCE -DNDEBUG -
UH5_DEBUG_API
AM_CPPFLAGS: -D_LARGEFILE_SOURCE -
D_LARGEFILE64_SOURCE -D_BSD_SOURCE

Shared Libraries: no

Static Libraries: yes
Statically Linked Executables: no

LDFLAGS: -fPIC
AM_LDFLAGS:
Extra libraries: -lpthread -lz -lm

Archiver: ar
Ranlib: ranlib
Debugged Packages:
API Tracing: no

Languages:
----------
Fortran: no
C++: no

Features:
---------
Parallel HDF5: no
High Level library: yes

Threadsafety: yes

Default API Mapping: v18
With Deprecated Public Symbols: yes
I/O filters (external): deflate(zlib)
I/O filters (internal): shuffle,fletcher32,nbit,scaleoffset
MPE: no
Direct VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function Stack Tracing: no
GPFS: no
Strict File Format Checks: no
Optimization Instrumentation: no
Large File Support (LFS): yes
H5dump Packed Bits: yes

Almost the same as in HDF5.build, only the LDFlags and AM_CPPFLAGS
differ. But I promise I followed the instructions this time.

That still leads to almost the same error at the same linking process,
except that now a different file seems to be causing it:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/
libz.a(compress.o): relocation R_X86_64_32 against `.rodata.str1.1'

can not be used when making a shared object; recompile with -fPIC

/usr/lib/gcc/x86_64-linux-gnu/4.1.3/../../../../lib/libz.a: could not
read symbols: Bad value

I start feeling stupid, asking all these noobish questions! :)

Thanks,
--Markus

[David Hellier]

Hi Markus

The short answer is that you need to make sure all the libraries that
Alembic links to are compiled with -fPIC and that you choose the
64-bit version of that library. That compile error looks like the zlib
library that comes installed with your ubuntu system is actually a
32-bit library. I'm assuming your system is 64-bit ubuntu, in which
case it means you probably have both the 32-bit and 64-bit version of
zlib installed and have chosen the 32-bit version. (or don't have the
64-bit version installed).

When the alembic_bootstrap script prompts for the ZLIB library, make
sure you choose the 64-bit version (e.g. option 2 below). I am not
sure we support 32-bit builds fully yet (we all run 64-bit builds
here)... though contributions in helping us get it compiling are
welcome!

--------

Number of your choice, new value, or blank to accept the default value:
[/usr/include/zlib.h]>
Using value '/usr/include/zlib.h'
Checking /usr/include/zlib.h

Using Zlib include directory: /usr/include
Please enter the full path to the zlib library
(eg, "/usr/lib/libz.a")

Enter the number of the choice you'd like to use, or enter
a different value if none of the choices are valid.

1) /usr/lib/libz.a
2) /usr/lib64/libz.a

------

Thanks for being an early adopter. It helps iron the bugs out for
future developers! :)

Cheers
David

[Joe Ardent]

On Thu, Sep 2, 2010 at 9:09 AM, David Hellier <david....@gmail.com> wrote:
>
> When the alembic_bootstrap script prompts for the ZLIB library, make
> sure you choose the 64-bit version (e.g. option 2 below). I am not
> sure we support 32-bit builds fully yet (we all run 64-bit builds
> here)... though contributions in helping us get it compiling are
> welcome!
>

Yes, currently, it will only build properly on 64-bit systems, due to
the Dimensions class (and the need to deal correctly with different
values for size_t). This issue is known to us and we will likely fix
that soon.

-Joe

[BaiLong]

Thanks for your help.

I'm also running a 64-bit system and by default the /usr/lib64/ was
only a link to /usr/lib/
I tried it anyway to use /usr/lib64/ but nothing changed... :(

Does that mean if have to compile it manually for 64-bit?
how does that work, cause I can't find the lib64z for amd64... o.O

Thanks!

[Joe Ardent]

Hmm, it's strange that your version of libz was not built with
position-independent code (that's what the '-fPIC' flag does). You
can try a couple things, though:

- try using /usr/lib64/libz.so
- download the source to zlib (http://zlib.net/zlib-1.2.5.tar.gz),
and build it yourself, ensuring that it's built with -fPIC, then using
the one you built for Alembic

[David Hellier]

zlib1g-dev is the name of the package for Ubuntu. I have had a look
and it looks like the static archive libz.a isn't compiled with -fPIC.

It exists in the Ubuntu package repository:
http://packages.ubuntu.com/lucid/zlib1g-dev ... you can re-compile it
as a static archive after customizing the build for -fPIC but I
wouldn't recommend it (at least not overriding the version in
/usr/lib64). I assume zlib has it compiled without -fPIC for static
builds for a reason - possibly performance as -fPIC should only be
used on 64-bit machines. I'm not sure if this is a bug in the static
zlib library that comes with ubuntu. anyway, if you want to try the
libz.so file that should work.

you can confirm if the libz.a file is 64-bit by running:

cd tmp; ar -x /usr/lib/libz.a compress.o; objdump -r /tmp/compress.o

[BaiLong]

I can't believe it! I guess that finally did it!
...It still was tricky, though. But it ran trough without complaining.
^^

It is already 9 pm here, so I should go home now. ;)
Tomorrow I'll try to test everything. Hopefully without any further
errors! ;)

Thank you so much Joe and David!!!!

Cheers,
--Markus

[Joe Ardent]

On Thu, Sep 2, 2010 at 12:10 PM, BaiLong <teneigh...@gmail.com> wrote:
> I can't believe it! I guess that finally did it!
> ...It still was tricky, though. But it ran trough without complaining.
> ^^
>

Excellent! It sounds, then, like there's a bug with Ubuntu's zlib
package (the static archive should still be built with -fPIC). If you
get a chance, send me a private message with the output of 'dpkg-query
-s zlib1g' and 'cat /etc/issue', and I'll look into filing a bug with
Ubuntu :)

-Joe

[Kevin Sallée]

I am kind of struggling with the same problem, and since i'm reading this thread to be able to compile (and it's outdated..), i wanted to point out two things:

first the instructions are now in $ALEMBIC_SRC_ROOT/doc/HDF5-howtobuild.txt

and then, in that file, the configure command doesn't work for me (the first two setenvs are not accepted by my shell). Instead, what works is :
./configure --prefix=/usr/local/hdf5-1.8.5-patch1/ --with-pic --disable-shared --enable-production --disable-debug --enable-threadsafe --with-pthread=/usr/include,/usr/lib LDFLAGS="-fPIC" CFLAGS="-m64 -fPIC"

i hope this will help people struggling with the same problem