h5_im.hpp:104 no member named 'ToLocalChecked' about hdf5.node HOT 29 CLOSED

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

from hdf5.node.

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?

from hdf5.node.

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?

from hdf5.node.

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.

:-)

from hdf5.node.

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

from hdf5.node.

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. :-)

from hdf5.node.

this is a gyp issue; not mine

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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.

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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?

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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!

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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.

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

nodejs/node-gyp#469

from hdf5.node.

'CLANG_CXX_LANGUAGE_STANDARD':'c++11',

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.

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

from hdf5.node.