Invalid deployment target for -stdlib=libc++ on OSX 10.8 - c++

I am compiling through node-gyp a Node.JS package written in C++. When I compile it I receive the following error: clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later). I'm running on OSX 10.8, and I have installed the XCode Command Line Tools. This is the file used by node-gyp to compile the package:
{
"targets": [
{
"target_name": "package_name",
'type': 'executable',
'xcode_settings': {
'OTHER_CFLAGS': [
"-std=c++11",
"-stdlib=libc++"
],
},
"sources": [ "package_src.cpp" ],
}
]
}
Basically it specifies the target of the compilation, the type and the flags, as well as the sources.
Any idea on how I can solve this problem?

Whilst you got OS X 10.8 clang will try to build it so that it can be run on other older OS X versions too. Now since -stdlib=libc++ requires a minimum version of 10.7 it won't compile it unless you explicitly tell it that you'll use 10.7 (or higher) as the deployment target by specifying
'MACOSX_DEPLOYMENT_TARGET': '10.7'
inside the xcode_settings.
In your case the complete settings should look like:
{
"targets": [
{
"target_name": "package_name",
'type': 'executable',
'xcode_settings': {
'MACOSX_DEPLOYMENT_TARGET': '10.7',
'OTHER_CFLAGS': [
"-std=c++11",
"-stdlib=libc++"
],
},
"sources": [ "package_src.cpp" ],
}
]
}

I don't know what worked for you, #drewish, but this is how I got it to work:
{
"targets": [
{
"target_name": "package_name",
'type': 'executable',
'xcode_settings': {
'OTHER_CFLAGS': [
"-std=c++11",
"-stdlib=libc++",
"-mmacosx-version-min=10.7"
],
},
"sources": [ "overcpu.cpp" ],
}
]
}

Related

"The specified module could not be found" when using a custom nodejs addon

I am writing a nodejs addon that depends on OpenGL (glfw). It compiles successfully but when I try and use it in node I get the error The specified module could not be found.
This is the problematic part of the addon C++ code:
#include <glfw/glfw3.h>
if(glfwInit()) {
printf("glfw init success");
}
else {
printf("glfw init failed");
}
With this in the addon, it compiles but causes the error in node. Without this it compiles and runs without issue.
Here is my binding.gyp:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"<(module_root_dir)/addon/lib/gl/glfw3dll.lib"
],
"include_dirs": [
"addon/lib",
"<!#(node -p \"require('node-addon-api').include\")"
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
}
]
}
And the addon file structure:
addon
lib
glfw
glfw3.dll
glfw3.h
glfw3.lib
glfw3dll.lib
glfw3native.h
opengl32.lib
addon.cc
Edit:
New binding.gyp:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"-lglfw3dll",
"-lopengl32",
"-L<module_root_dir)/lib/glfw",
"-Wl,-rpath,\$$ORIGIN/../../lib",
],
"include_dirs": [
"addon/lib",
'<!#(node -p "require(\'node-addon-api\').include")'
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
}
]
}
I'm not sure this is your issue but it can be a bit tricky to convince the loader to load a specific library in a local directory. I added this section to my the targets array in binding.gyp.
The trick is to tell the linker look for the library relative to $ORIGIN(where the addon is). Because the addon is in build/Release then $ORIGIN is build/Release and ../../ gets you back to the module root.
It just took trial and error to find the right way to specify $ORIGIN via binding.gyp and the linker's quoting rules. \$$ORIGIN resulted in $ORIGIN being embedded in the node addon.
'conditions': [
['OS in "linux"', {
# includes reference glfw3dll/glfw3dll.h, so
'include_dirs': [
'<!#(node -p "require(\'node-addon-api\').include")',
'<(module_root_dir)/'
],
'libraries': [
'-lglfw3dll',
'-L<(module_root_dir)/dir-for-glfw3dll/',
'-Wl,-rpath-link,<(module_root_dir)/dir-for-glfw3dll/',
'-Wl,-rpath,\$$ORIGIN/../../dir-for-glfw3dll/'
],
}]
]
(I changed the name of my file to your file and put it in a directory directly under the module_root_dir.)
I managed to get it working with this binding.gyp file:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"legacy_stdio_definitions.lib",
"msvcrt.lib",
"msvcmrt.lib",
"<(module_root_dir)/addon/lib/glfw/opengl32.lib",
"<(module_root_dir)/addon/lib/glfw/glfw3.lib"
],
"include_dirs": [
"addon/lib",
'<!#(node -p "require(\'node-addon-api\').include")',
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]
}
]
}
Just in case someone else has the same issue and ends up here. The libraries that are required by the addon needs to be within reach on runtime, even if the linker managed to find it.
For example if this is on Windows, and you linked with foo.lib during your build/link, during runtime, foo.dll should be either in the same folder (for me it worked in the same folder as .node) or in a folder in the path. Otherwise it wont be loaded and this error will be thrown. Very unexplanatory error in my opinion.
Also, keeping the libraries in the same folder as the .node helps with segregating the different arch builds & dependancies (x86, x64 etc).

polymer 3: code not work after polymer build

my polymer.json
{
"entrypoint": "index.html",
"shell": "src/boo-blogger/boo-blogger.js",
"sources": [
"images/*",
"fonts/*"
],
"extraDependencies": [
"manifest.json",
"node_modules/#webcomponents/webcomponentsjs/*.js",
"node_modules/web-animations-js/web-animations-next-lite.min.js",
"node_modules/#webcomponents/webcomponentsjs/bundles/*.js"
],
"builds": [
{
"name": "es6",
"bundle": true,
"browserCapabilities": [
"es2015",
"modules"
],
"js": {
"minify": true,
"transformModulesToAmd": true
},
"html": {
"minify": true
},
"css": {
"minify": true
},
"addServiceWorker": true
}
],
"npm": true,
"lint": {
"rules": [
"polymer-3"
]
}
}
I got the problem
article-list.js:5 Uncaught (in promise) TypeError: _booBlogger.html$1 is not a function
article-list.js imported dynamic by routing. So I tried to attempt some build option differently to build. I found when I build without bundle, built code can work. I don't know why my code can not bundle by polymer build. if anyone is curious the problem and need completely source code. contact me
tools summary
system: ubuntu 16.04
polymer: 1.7.7
node: 10.1.0
In your polymer.json you need to add:
"fragments": [
"src/article-list.js"
],
I think you forgot to add article-list.js to your sources. As it is written in docs you have to include your dynamically imported modules to "sources" in polymer.json. See https://polymer-library.polymer-project.org/3.0/docs/apps/build-for-production#dynamic

g++ build errors with node-gyp rebuild for Node.js Addon

Here is my bindings.gyp file:
{
"targets": [
{
"target_name": "hello",
"sources": [ "hello.cpp" ],
"include_dirs": [
"<!(node -e \"require('nan')\")"
],
"cflags" : [ "-std=c++1", "-stdlib=libc++" ],
"conditions": [
[ "OS!='win'", {
"cflags+": [ "-std=c++11" ],
"cflags_c+": [ "-std=c++11" ],
"cflags_cc+": [ "-std=c++11" ],
}],
[ "OS=='mac'", {
"xcode_settings": {
"OTHER_CPLUSPLUSFLAGS" : [ "-std=c++11", "-stdlib=libc++" ],
"OTHER_LDFLAGS": [ "-stdlib=libc++" ],
"MACOSX_DEPLOYMENT_TARGET": "10.7"
},
}],
],
}
]
}
when running
sudo node-gyp rebuild
I get these errors:
make: Entering directory '/home/oleg/WebstormProjects/oresoftware/replace-line/build'
CXX(target) Release/obj.target/hello/hello.o
g++: error: unrecognized command line option ‘-std=c++1’
g++: error: unrecognized command line option ‘-stdlib=libc++’
hello.target.mk:106: recipe for target 'Release/obj.target/hello/hello.o' failed
from the error trace, seems clear that we are using g++ not gcc, and my g++ version is:
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
and yep I am on Ubuntu 16.04
Does anyone know why this error is occurring?
You have -std=c++1, which is a typo, it should be: -std=c++11.
Also, -stdlib is a clang option (not g++). For g++ libstdc++ is always used.

What is wrong with this GYP file?

I am using a simple GYP file to build a simple D program. The GYP file follows:
{
'targets': [
{
'target_name': 'bin/launchprogram',
'type': 'executable',
'sources': [
'src/launchprogram.d',
],
'actions': [
{
'action_name': 'gdc',
'inputs': [
'src/launchprogram.d'
],
'outputs': [
'bin/launchprogram'
],
'action': [
'gdc',
'-o', 'bin/launchprogram',
'-O3', '-march=native',
'src/launchprogram.d'
],
},
],
},
],
}
The compilation doesn't work -- it tries to run g++ on the produced executable and that of course fails. What did I do wrong?
This is my first attempt at using GYP, so please be patient.
It works when I change the executable type to 'none', to keep GYP from trying to link.

using c++11 with GYP project

I am trying to create a simple cross platform C++ project with gyp. Currently I'm just trying this on a mac - but would like to get it to build for windows, Linux, ios and android eventually.
HEre is the simple gyp file that I'm using.
I would like to be able to use ninja as well as xcode/msvc projects from this gyp.
I know that I need to be able to add
-std=c++11 and -libstdc++ to the commandline for clang, but right now I only see the generated build files using g++ instead of clang.
This is my gyp file.
{
'targets': [
{
'target_name': 'libtest',
'product_name': 'test',
'type': 'static_library',
'sources': [
'./src/lib.cpp',
],
'include_dirs': [
'include',
],
},
{
'target_name': 'testapp',
'type': 'executable',
'sources': [
'./test/test.cpp',
],
'include_dirs': [
'src',
],
'dependencies': [
'libtest'
],
},
],
}
I've sort of figured out this to a certain extent. At lesast I got it working on the mac for a makefile build ( not ninja which was my original hope).
First I had to get gyp to use clang instead of g++ , to do this I had to add a make_global_settings to the gyp file as so. This doesn't seem like a good plan for a crossplatform build. I was also able to set these with environment variables, I'm guessing I can probably do something with conditions to make this specific to the mac.
'make_global_settings': [
['CXX','/usr/bin/clang++'],
['LINK','/usr/bin/clang++'],
],
'targets':
[
......
The other thing I had to do was add an xcode_settings dictionary with OTHER_CPLUSPLUSFLAGS and OTHER_LDFLAGS depending on the target type. Full example below.
{
'make_global_settings': [
['CXX','/usr/bin/clang++'],
['LINK','/usr/bin/clang++'],
],
'targets': [
{
'target_name': 'mylib',
'product_name': 'mylib',
'type': 'static_library',
'sources': [
'src/implementation.cc',
],
'include_dirs': [
'include',
],
'conditions': [
[ 'OS=="mac"', {
'xcode_settings': {
'OTHER_CPLUSPLUSFLAGS' : ['-stdlib=libc++'],
},
}],
],
},
{
'target_name': 'myapp',
'type': 'executable',
'sources': [
'./bin/myapp.cc',
],
'conditions': [
[ 'OS=="mac"', {
'xcode_settings': {
'OTHER_CPLUSPLUSFLAGS' : ['-std=c++11','-stdlib=libc++'],
'OTHER_LDFLAGS': ['-stdlib=libc++'],
},
}],
],
'include_dirs': [
'include',
],
'dependencies': [
'mylib'
],
},
],
}
So I just tried this on the clang++ 6 OSX 10.10 and I ran into the same problem that drewish hit.
Adding -mmacosx-version-min=10.7 to the OTHER_CPLUSPLUSFLAGS and OTHER_LDFLAGS arrays fixed the issue.
EDIT
An even better way that I found to fix this is to add "MACOSX_DEPLOYMENT_TARGET": "10.7" into the xcode_settings array. This will override any defaults that Node sets in its common.gypi file.
So it should look something like this
{
'targets': [
{
'target_name': 'myApp',
'sources': [ 'myApp.cc' ]
'conditions': [
['OS=="mac"', {
'xcode_settings': {
'MACOSX_DEPLOYMENT_TARGET': '10.7'
}
}]
]
}
]
}
johnhaley81's solution is really the simplest one to get this working (at least on OSX), however I had to add a few more settings:
"conditions": [
[ 'OS=="mac"', {
"xcode_settings": {
'MACOSX_DEPLOYMENT_TARGET': '10.9',
"CLANG_CXX_LIBRARY": "libc++",
"GCC_ENABLE_CPP_RTTI": "YES",
"GCC_ENABLE_CPP_EXCEPTIONS": "YES"
},
}],
],
As you can see, you can directly use the name/value pairs from an XCode project here. Pretty handy.
The previous answers were helpful, but all that must actually be added to xcode_settings are 'MACOSX_DEPLOYMENT_TARGET': '10.7' and 'CLANG_CXX_LIBRARY': 'libc++'
{
'targets': [
{
'target_name': 'myApp',
'sources': [ 'myApp.cc' ]
'conditions': [
['OS=="mac"', {
'xcode_settings': {
'MACOSX_DEPLOYMENT_TARGET': '10.7',
'CLANG_CXX_LIBRARY': 'libc++'
}
}]
]
}
]
}
Specifically, the option 'CLANG_CXX_LIBRARY': 'libc++' is what's getting us what we want. If you add this option without 'MACOSX_DEPLOYMENT_TARGET': '10.7' then you might see the following error:
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
This error indicates that 10.7 is a more appropriate value than 10.9 for MACOSX_DEPLOYMENT_TARGET if you're interested in compatibility.