I just want to make a little test with GLFW3 D binding.
I create a new package using
dub init glfw3Test
Then I wrote a little test in glfw3Test\source\app.d
import derelict.glfw3.glfw3;
void main()
{
// Load the GLFW 3 library.
DerelictGLFW3.load();
if(DerelictGLFW3.isLoaded)
{
// Do something cool!
}
}
And I modified the default JSON with:
{
"name": "glfw3Test",
"dependencies":
{
"derelict-glfw3": "~master"
},
"configurations": [
{
"name": "glfw3Test",
"targetType": "executable"
}
]
}
I built with dub build, everything went fine, but when I tred to launch the executable I got the following errors:
derelict.util.exception.SharedLibLoadException#../../../.dub/packages/derelict-util-1.0.2/source/derelict/util/exception.d(35): Failed to load one or more shared libraries:
libglfw.3.dylib - dlopen(libglfw.3.dylib, 2): image not found
libglfw3.dylib - dlopen(libglfw3.dylib, 2): image not found
I have also tried to compile my application manually without using DUB, but I got always the same problem.
It seems to look for the GLFW3 shared library, but I was thinking that the lib is statically linked by the built process.
I am on OS X 10.10 with Xcode 6 installed (DMD compiler 2.065)
I've noticed that the default make process of GLFW3 (using cmake) does not create the dylib files. So I rebuilt GLFW with the following option:
cmake -D BUILD_SHARED_LIBS=ON
And then I made a make install, so now the file libglfw.dylib is correctly installed in /usr/local/lib
Thank to #duselbaer for make me noticed this problem.
Related
I try to create an example using SWIG and NodeJS on my M1 (arm64) Mac,
but I want to mention this as early as possible:
this issue appears also on an Intel (x64) Mac.
I create my simple example Files like this:
example.h
#pragma once
class Die
{
public:
Die();
~Die();
int foo(int a);
};
Die* getDie();
//to test if the issue also appears getting a simple functiom without any class context.
extern "C"
{
bool getFoo();
}
here is the implementation.
example.cpp
#include <iostream>
#include "example.h"
int Die::foo(int a)
{
std::cout << "foo: running fact from simple_ex" << std::endl;
return 1;
}
Die::Die()
{
}
Die::~Die()
{
}
// out of Class Context
Die* getDie()
{
return new Die();
}
extern "C"
{
bool getFoo()
{
return true;
}
}
my Swig interface is as follows:
example.i
%module example
%{
#include "example.h"
%}
%include "example.h"
then i create my example_warp.cxx file. But as actually the 4.0.2 Version of Swig is not compatible with NodeJs v16.0.0 (read SWIG support for NodeJS v12 #1520 and Prepare SWIG for Node.js v12 #1746).
Therefore i needed to build swig from source using master branch with the current version (4.1.0). Please keep that in mind.
Swig Command:
swig -Wall -c++ -javascript -node example.i
Here now some files preparing to create the .node file
package.json
{
"name": "SwigJS",
"version": "0.0.1",
"scripts": {
"start": "node index.js",
"install": "node-gyp clean configure build"
},
"dependencies": {
"nan": "^2.16.0",
"node-gyp": "^9.0.0"
},
"devDependencies": {
"electron-rebuild": "^3.2.7"
}
}
the package.json i got from a mate as an example an edited it to work with my project so there may be some lines not really needed by me.
binding.gyp
{
"targets": [
{
"target_name": "SwigJS",
"sources": [ "example_wrap.cxx" ],
"include_dirs" : [ "<!(node -e \"require('nan')\")" ]
}
]
}
now i build my SwigJS.node file using:
node-gyp configure
node-gyp build
it runs through without any errors.
Now i try to access the node-file in my JavaScript but i always get the error message:
missing symbol called
index.js
const Swigjs = require("./build/Release/SwigJS.node");
console.log("exports :", Swigjs); //show exports
die = Swigjs.getDie(); //try to get the Class
console.log(die.foo(5)); //call a function from the class
the output looks like this:
[Running] node "/Users/rolf/Documents/SwigJS/index.js"
exports : {
getDie: [Function (anonymous)],
getFoo: [Function (anonymous)],
Die: [Function: Die]
}
dyld[49745]: missing symbol called
[Done] exited with code=null in 0.12 seconds
What i have tried to find the error:
tried to build the .node file on an x64 architecture to check if it is an arm topic with NodeJS v16:17 on an Intel x64 Mac from a mate.
installed NodeJS 16.0.0 (first version supporting arm64 on mac)
as the Github Issues suggest NodeJS version 12 tried to build and run this on an x64 Intel Mac with NodeJS v12.13.0
tried to force x64 architecture leading to different error but because of incompatible library (x64) using a arm64 mac
all of it (except last mentioned) ended with the same result "missing symbol called"
help would be appreciated big.
Your question is an interesting take on a FAQ on this site: What is an undefined reference/unresolved external symbol error and how do I fix it?.
The role of SWIG is indeed to generate glue code between Node.js and C++ code. But it does only that. If you inspect the .dylib file that is associated with your NodeJS module using the nm command, you will see that it has Undefined references to the C++ functions it wraps.
This is by design. SWIG expects that the code it wraps is somehow already loaded into memory.
There are three approaches to do so:
Compile example.cpp directly into the SWIG wrapper. Or compile it to a static library first (example.a) and link that statically into the wrapper. I think it suffices to add example.cpp to the sources section of binding.gyp
Compile example.cpp into a library (example.dylib) and dynamically link it to the SWIG wrapper. I have not used GYP myself yet, but I think it means adding the following to your targets entry in bindings.gyp:
'link_settings': {
'libraries': [
'-lexample',
],
},
Compile example.cpp into a library (example.dylib) and use dlopen to load it explicitly. This puts a tremendous burden on your users and is very hard to debug. Do not do this.
SO wisdom, I'm turning to you. I'm trying to build a 64-bit static lib using LTO with Makefiles and Premake 5 on Ubuntu 16.04 LTS.
Here's the premake script i'm using:
-- premake5.lua
workspace "TestApp"
location "TestApp" -- The directory of generated files - .sln, etc.
configurations { "Debug", "Shipping" }
platforms { "Linux_Static", "Linux_DLL" }
targetdir "TestApp/Build/%{cfg.platform}/%{cfg.buildcfg}"
objdir "TestApp/Build/"
language "C++"
architecture "x86_64"
system "linux"
filter "platforms:*Static"
kind "StaticLib"
filter "platforms:*DLL"
kind "SharedLib"
filter "kind:SharedLib"
defines { "TEST_USE_DLL", "TEST_DLL_EXPORT" }
-- Configuration filters
configuration "*"
flags { "ExtraWarnings", "C++14", "MultiProcessorCompile", "ShadowedVariables", "UndefinedIdentifiers" }
configuration { "Debug" }
symbols "On"
defines { "TEST_DEBUG" }
optimize "Debug"
configuration "Shipping"
defines { "TEST_SHIPPING" }
optimize "Full"
flags { "LinkTimeOptimization" }
-- step 1
--buildoptions "--plugin=$$(gcc --print-file-name=liblto_plugin.so)"
-- step 2
--toolset "clang"
-- step 3
--premake.tools.gcc.ar = "gcc-ar"
-- Projects
project "TestCore"
location "TestApp/Core"
files { "TestApp/Core/*.h", "TestApp/Core/*.cpp" }
includedirs { "TestApp/" }
project "UnitTests"
location "TestApp/Tests"
kind "ConsoleApp"
links { "TestCore" }
objdir "TestApp/Tests/Build/"
files { "TestApp/Tests/UnitTests/*.cpp", "TestApp/ThirdParty/Catch/*" }
includedirs { "TestApp/ThirdParty/Catch", "TestApp/" }
removedefines { "TEST_DLL_EXPORT" }
filter { "platforms:*DLL", "system:linux" }
runpathdirs { "Build/%{cfg.platform}/%{cfg.buildcfg}" }
"Shipping" is the faulty configuration. I also bundled the whole test project in a zip for you to try to reproduce the issue.
The errors I have when compiling the TestCore library are first plugin needed to handle lto object, then plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so is not licensed under a GPL-compatible license.
What can we do about it ? If you have any knowledge to make it work with GCC, please help.
what you would do to reproduce the GCC errors after extracting the zip:
cd testBreaking
premake5 gmake
cd TestApp
make config=shipping_linux_static TestCore (get the "plugin needed to handle lto object" error)
Uncomment line 37 of premake5.lua to get the "not licensed under a GPL-compatible license" error
Uncomment line 43 to use gcc-ar instead of ar, notice it doesn't work either
Using gcc option -fuse-linker-plugin doesn't help
Some more system info:
ubuntu 16.04 LTS
gcc 5.4, make 4.1, ar 2.26.1
premake 5.0.0-alpha11
I got it working with Clang. Using toolset clang for Shipping configuration (using LLVM 3.9), the library seems to compile fine. But I got another error:
error adding symbols: Archive has no index; run ranlib to add one
I managed to work around this issue by calling ranlib Build/Linux_Static/Shipping/libTestCore.a --plugin /usr/lib/llvm-3.9/lib/LLVMgold.so, then make again.
So it painfully works using Clang.
I read that I could create a specific premake toolset for this kind of thing, because it's recommended replacing all gnu utils with their gcc- counterparts (e.g. gcc-ar instead of ar), but having rapidly tinkered with premake.tools.gcc.ar = "gcc-ar" with no result, I'm not so sure it would help.
I am currently trying to use Tensorflow's shared library in a non-bazel project, so I creat a .so file from tensorflow using bazel.
but when I launch a c++ program that uses both Opencv and Tensorflow, it makes me the following error :
[libprotobuf FATAL external/protobuf/src/google/protobuf/stubs/common.cc:78] This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.1.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-pkdHET/mir-0.21.0+16.04.20160330/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.1.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-pkdHET/mir-0.21.0+16.04.20160330/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
Abandon (core dumped)
Can you help me?
Thank you
You should rebuild TensorFlow with a linker script to avoid making third party symbols global in the shared library that Bazel creates. This is how the Android Java/JNI library for TensorFlow is able to coexist with the pre-installed protobuf library on the device (look at the build rules in tensorflow/contrib/android for a working example)
Here's a BUILD file that I adapted from the Android library to do this:
package(default_visibility = ["//visibility:public"])
licenses(["notice"]) # Apache 2.0
exports_files(["LICENSE"])
load(
"//tensorflow:tensorflow.bzl",
"tf_copts",
"if_android",
)
exports_files([
"version_script.lds",
])
# Build the native .so.
# bazel build //tensorflow/contrib/android_ndk:libtensorflow_cc_inference.so \
# --crosstool_top=//external:android/crosstool \
# --host_crosstool_top=#bazel_tools//tools/cpp:toolchain \
# --cpu=armeabi-v7a
LINKER_SCRIPT = "//tensorflow/contrib/android:version_script.lds"
cc_binary(
name = "libtensorflow_cc_inference.so",
srcs = [],
copts = tf_copts() + [
"-ffunction-sections",
"-fdata-sections",
],
linkopts = if_android([
"-landroid",
"-latomic",
"-ldl",
"-llog",
"-lm",
"-z defs",
"-s",
"-Wl,--gc-sections",
"-Wl,--version-script", # This line must be directly followed by LINKER_SCRIPT.
LINKER_SCRIPT,
]),
linkshared = 1,
linkstatic = 1,
tags = [
"manual",
"notap",
],
deps = [
"//tensorflow/core:android_tensorflow_lib",
LINKER_SCRIPT,
],
)
And the contents of version_script.lds:
{
global:
extern "C++" {
tensorflow::*;
};
local:
*;
};
This will make everything in the tensorflow namespace global and available through the library, while hiding the reset and preventing it from conflicting with protobuf.
(wasted a ton of time on this so I hope it helps!)
The error indicates that the program was complied using headers (.h files) from protobuf 2.6.1. These headers are typically found in /usr/include/google/protobuf or /usr/local/include/google/protobuf, though they could be in other places depending on your OS and how the program is being built. You need to update these headers to version 3.1.0 and recompile the program.
This is indeed a pretty serious problem! I get the below error similar to you:
$./ceres_single_test
[libprotobuf FATAL google/protobuf/stubs/common.cc:78] This program was compiled against version 2.6.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.1.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/build/mir-pkdHET/mir-0.21.0+16.04.20160330/obj-x86_64-linux-gnu/src/protobuf/mir_protobuf.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
Aborted
My workaround:
cd /usr/lib/x86_64-linux-gnu
sudo mkdir BACKUP
sudo mv libmirprotobuf.so* ./BACKUP/
Now, the executable under test works, cool. What is not cool, however, is that things like gedit no longer work without running from a shell that has the BACKUP path added to LD_LIBRARY_PATH :-(
Hopefully there's a better fix out there?
The error complains about the Protocol Buffer runtime library, which is not compatible with the installed version. This error is coming from the GTK3 library. GTK3 use Protocol Buffer 2.6.1. If you use GTK3 to support Opencv, you get this error. The easiest way to fix this, you can use QT instead of GTK3.
If you use Cmake GUI to install Opencv, just select QT support instead of using GTK3. You can install QT using the following command.
sudo apt install qtbase5-dev
rebuild libprotobuf with -Dprotobuf_BUILD_SHARED_LIBS=ON
then make install to cover the older version
I have a node.js module written in C++ that provides some bindings for a C++ library. The library crashes with SIGSEGV, so I need to debug it with GDB and find out what goes wrong.
I already have the source for the module in ./node_modules/somelib/ and if I go to that folder and type npm install the library is compiled and can be used through a require('somelib') from node.js. I can attach gdb to node and reproduce the error, but in the stacktrace I just see node_modules/somelib/Release/somelib.node.
I'm not sure if this is important but the library is compiled using node-gyp.
Question 1: How do I load the source code or point gdb to the source code?
Question 2: How do I configure node-gyp to produce debug symbols?
I just found the answer to this in the node-gyp documentation. The solution is to invoke the build process with the --debug flag. That means to invoke node-gyp configure --debug and/or node-gyp build --debug. Then instead of a Release folder a Debug folder will be created. gdb will then automatically load the source files.
Shamelessly copied from an archive of the (now broken) link provided by #Peter Cordes
First, compile your add-on using node-gyp with the --debug flag.
$ node-gyp --debug configure rebuild
Second, if you're still in "playground" mode like I am, you're probably loading your module with something like
var ObjModule = require('./ObjModule/build/Release/objModule');
However, when you rebuild using node-gyp in debug mode, node-gyp throws away the Release version and creates a Debug version instead. So update the module path:
var ObjModule = require('./ObjModule/build/Debug/objModule');
Alright, now we're ready to debug our C++ add-on. Run gdb against the node binary, which is a C++ application. Now, node itself doesn't know about your add-on, so when you try to set a breakpoint on your add-on function (in this case, StringReverse) it complains that the specific function is not defined. Fear not, your add-on is part of the "future shared library load" it refers to, and will be loaded once you require() your add-on in JavaScript.
$ gdb node
...
Reading symbols from node...done.
(gdb) break StringReverse
Function "StringReverse" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
OK, now we just have to run the application:
(gdb) run ../modTest.js
...
Breakpoint 1, StringReverse (args=...) at ../objModule.cpp:49
You can add the directory containing the source of the module to gdb's search path:
(gdb) directory /path/to/source
See: http://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html
Also, to get node-gyp debug symbols, install node-gyp-dbg/dev or equivalent, or compile it with -g
If you are a VSCode user, you may find this helpful inorder to debug your module.
Basic steps are:
Install the vscode plugin https://github.com/vadimcn/vscode-lldb
Setup your launch.json to look like this :
{
"version": "0.2.0",
"configurations": [{
"type": "lldb",
"request": "launch",
"name": "Launch Program",
"program": "/absolute/path/to/node",
"args": [
"/absolute/path/to/your/index.js"
]
}]
}
Then setup breakpoints as you would in VS Code.
Happy debugging!
I have also published a detailed blog here if you want more detailed explanation.
https://medium.com/#atulanand94/debugging-nodejs-c-addons-using-vs-code-27e9940fc3ad
Currently I can build my program using boost build in different platforms by setting the toolset and parameters in the command line. For example :
Linux
b2
MacOS
b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++"
Is there a way to create a rule in the Jamroot file to decide which compiler to use based on the operating system? I am looking for something along these lines:
import os ;
if [ os.on-macos ] {
using clang : <cxxflags>"-stdlib=libc++" <linkflags>"-stdlib=libc++c ;"
}
in linux it automatically decides to use gcc but in the mac if I don't specify the clang toolset it will try (without success) to compile it with gcc.
Just for reference, here is my current jamroot (any suggestions also appreciated):
# Project requirements (note, if running on a Mac you have to build foghorn with clang with libc++)
project myproject
: requirements <cxxflags>-std=c++11 <linkflags>-std=c++11 ;
# Build binaries in src
lib boost_program_options ;
exe app
: src/main.cpp src/utils src/tools boost_program_options
;
How abou using a Jamroot? I have the following in mine. It selects between two GCC versions on Linux, depending on what's in an environmen variable, and chooses vacpp on AIX.
if [ os.name ] = LINUX
{
switch [ modules.peek : ODSHOME ]
{
case *gcc-4* : using gcc : 4.4 : g++-4.4 ;
case *gcc-3.3* : using gcc : 3.3 : g++-3.3 ;
case * : error Only gcc v4 and gcc v3.3 supported. ;
}
}
else if [ os.name ] = AIX
{
using vacpp ;
}
else
{
error Only Linux and AIX supported at present. ;
}
After a long time I have found out that there is really no way (apart from very hacky) to do this. The goal of Boost.Build is to let the toolset option for the user to define.
The user has several ways to specify the toolset:
in the command line with --toolset=gcc for example
in the user configuration by setting it in the user-config.jam for all projects compiled by the user
in the site configuration by setting it in the site-config.jam for all users
the user-config.jam can be in the user's $HOME or in the boost build path.
the site-config.jam should be in the /etc directory, but could also be in the two locations above.
In summary, setup your site-config or user-config for a pleasant experience, and write a nice README file for users trying to compile your program.
Hope this helps someone else.