Build failing on OS X Yosemite (10.10) about hdf5.node HOT 27 CLOSED

Hi, which hdf5 version?

I have access to a MacOSX at work; will try it there tomorrow. Those OS X flag switches you found will be helpful.

H5Aiterate is something I just changed to to remove all use of the HDF5 C++library and go with just the c interface.

Another project of mine builds on MacOSX; it's binding looks like https://github.com/rimmartin/saxon-node/blob/master/binding.gyp

For this project the $(HDF5_HOME) is important. I'll be focusing on adding MacOSX and Windows builds this week.

from hdf5.node.

Oh the lambda function

[&](hid_t loc, const char* attr_name, const H5A_info_t* ainfo, void *operator_data) -> herr_t

might not be working on the Mac build.
Needs to match
typedef herr_t (_H5A_operator2_t)( hid_t location_id/in/, const char *attr_name/in/, const H5A_info_t *ainfo/in/, void op_data/_in,out/)

Maybe this will need changed to make it happy

from hdf5.node.

I put linux, win and mac conditions in the binding.gyp and 'OTHER_CPLUSPLUSFLAGS' as you pointed to made gyp work with xcode and it builds. Thank you for finding this! My other project was using 'OTHER_CFLAGS' which wasn't setting it for c++11 either so I'm correcting that project too.

mocha tests ran on the work mac( it was still node-v0.11.16-01312015). Will get them to upgrade it.

Published to npm for module style. Next win target

from hdf5.node.

Hi,

Good that the find was useful for you. My HDF5 version is 1.8.13. Do you need additional info?

from hdf5.node.

no, I think it should build on mac now. Both from github and npm.

my windows build environment still has a problem so not working on windows yet.

Let me know of any aspects you need working. I'm developing more of the high level and data types for attributes and datasets.

from hdf5.node.

I'm running 10.10.3 with HDF5 1.8.12 and I'm also seeing:

In file included from ../src/h5ds.cc:2:
In file included from ../src/file.h:14:
../src/attributes.hpp:39:13: error: no matching function for call to 'H5Aiterate2'
            H5Aiterate(group->id,H5_INDEX_NAME, H5_ITER_INC, &index, [&](hid_t loc, const char* attr_name, const H5A_info_t* ainfo, void *operator_data) -> herr_t {
            ^~~~~~~~~~
/usr/local/include/H5version.h:169:20: note: expanded from macro 'H5Aiterate'
#define H5Aiterate H5Aiterate2
                   ^~~~~~~~~~~
/usr/local/include/H5Apublic.h:74:16: note: candidate function not viable: no known conversion from '(lambda at ../src/attributes.hpp:39:70)' to 'H5A_operator2_t'
      (aka 'herr_t (*)(hid_t, const char *, const H5A_info_t *, void *)') for 5th argument
H5_DLL herr_t  H5Aiterate2(hid_t loc_id, H5_index_t idx_type,
               ^
In file included from ../src/h5ds.cc:4:

from hdf5.node.

if you run
xcodebuild -version
what do you get?
Mine is 4.6.3; probably much older. Maybe the newer compiler wants something more specific from this lambda callback that the older lets go by. Or there is a different way to pick c++11. I'm checking about trying this on a 10.10.x mac
I'll also put HDF5 1.8.12 on a box and test with it.

from hdf5.node.

$ xcodebuild -version
Xcode 6.3
Build version 6D570

from hdf5.node.

Hi, question below: The high level image API http://www.hdfgroup.org/HDF5/doc/HL/RM_H5IM.html is inadequate for many images so I am extending the node h5im to the Image Spec 1.2 http://www.hdfgroup.org/HDF5/doc/ADGuide/ImageSpec.html Have the bit data flowing via node Buffer's and flowing to and from koa web interface with binaryjs http://binaryjs.com/. Drag&drop.

Took care of resource leaks on the native side that were on my mind.

Late tonight and tomorrow I'm going to work on compiling on mac and windows.

Not doing it immediately but am thinking of adding "High-level Functions for Region References, Hyperslabs, and Bit-fields" http://www.hdfgroup.org/projects/jpss/documentation/HL/RM/index.html
This software needs to be downloaded [ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/NPOESS/source] and installed separately from the main hdf5 library.

Would this extra dependency cause you difficulties? Haven't tried yet on mac. This could be useful for viewfinding very large images.

My own application is ~1440 2048x2048 images in a stack which are projections from a 3d density

from hdf5.node.

[interacting with sys admin takes time]
I'm suspecting node-gyp versions; trying to get to nodejs v0.12 and node-gyp 1.0.3

http://skitr.com/2014/05/11/node-js-addons-and-c11/ indicates a MACOSX_DEPLOYMENT_TARGET for xcode settings that might assist

              [ 'OS=="mac"', {
                "xcode_settings": {
                    'OTHER_CPLUSPLUSFLAGS' : ['fPIC','-std=c++11','-fexceptions'],
                    'OTHER_LDFLAGS': [],
                    'MACOSX_DEPLOYMENT_TARGET': '10.7'
                }
            }]

when I set to 10.10 it didn't effect my build on 10.7. But if I set it to nonsense it complains so I know it is getting picked up.. Not sure if the mechanism for setting c++11 changed by the 10.10 OS

adding "-stdlib=libc++" caused complaint on MacOSX 10.7

from hdf5.node.

MacOSX 10.7 nodejs v0.12 and node-gyp v1.0.3 builds successfully. On Monday or Tuesday I'll have access to a machine with MacOSX 10.10 on it to test

from hdf5.node.

My OS X 10.10 doesn't build with [email protected] and [email protected], unfortunately. Still the 'candidate function is not viable' error.

I used your exact xcode_settings object.

from hdf5.node.

Is this of any help?

http://blogs.encamina.com/returnvalue/2014/05/29/node-js-addons-c11/

Sent from my iPhone

On May 6, 2015, at 3:11 AM, arryon [email protected] wrote:

My OS X 10.10 doesn't build with [email protected] and [email protected], unfortunately. Still the 'candidate function is not viable' error.

—
Reply to this email directly or view it on GitHub.

from hdf5.node.

It seems the lambda function is not working in Clang properly. If replaced with a private static member, the file builds just fine:

class Attributes : public node::ObjectWrap {
    private:
        static herr_t pushback (hid_t loc, const char* attr_name, const H5A_info_t* ainfo, void *operator_data) {
          ((std::vector<std::string>*)operator_data)->push_back(attr_name);
          return 0;
        };

H5Aiterate(group->id,H5_INDEX_NAME, H5_ITER_INC, &index, pushback, &holder);

I forked the repository to try and compile it on OS X, [email protected], [email protected], [email protected].
I found another error related to narrowing so I fixed that, probably quick and dirty because I never code C++. See the commit here:
arryon@d8984b6

Unfortunately, the errors are not gone yet. Currently baffled by the following:

In file included from ../src/h5tb.cc:2:
In file included from ../src/file.h:7:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:627:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:875:22: error: implicit
      instantiation of undefined template 'std::__1::__pointer_traits_element_type<std::__1::__tuple_leaf<2, std::__1::unique_ptr<unsigned long
      [], std::__1::default_delete<unsigned long []> >, false>, false>'
    typedef typename __pointer_traits_element_type<pointer>::type    element_type;

I have no idea where that comes from. Hopefully it's just an included order error, and someone here knows an easy fix.
It appears Clang is stricter than g++, which would explain the difficulty building. If possible, I'll also try to build using g++ instead of the Apple LLVM to build the package, then report back.

from hdf5.node.

very hard to build with g++ on mac because the gyp is designed for xcode clang. Would have to make all the make files by another tool other than node-gyp but achieve what node-gyp does.

What I don't get is why 10.7 builds. I have the possibility of borrowing a 10.10 today; a c++11 lambda function should be gravy for an even more modern version of xcode and clang

from hdf5.node.

@dwstevens same info as the link above
http://skitr.com/2014/05/11/node-js-addons-and-c11/
on 10.7 I had to remove the -stdlib=libc++ part; I wouldn't expect OTHER_LDFLAGS to help either because mac is DYLD

from hdf5.node.

also some googling says later macs don't ship g++ anymore but a wrapper of clang++ called g++.

Would apparently have to build gcc/g++ from its source

from hdf5.node.

I think you can just use homebrew to install it, although there was some trouble with it a few months back.

from hdf5.node.

I added a -v
'OTHER_CPLUSPLUSFLAGS' : ['fPIC','-std=c++11','-fexceptions','-v'],

and get compile info showing what switches it really is building with
for example

COLLECT_GCC_OPTIONS='-D' '_DARWIN_USE_64_BIT_INODE=1' '-D' '_LARGEFILE_SOURCE' '-D' '_FILE_OFFSET_BITS=64' '-D' 'BUILDING_NODE_EXTENSION' '-I' '/Users/Shared/Jenkins/.node-gyp/0.12.0/src' '-I' '/Users/Shared/Jenkins/.node-gyp/0.12.0/deps/uv/include' '-I' '/Users/Shared/Jenkins/.node-gyp/0.12.0/deps/v8/include' '-I' '/Users/Shared/Jenkins/NodeProjects/hdf5/include' '-Os' '-gdwarf-2' '-mmacosx-version-min=10.5' '-m64' '-Wall' '-Wendif-labels' '-Wextra' '-Wno-unused-parameter' '-fno-rtti' '-fno-threadsafe-statics' '-fPIC' '-O4' '-std=c++11' '-fexceptions' '-v' '-MMD' '-MF' './Release/.deps/Release/obj.target/h5ds/src/h5ds.o.d.raw' '-c' '-o' 'Release/obj.target/h5ds/src/h5ds.o' '-shared-libgcc' '-mtune=core2'

for the 10.7 target the -std=c++11 is there from node-gyp reading the binding.gyp file. There are five place where OTHER_CPLUSPLUSFLAGS exists in binding.gyp

from hdf5.node.

it also appears to build the last target_name first; so I test h5ds with changes first

from hdf5.node.

g++ --version
give you what?

from hdf5.node.

Wow I had completely gotten it wrong when I learned "xcode_settings" was needed conditionally on the macs. Th doesn't mean it doesn't use g++; the node-gyp apparently is picking up the 4.9.0 built on the company's 10.7 box
The https://www.npmjs.com/package/node-gyp right up front says "A proper C/C++ compiler toolchain, like GCC" on Unix and doesn't distinguish mac from linux. I see from the -v output

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../x86_64-apple-darwin11.4.2/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/Shared/Jenkins/.node-gyp/0.12.0/src
 /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/uv/include
 /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/v8/include
 /Users/Shared/Jenkins/NodeProjects/hdf5/include
 /share/apps/intel/mac/composer_xe_2011_sp1.9.289/mkl/include
 /opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0
 /opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0/x86_64-apple-darwin11.4.2
 /opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0/backward
 /opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/include
 /usr/local/include
 /opt/gcc/gcc-4.9.0-06022014/include
 /opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C++ (GCC) version 4.9.0 (x86_64-apple-darwin11.4.2)
    compiled by GNU C version 4.9.0, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1

and

 /opt/gcc/gcc-4.9.0-06022014/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/cc1plus -quiet -v -I /Users/Shared/Jenkins/.node-gyp/0.12.0/src -I /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/uv/include -I /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/v8/include -I /Users/Shared/Jenkins/NodeProjects/hdf5/include -MMD Release/obj.target/h5ds/src/h5ds.d -MF ./Release/.deps/Release/obj.target/h5ds/src/h5ds.o.d.raw -MQ Release/obj.target/h5ds/src/h5ds.o -D__DYNAMIC__ -D _DARWIN_USE_64_BIT_INODE=1 -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D BUILDING_NODE_EXTENSION ../src/h5ds.cc -fPIC -quiet -dumpbase h5ds.cc -mmacosx-version-min=10.5 -m64 -mtune=core2 -auxbase-strip Release/obj.target/h5ds/src/h5ds.o -gdwarf-2 -Os -O4 -Wall -Wendif-labels -Wextra -Wno-unused-parameter -std=c++11 -version -fno-rtti -fno-threadsafe-statics -fPIC -fexceptions -o /var/folders/ns/087m

The xcode_settings used just to allow for different configurations between mac and say ubuntu? For some of the few compiler switch differences

I'm sorry. I should have looked at this sooner. The version of xcodebuild may not be important at all.

Just need a c++11 level of g++

from hdf5.node.

Also, through homebrew we have access to many different gcc versions

➜ theGrid git:(dev) ✗ brew search gcc

gcc

homebrew/versions/gcc43 homebrew/versions/gcc45
homebrew/versions/gcc47 homebrew/versions/gcc49
homebrew/versions/llvm-gcc28

homebrew/versions/gcc44 homebrew/versions/gcc46
homebrew/versions/gcc48 homebrew/versions/gcc5
homebrew/dupes/apple-gcc42

On Wed, May 6, 2015 at 2:34 PM, David Stevens [email protected] wrote:

On 10.10.3 I get

➜ theGrid git:(dev) ✗ g++ --version

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1

Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)

Target: x86_64-apple-darwin14.3.0

Thread model: posix

➜ theGrid git:(dev) ✗

On Wed, May 6, 2015 at 1:15 PM, rimmartin [email protected]
wrote:

Wow I had completely gotten it wrong when I learned "xcode_settings" was
needed conditionally on the macs. Th doesn't mean it doesn't use g++; the
node-gyp apparently is picking up the 4.9.0 built on the company's 10.7 box
The https://www.npmjs.com/package/node-gyp right up front says "A proper
C/C++ compiler toolchain, like GCC" on Unix and doesn't distinguish mac
from linux. I see from the -v output

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../x86_64-apple-darwin11.4.2/include"
#include "..." search starts here:
#include <...> search starts here:
/Users/Shared/Jenkins/.node-gyp/0.12.0/src
/Users/Shared/Jenkins/.node-gyp/0.12.0/deps/uv/include
/Users/Shared/Jenkins/.node-gyp/0.12.0/deps/v8/include
/Users/Shared/Jenkins/NodeProjects/hdf5/include
/share/apps/intel/mac/composer_xe_2011_sp1.9.289/mkl/include
/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0
/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0/x86_64-apple-darwin11.4.2
/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/../../../../include/c++/4.9.0/backward
/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/include
/usr/local/include
/opt/gcc/gcc-4.9.0-06022014/include
/opt/gcc/gcc-4.9.0-06022014/lib/gcc/x86_64-apple-darwin11.4.2/4.9.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C++ (GCC) version 4.9.0 (x86_64-apple-darwin11.4.2)
compiled by GNU C version 4.9.0, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1

and

/opt/gcc/gcc-4.9.0-06022014/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/cc1plus -quiet -v -I /Users/Shared/Jenkins/.node-gyp/0.12.0/src -I /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/uv/include -I /Users/Shared/Jenkins/.node-gyp/0.12.0/deps/v8/include -I /Users/Shared/Jenkins/NodeProjects/hdf5/include -MMD Release/obj.target/h5ds/src/h5ds.d -MF ./Release/.deps/Release/obj.target/h5ds/src/h5ds.o.d.raw -MQ Release/obj.target/h5ds/src/h5ds.o -D__DYNAMIC__ -D _DARWIN_USE_64_BIT_INODE=1 -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -D BUILDING_NODE_EXTENSION ../src/h5ds.cc -fPIC -quiet -dumpbase h5ds.cc -mmacosx-version-min=10.5 -m64 -mtune=core2 -auxbase-strip Release/obj.target/h5ds/src/h5ds.o -gdwarf-2 -Os -O4 -Wall -Wendif-labels -Wextra -Wno-unused-parameter -std=c++11 -version -fno-rtti -fno-threadsafe-statics -fPIC -fexceptions -o /var/folders/ns/087m

The xcode_settings used just to allow for different configurations
between mac and say ubuntu? For some of the few compiler switch differences

I'm sorry. I should have looked at this sooner. The version of xcodebuild
may not be important at all.

Just need a c++11 level of g++

—
Reply to this email directly or view it on GitHub
#4 (comment).

from hdf5.node.

I take it the little guy in yer avatar is an expert on homebrew:-)

from hdf5.node.

thanks for the homebrew hint. would be nice to be able to do it with the default compiler but for now i used

brew install gcc49
export CXX=/usr/local/bin/gcc-4.9

did the trick and it builds with node 0.12 on osx 10.10.3 without any changes to the current master

from hdf5.node.

Good, 4.9 has been solid. I'm going through eliminating compiler warnings though at times rewrites change quite a bit on the native side. Also am trying not to depend on specialized libraries so that users can make their own choices such as image processing libraries. Am testing with gcc-5.

Let me know of any h5 features you need. For example I've started experimenting with filters and compression and adding capability for the registered third party filters http://www.hdfgroup.org/services/contributions.html because one of the h5's I'm using is made by other software. However I'm interested in completing useful portions of the API for anyone applying this project.

from hdf5.node.

thanks, that's good to know! i am currently moving a project to use hdf5 for dataset storage so i am really at the beginning and still figuring out what i need exactly and what's already there

from hdf5.node.