I have cross compiled gRPC (v1.27.3) for QNX 7 (ARM) platform. I am using the protobuf which was already available for our system (QNX ARM v3.11.4).
I used following cmake command to build gRPC for compilation process
cmake -DCMAKE_CROSSCOMPILING=1 -DgRPC_BUILD_TESTS=OFF -DgRPC_PROTOBUF_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DgRPC_ZLIB_PROVIDER=package -DOPENSSL_CRYPTO_LIBRARY=$QNX_TARGET/aarch64le/usr/lib/libcrypto.a -DOPENSSL_SSL_LIBRARY=$TARGET/aarch64le/usr/lib/libssl.a -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/tmp/qnxarm/toolchain.cmake -DCMAKE_INSTALL_PREFIX=/tmp/qnxarm/inst ../..
make plugins
make -j4
sudo make install
After compiling, I am able to see the binaries in /tmp/qnxarm/inst folder.
I copied those binaries in our code to compile the application for QNX.
While compiling I am getting this issue:
<local_directory>/grpc/aarch64/qnx/bin/grpc_cpp_plugin: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
lib/qmonitor/proto/CMakeFiles/QMonitorProto.dir/build.make:105: recipe for target 'lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc' failed
make[2]: *** [lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc] Error 1
Please help me to know what is wrong? or what should be done to solve this.
Do we need to add the PATH in gRPCTargets.cmake file which is generated in lib folder?
You've compiled the gRPC tools for your QNX ARM system -- so the version of grpc_cpp_plugin you made is expecting to be run on your QNX system, not your build host.
The usual approach for this sort of thing is to make a second copy of gRPC compiled for your build host, and then instruct your application build to link the libraries from the cross build, but call the grpc_cpp_plugin compiled for the build host.
Related
If want to run dotnet-trace on Linux, against an application that ships with its own .NET Core runtime. When I run it, however, I get:
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/user/.net/dotnet-trace/RMBGJOBRwpkX5Kvpq_FShF5s1UmJMO8=/].
If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].
I located the libhostfxr.so library at /home/user/app/libhostfxr.so, then executed DOTNET_ROOT=/home/user/app/ dotnet-trace, but got the same error.
How do I go from the path of this library to the correct setting for DOTNET_ROOT?
According to strace, it is looking for the file /home/user/app/host/fxr which does not exist.
I ended up installing the .NET version that matched the application I was trying to debug using the install script. (I found this by using strings libhostfxr.so; perhaps there's a better way.)
A little confusingly, the runtime version 3.1.28 is not the same as the corresponding SDK version 3.1.422, which I installed with:
$ wget -O - https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --version 3.1.422
It can also be downloaded from versionsof.net which is not an official site, but it links to the files hosted by Microsoft.
This process installed /home/user/.dotnet/host/fxr/3.1.28/libhostfxr.so and I could then run DOTNET_ROOT=/home/user/.dotnet/ dotnet-trace.
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I'm trying to build our application using Qt 5.13.0 installed via Conan/Artifactory. We run our own Artifactory server and the Qt version there is self-build (and statically linked) in our CI solution. We use the Conan recipe for Qt written by the bincrafters, slightly modified to apply some patches for known Qt bugs and set some flags for building properly on Android and WebAssembly.
When trying to build the application, the linker fails to find the necessary dependencies for Qt itself because it tries to look them up in the home folder of the user who build the Qt package, not the user who's running the build.
Here's an excerpt from the build log, showing the attempt at linking all previously compiled object files together:
application folder-------v subproject of the application----v-------v dependency of the application, correct user home dir---------v Qt library installed via Conan, correct user home dir-------v dependency of Qt, WRONG user home dir------------v
g++ -Wl,--gc-sections -o ../../fah [--> all the .o files <--] -L../lib -lmodel -lcore [--> more linked libraries and application parts <--] -L/home/kaupes/.conan/data/libsodium/1.0.18/bje/stable/package/d1efe3774eed76670888f919621e7c4e1b52efa9/lib /home/kaupes/.conan/data/qt/5.13.0/bje/stable/package/d6b3f512e1a5607061462f94e3271dc8af3dd516/lib/libQt5Gui.a /home/dev/.conan/data/harfbuzz/2.4.0/bje/stable/package/c68551ae35bf5d62e66263379d58a38416eb84a9/lib/libharfbuzz.a [--> many, many more libraries <--]
g++: error: /home/dev/.conan/data/harfbuzz/2.4.0/bje/stable/package/c68551ae35bf5d62e66263379d58a38416eb84a9/lib/libharfbuzz.a: No such file or directory
many, many more errors...
As you can see, the user running the build is kaupes, but the g++ invocation attempts to look for the dependencies in /home/dev/, the home folder of the CI user who build the Qt Conan package.
Only dependencies of Qt itself have the problem. Dependencies of the application (also installed via Conan) are found at the correct place.
The Qt package has been build in the CI using the following Conan invocation:
conan create --profile .conan/profiles/linux -s compiler=gcc -s compiler.version=9 . fah/stable
Compiler and version are explicitly set because I'm also build for another GCC version. The linux profile file also doesn't do anything interesting (as far as I can see):
include(default)
[settings]
build_type=Release
compiler.libcxx=libstdc++11
[options]
OpenSSL:shared=False
OpenSSL:no_asm=True
OpenSSL:no_asm=True
OpenSSL:no_weak_ssl_ciphers=True
OpenSSL:no_ssl2=True
OpenSSL:no_ssl3=True
OpenSSL:no_engine=True
libcurl:shared=False
libxml2:shared=False
libxml2:fPIC=True
libsodium:shared=False
pcre2:shared=False
libpng:shared=False
freetype:shared=False
bzip2:shared=False
libjpeg:shared=False
harfbuzz:shared=False
xkbcommon:shared=False
qt:shared=False
qt:with_glib=False
qt:with_sqlite3=False
qt:with_mysql=False
qt:with_pq=False
qt:with_odbc=False
qt:with_sdl2=False
qt:with_openal=False
qt:with_libalsa=False
qt:openssl=True
qt:commercial=False
qt:qtsvg=True
qt:qtdeclarative=True
qt:qtactiveqt=False
qt:qtscript=False
qt:qtmultimedia=False
qt:qttools=True
qt:qtxmlpatterns=False
qt:qttranslations=True
qt:qtdoc=False
qt:qtrepotools=False
qt:qtqa=False
qt:qtlocation=True
qt:qtsensors=True
qt:qtwayland=True
qt:qt3d=False
qt:qtimageformats=False
qt:qtgraphicaleffects=True
qt:qtquickcontrols=True
qt:qtserialbus=False
qt:qtserialport=False
qt:qtx11extras=True
qt:qtmacextras=False
qt:qtwinextras=False
qt:qtandroidextras=False
qt:qtwebsockets=True
qt:qtwebchannel=False
qt:qtwebengine=False
qt:qtwebview=False
qt:qtquickcontrols2=True
qt:qtpurchasing=False
qt:qtcharts=True
qt:qtdatavis3d=False
qt:qtvirtualkeyboard=True
qt:qtgamepad=False
qt:qtscxml=False
qt:qtspeech=False
qt:qtnetworkauth=False
qt:qtremoteobjects=False
qt:qtwebglplugin=False
qt:qtlottie=False
qt:qtconnectivity=True
Is there something I'm doing wrong during the Conan package creation or installation or is this caused by something different?
Indeed, when building qt, all paths to dependencies are hardcoded in configurations files (mkspecs\modules\qt_lib_*.pri).
I assume you are building your application with qmake, because you use static qt, and static qt is incompatible with cmake. One thing you could try is to pass the full path to harfbuzz lib to qmake by adding argument QMAKE_LIBS_HARFBUZZ=/home/kaupes/.conan/data/harfbuzz/2.4.0/bje/stable/package/c68551ae35bf5d62e66263379d58a38416eb84a9/lib/libharfbuzz.a to your qmake invocation.
Edit: it seems to be a knwonw behaviour of qt >= 5.12.1 : https://bugreports.qt.io/browse/QTBUG-72903. This feature has been reverted in 5.14.x and 5.15.x with https://github.com/qt/qtbase/commit/9864d2c6f3b628ca9f07a56b197e77bd43931cca
I write a code in qt creator under Ubuntu (vmware one). the code compiled and run on my computer correctly. But when I try to compile the code on university supercomputer it give the following error:
./Test02_Qt: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
It should be added that I tried to compile my code on the supercomputer using make command and I got the following error :
error while loading shared libraries: libstdc++.so.6: cannot open shared object file; no such file or directory
make: *** [Makefile] Error 127
please help me on this issue.
Regards
You should compile your software on the target machine to ensure that all libraries match. Compiling against library version A on computer 1 and then running against version B on computer 2 might outright fail or have side-effects.
Have a look at this:
error while loading shared libraries: libstdc++.so.6
This is a common error if operating system versions do not match (most probably, the supercomputer has an older version of libstdc++ installed).
To understand why your compilation on the target machine does not work, we need more information on your build setup. Are you using a plain Makefile? Autotools? QMake? CMake? Normally your build system should not dictate a specific version of libstdc++ and it might be you have to re-initialize it or edit the Makefile.
I'm trying to build a static application on Ubuntu (if it matters, Ubuntu running in a virtual machine in Windows), following the Qt documentation. Accordingly, I have build the libraries from source, using the configuration from the documentation:
./configure -static -prefix /path/to/Qt
There were no error messages from the build from source. I have tried setting the PATH variable in the build environment to the directory that contains my static build files. I've also tried specifying this path in the .pro file's LIBPATH variable. Nevertheless, whenever I build the application, a call to ldd shows that there are still dependencies to the Qt's dynamic libraries. I'm at a loss to understand how I need to configure Qt Creator to fix this.
You should download sources of interested Qt version, configure for static build and compile them yourself.