h5_im.hpp:104 no member named 'ToLocalChecked'

[sanfords]

I've pulled the latest and am executing npm install --build-from-source inside the bundle.

I get the following error:

../src/h5_im.hpp:104:128: error: 'class v8::Local<v8::Object>' has no member named 'ToLocalChecked'
     v8::Local<v8::Object> buffer=node::Buffer::New(v8::Isolate::GetCurrent(), (char*)contentBuffer.get(), planes*width*height).ToLocalChecked();

This is with gcc-5 on Mac OS X. gcc-4.9 too.

Any ideas?

Thank you.

[rimmartin]

You need to be at node 4.2 or later.

Or if you still require node 0.12.x you need to use the 0.0.20 release or the 0.0.19 branch/tag

[sanfords]

Ahh, I see. I have 0.12.x installed. Are there any plans to use NaN instead of updating the module with new releases of Node?

I can probably get it building with LLVM, but starting with NaN would be better. How easy will it be to merge changes in the 0.0.20 branch for 0.12.x in to the 4.x branch?

[rimmartin]

If there is a need or feature needed with 0.12.x I'll add for it as well. Nan has it's own issues and gets in the way of experimenting with V8 so I chose to branch instead.

Let me know what you need. If you use variable length strings for attributes that is one thing I can back port easily.

Also node::Buffer has changed dramatically

And the new branch I'm looking at streams that won't be possible in 0.12.x base.

But if there is something you need from hdf5 functionality post an issue and I'll add it

can gyp be tricked into using LLVM?

[sanfords]

I understand now that you want to move forward with new ideas not compatible with 0.0.12 and NaN. I'll let you know if we need specific features back-ported. Thank you for the explanation and offer!

Regarding gyp on Mac OS X, it's using LLVM. The problem is LLVM finds errors (not warnings) all over the code. (gcc flags a bunch of warnings, but no errors.) Requiring Mac users to install gcc5 is probably not something you want.

The writing is on the wall... 0.0.12 is on the way out. We may be porting our project to 4.x. At that point I should have some time to help out with LLVM compatibility. An effortless Mac build will be a good thing.

:-)

[rimmartin]

Did they change for Mac? I found it using gcc at least 4.9 is needed

I've been building on OSX readily
#13
#10
#4

particularly discussions about homebrew

[sanfords]

Will you continue require homebrew and a custom install of gcc so users can use this project on Mac OS X?

Or should the code be updated so it can compile with LLVM? I'm happy to assist with the latter. :-)

[rimmartin]

this is a gyp issue; not mine

[rimmartin]

I only require -std=c++11 or later

[rimmartin]

https://github.com/nodejs/node-gyp
https://www.npmjs.com/package/node-pre-gyp

[sanfords]

Your definition of c++11 or greater is gcc's interpretation of that standard.

Gyp on Mac uses LLVM. That's just the way it is. Isses #4, #10 and #13 have the same problem. Gyp on Mac will not go out and install gcc5.

You're basically telling any user of any dependency on this library to install gcc5. That's not reasonable.

I understand your position that you are not interested in LLVM compatibility and therefore you are not interested in Mac OS X compatibility.

[sanfords]

Furthermore, I set -std=c++11 in the gyp file, and there are errors all over the place with LLVM.

[rimmartin]

https://github.com/nodejs/node-gyp
quote
On Mac OS X:

python (v2.7 recommended, v3.x.x is not supported) (already installed on Mac OS X)
Xcode
    You also need to install the Command Line Tools via Xcode. You can find this under the menu Xcode -> Preferences -> Downloads
    <b>This step will install gcc and the related toolchain containing make</b>

The other issues #4, #10 and #13 have been resolved

[rimmartin]

We are running and building on OSX 10.7 and 10.10. Which version is yours?

[rimmartin]

nodejs/node-gyp#741 shows that if

gcc --version at the command line returns
❯ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

what happens on yours?

[sanfords]

If you look at bug #4, the user had to download and install gcc49. gcc49 != LLVM.

I don't believe you are building on 10.10 without gcc49 or gcc5 installed specially. If so, then I am sorely mistaken and I apologize.

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

[rimmartin]

Yea I believe the change happened along 10.9

I personally don't have a mac; the 10.7 one was at work

The question comes down to how the binding.gyp can support before and after 10.9

The /include/c++/4.2.1 is a question too if that is claiming to be compatible with gcc 4.2

http://clang.llvm.org/cxx_status.html shows clang version around 3.3 is c++11 compatible; not sure yet how this version translate to the Apple LLVM version

Let's look at what is being done to make the binding.gyp happy. I had experimented with 'MAXOSX_DEPLOYMENT_TARGET': '10.10'
https://github.com/ryancole/hdf5.node/blob/master/binding.gyp#L534 but couldn't tell if it had an effect

[sanfords]

The word "compatible" may not mean what you think it means. ;-)

Some of the C++ you're using is pretty new. I think you're hitting edge cases with LLVM. I was able to quickly work around them here. (Then I got stuck on node 0.12 vs 4.x!)

I can probably get you a login to a Mac OS X 10.11 box if you want.

I'm happy to help!

[rimmartin]

What is your schedule? I'm at work till 6 or 7 ET.

Probably I can first experiment with clang on my ubuntu and see what the versions support. The /include/c++/4.2.1 is worrisome; it may be the 'stable' release of clang is a bit long in the tooth

[rimmartin]

Also I have made quite a few prebuilts that get pulled from amazon so users don't even need to build

[sanfords]

Prebuilts are a pretty cool idea. Although I have a feeling once you're LLVM compatible you'll be happily gcc and llvm compatible. It'll simplify things substantially, think.

Let me check on clang... their web site says 3.7.1. And that's really annoying me. I'll let you know what comes back. 3.7.1 from that site could be the same as 7.0.2. But I don't know for sure.

http://llvm.org

[rimmartin]

k,

What added complexity to prebuilts was supporting hdf5 versions; the matrix gets large and npm and node-pre-gyp don't help out on this

[rimmartin]

I used clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04 successfully last night with my kind of code. Now looking for binding.gyp formatting to condition for different compilers on Mac OS X versions.

[rimmartin]

there is now a branch for code changes for nodejs v0.12.x compatibility
https://github.com/ryancole/hdf5.node/tree/v0.12.x

[rimmartin]

There is a CLANG_CXX_LANGUAGE_STANDARD for xcode_settings that sets dialect
nodejs/node-gyp#252

looking for an example and what values it can be set to

[rimmartin]

nodejs/node-gyp#469

[rimmartin]

'CLANG_CXX_LANGUAGE_STANDARD':'c++11',

[sanfords]

Sorry, I got pulled away.

I don't see that updated in the binding.gyp file in branch 0.12.x. Did you update it?

I do the following:

1. Pull 0.12. x.
2. Enter the directory for the project.
3. Utter node-gyp rebuild
   I see:

gyp: Undefined variable module_name in binding.gyp while trying to load binding.gyp
configure error

[rimmartin]

I did not add it because I can't test it; can't afford the latest apple equipment:-)

it doesn't build with node-gyp; it builds with node-pre-gyp
there are two scripts in the package.json
https://github.com/ryancole/hdf5.node/blob/v0.12.x/package.json#L31
and you build with

$NODE_HOME/bin/npm install  --build-from-source

or

$NODE_HOME/bin/npm install --fallback-to-build

With the one mac box at work I can test that certain xcode_settings don't bust prior builds

[rimmartin]

when it gets to setting up, the build folder should have a project that is open'able by XCode; at least that's what happens on a windows box; can open and explore the project with VS2013; that is how I learned how to configure for windows.

And I think that is why gyp doesn't have project type documentation; it assumes we'll look with the native tool