I used the ldd command to print out the binary build through bazel and the result is as follows.
libexternal_Scom_Ugoogle_Uprotobuf_Slibprotobuf.so => /apollo/bazel-bin/cyber/../_solib_k8/libexternal_Scom_Ugoogle_Uprotobuf_Slibprotobuf.so (0x00007f5900b1c000)
libexternal_Scom_Ugoogle_Uprotobuf_Slibprotobuf_Ulite.so => /apollo/bazel-bin/cyber/../_solib_k8/libexternal_Scom_Ugoogle_Uprotobuf_Slibprotobuf_Ulite.so (0x00007f59009f7000)
libexternal_Szlib_Slibzlib.so => /apollo/bazel-bin/cyber/../_solib_k8/libexternal_Szlib_Slibzlib.so (0x00007f59009d8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f59007d0000)
libPocoFoundation.so.71 => /opt/apollo/sysroot/lib/libPocoFoundation.so.71 (0x00007f59003a5000)
libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f590019d000)
My question is I found LD_LIBRARY_PATH path not have
/apollo/bazel-bin/cyber/../_solib_k8/
So how is this path added to find the dynamic library?
I finally found out that bazel doesn't change LD_LIBRARY_PATH, but if you want to add use it, it works too.
bazel writes the path to binary, which implements this function by calling gcc -rpath, so that the dynamic library will be searched from rpath when linking. https://en.wikipedia.org/wiki/Rpath
Related
I have been facing linking issues when including various ROS packages and Drake as libraries, and have narrowed the issue down to VTK.
It seems that ROS(noetic) PCL depends on VTK 7.1.0 whereas Drake depends on VTK 9.1.0 after running ldd:
linux-vdso.so.1 (0x00007fffa88ea000)
libdrake.so => /opt/drake/lib/libdrake.so (0x00007f644589d000)
libpcl_io.so.1.10 => /lib/x86_64-linux-gnu/libpcl_io.so.1.10 (0x00007f64455d7000)
libvtkCommonCore-7.1.so.7.1p => /lib/x86_64-linux-gnu/libvtkCommonCore-7.1.so.7.1p (0x00007f644528b000)
libvtkFiltersGeneral-7.1.so.7.1p => /lib/x86_64-linux-gnu/libvtkFiltersGeneral-7.1.so.7.1p (0x00007f6444f41000)
libvtkRenderingCore-7.1.so.7.1p => /lib/x86_64-linux-gnu/libvtkRenderingCore-7.1.so.7.1p (0x00007f6444c30000)
libvtkRenderingOpenGL2-7.1.so.7.1p => /lib/x86_64-linux-gnu/libvtkRenderingOpenGL2-7.1.so.7.1p (0x00007f6444907000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6444725000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6444533000)
libdrake_lcm.so => /opt/drake/lib/libdrake_lcm.so (0x00007f644451a000)
libdrake_marker.so => /opt/drake/lib/libdrake_marker.so (0x00007f6444517000)
libvtksys-9.1.so.1 => /opt/drake/lib/libvtksys-9.1.so.1 (0x00007f64444c2000)
libvtkfmt-9.1.so.1 => /opt/drake/lib/libvtkfmt-9.1.so.1 (0x00007f644449b000)
libvtkkissfft-9.1.so.1 => /opt/drake/lib/libvtkkissfft-9.1.so.1 (0x00007f6444493000)
libvtkloguru-9.1.so.1 => /opt/drake/lib/libvtkloguru-9.1.so.1 (0x00007f6444459000)
...
My CMakeLists.txt is defined as:
cmake_minimum_required(VERSION 3.10)
project(my_project)
find_package(catkin REQUIRED COMPONENTS
roscpp
pcl_ros
)
find_package(drake CONFIG REQUIRED PATHS /opt/drake)
catkin_package(
CATKIN_DEPENDS roscpp pcl_ros
DEPENDS drake
)
include_directories(${catkin_INCLUDE_DIRS})
add_executable(my_test test.cpp)
target_link_libraries(my_test drake::drake ${catkin_LIBRARIES})
and package.xml as
....
<buildtool_depend>catkin</buildtool_depend>
<depend>roscpp</depend>
<depend>pcl_ros</depend>
</package>
Simply including vtk headers causes immediate an segmentation fault:
#include "drake/systems/framework/diagram_builder.h"
#include <vtkPolyData.h>
int main() {
drake::systems::DiagramBuilder<double> builder;
return 0;
}
That's correct -- VTK's library symbols are not version-namespaced, so you cannot load two different VTK versions into the same process, even for two completely independent uses. This is not unique to Drake; it's generally true about VTK.
The only challenge with Drake is that (1) Drake's pre-compiled binaries are built against a specific version of VTK that differs from ROS PCL's VTK, and (2) even for a Drake source build, Drake doesn't make it very easy to change which version of VTK will be linked. Unlike Eigen or spdlog or fmt, Drake's VTK dependency is not designed to be end-user-serviceable.
To avoid problems like this, Drake is actively working on linking VTK privately. Follow #16502 for updates. ETA for the fix should be within the next month or two.
In the meantime, there are not many good work-arounds.
The only easy one is to carefully link to only the parts of PCL that do not depend on VTK. For example, the PCL KDTree does not use VTK (should be safe), but the PCL IO does use VTK (will segfault). If your problem is only over-linking, then fixing your build to link fewer unnecessary things might resolve it.
The other work-around is to put a process boundary between your Drake-using code and PCL-with-VTK-using-code, with some kind of a message channel inbetween. That is, rework your code to only ever load Drake in some programs, and PCL in others, and never the two shall meet.
Hopefully, the Drake feature 16502 will be resolved soon, making this all moot.
As of tonight's nightly build (20221117 or greater) or the next stable release (v1.11.0 or newer), Drake will use Ubuntu's build of VTK 9.1 when running on Ubuntu 22.04 (aka "Jammy"). In case you can run a version of ROS on Ubuntu 22.04, hopefully it would use a compatible VTK 9.1 and PCL would work.
In Bazel 4.2.2 I could do a "go-to-reference" on a source file to get the path of the corresponding BUILD file, along with the line and column numbers pointing to where the source file is referenced:
bazel query ./main.cpp --output=location
~/project/package/BUILD:124:8: source file //package:main.cpp
In Bazel 5.1.1 this command returns the path of the very same source file:
bazel query ./main.cpp --output=location
~/project/package/main.cpp:1:1: source file //package:main.cpp
How to get the old behavior back?
P.S. This ticket requests the new behavior.
Solution is to use --noincompatible_display_source_file_location:
bazel query ./main.cpp --output=location --noincompatible_display_source_file_location
~/project/package/BUILD:124:8: source file //package:main.cpp
Use case: I have a dependency that falls back to a subproject:
./
./subprojects/
./subprojects/mylib.wrap
src/meson.build contains:
mylib_dep = dependency('mylib') # Searches for mylib with pkg-config then fall backs to mylib.wrap.
myexec_exe = executable ('myexec', 'myexec.c', dependencies : mylib_dep)
Dependency mylib_dep provides libraries, which, if not installed on the system, make the main executable of my project unusable:
$ meson build && cd build && meson compile src/my_exec
...snip'd...
$ src/my_exec
src/my_exec: error while loading shared libraries: libmylib.so: cannot open shared object file: No such file or directory
My testing script build/tests/mytests.sh is configure_filed from tests/mytests.sh.in to indicate the location of myexec, and I'd like to pass to it the library paths, so that it can adjust LD_LIBRARY_PATH and run the executable. For instance, in tests/meson.build:
conf_data = configuration_data ()
conf_data.set_quoted ('MYEXEC_PATH', myexec_exe.full_path ())
conf_data.set_quoted ('MYLIB_PATH', mylib_dep.??????)
mytest_exe = configure_file (input : 'mytests.sh.in', output : 'mytests.sh', configuration : conf_data)
and in tests/mytests.sh.in:
MYEXEC_PATH=#MYEXEC_PATH#
MYLIB_PATH=#MYLIB_PATH#
export LD_LIBRARY_PATH=$(dirname "$MYLIB_PATH"):$LD_LIBRARY_PATH
$MYEXEC_PATH
Question: What should go at the ?????? above? In other words, given a dependency object, how can I extract the libraries within it, and get their full paths?
Usually in meson you wouldn't configure_file this, you'd pass the library/executable(s) to the script as arguments in the test command:
test(
'mytest',
find_program('mytest.sh')
args : [executable_target, library_target, ...],
)
It can be frustrating trying to get this sort of info out of Meson. Fortunately, if Meson used CMake to find the dependency, you may be able to get the library path from the underlying CMake variables, which are available in the Meson dependency object. Eg, something along the following lines worked for me:
mylib_dep = dependency('mylib')
if mylib_dep.found()
mylib_path = mylib_dep.get_variable(default_value : '', cmake : 'PACKAGE_LIBRARIES')
message('Library path is:', mylib_path)
endif
I am trying to find the boost libraries (cmake) inside the Yocto SDK with extended environment on krogoth.
The default cmake Find_
find_package(Boost REQUIRED)
The standard error message
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:3 (find_package)
The following is a snippet from my conf/local.conf
IMAGE_INSTALL_append = " boost-dev"
IMAGE_INSTALL_append = " boost"
IMAGE_INSTALL_append = " kernel-devsrc"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-hello"
KERNEL_MODULE_AUTO_lOAD += "hello-md"
LCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
SDK_EXTRA_TOOLS = " nativesdk-cmake
I am using the native cmake
auke#xenialxerus:~/workspace/beaglebone-dev/build$ which cmake
/home/auke/workspace/beaglebone-dev/poky-sdk/tmp/sysroots/x86_64-linux/usr/bin/
since I:
source environment-setup-cortexa8hf-neon-poky-linux-gnueabi
looking for the usual headers in:
find ./tmp/sysroots/beaglebone/usr/include/boost/
..
/tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_seq.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_tuple.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/to_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/empty.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/size.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/get_type.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/assert_is_identifier.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_number.hpp
..
just like the binaries:
./tmp/sysroots/beaglebone/usr/lib/libboost_system-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so.1.60.0
./tmp/sysroots/beaglebone/usr/lib/libboost_serialization-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time.a
./tmp/sysroots/beaglebone/usr/lib/libboost_thread.so
./tmp/sysroots/beaglebone/usr/lib/libboost_signals-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.so
./tmp/sysroots/beaglebone/usr/lib/libboost_graph-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so
./tmp/sysroots/beaglebone/usr/lib/libboost_regex.so
./tmp/sysroots/beaglebone/usr/lib/libboost_wserialization.so.1
Is there something that i might have overlooked?
regards Auke
You should use
bitbake -c populate_sdk <image_name> to generate the SDK based on your image;
As an alternative to locating and downloading a toolchain installer,
you can build the toolchain installer one of two ways if you have a
Build Directory:
*Use bitbake meta-toolchain. This method requires you to still install
the target sysroot by installing and extracting it separately. For
information on how to install the sysroot, see the "Extracting the
Root Filesystem" section.
*Use bitbake -c populate_sdk. This method has significant
advantages over the previous method because it results in a toolchain
installer that contains the sysroot that matches your target root
filesystem.
Also, using the variable TOOLCHAIN_HOST_TASK to add more packages.
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html
This variable lists packages the OpenEmbedded build system uses when
building an SDK, which contains a cross-development environment. The
packages specified by this variable are part of the toolchain set that
runs on the SDKMACHINE, and each package should usually have the
prefix "nativesdk-". When building an SDK using bitbake -c
populate_sdk , a default list of packages is set in this
variable, but you can add additional packages to the list.
e.g.
TOOLCHAIN_HOST_TASK += “nativesdk-libqt5core-dev”
I downloaded the source of LuaJIT and compiled it with msvc120.dll (VS 2013 x64). When I run it from the command line I have no problems executing some basic lua. Now the LuaJIT installation guide mentions moving luajit.exe and lua51.dll into their own folder. From there it says to create a lua folder and under that a jit folder with the contents of src/jit moved underneath the newly created jit folder.
From my understanding my folder should look like and contain:
luajit.exe
lua51.dll
/lua
/jit
bc.lua
[rest of jit files]
vmdef.lua
Is this correct or am I missing files?
Now after I built my luajit I tried to wire it up into my luarocks to act as my interpreter using
install.bat /LUA C:\LuaJIT\2.0.3\[folder with above content]
However this cannot find the header files. I then copied over what are the header files into the folder above and that wires it up, but I can never actually get anything to compile when pointed over to LuaJIT. Edit: The error I get is the following,
C:\LuaJIT\2.0.3\bin\lua51.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D0
Error: Failed installing dependency: https://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock - Build error: Failed compiling module lfs.dll
Is the correct way to handle this to simply point to my lua binaries and from there leverage LuaJIT to run my files or am I doing something wrong with wiring up LuaJIT and luarocks? The former seems to work for the most part, since I only ran into one library compilation issue, lua-cjson.
I've run on exactly the same problem, but they've found a solution right here:
https://github.com/keplerproject/luafilesystem/issues/22
I knew that for "linking DLLs statically" there is a so-called "export" .lib file, which is passed to the linker (and not the DLL itself).
So, for example, when compiling, LuaRocks was doing this:
cl /nologo /MD /O2 -c -Fosrc/mime.obj -ID:/LuaJIT-2.0.4/include/ src/mime.c -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG -DNDEBUG -DLUASOCKET_API=__declspec(dllexport) -DMIME_API=__declspec(dllexport) mime.c
link -dll -def:core.def -out:mime/core.dll D:/LuaJIT-2.0.4/bin/lua51.dll src/mime.obj
My LuaJIT was compiled from source in D:\LuaJIT-2.0.4\src, but I made two folders myself: D:\LuaJIT-2.0.4\include with all *.h files copied from src and D:\LuaJIT-2.0.4\bin with luajit.exe, lua51.dll, and then later lua51.exp and lua51.lib. Still same error, but this was the right track.
Fix
Now, check where your LuaRocks configs are:
luarocks.bat help
Scroll down to a section like:
CONFIGURATION
Lua version: 5.1
Configuration files:
System: D:/luarocks/config-5.1.lua (ok)
User : (... snip ...)
Edit the System configuration file, specifically see the part:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.dll'
}
Here! LUALIB should be the .lib file. If your export lib is alongside the DLL, you just need to change to:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.lib' -- here!
}
Verification
And now:
luarocks.bat install luasocket
(...)
link -dll -def:core.def -out:socket/core.dll D:/LuaJIT-2.0.4/bin/lua51.lib src/luasocket.obj (...)
(...)
luasocket 3.0rc1-2 is now built and installed in D:\luarocks\systree (license: MIT)
Note the first argument passed to the linker.