I am new to bazel.
I tried the tutorial below
https://docs.bazel.build/versions/master/tutorial/cpp.html#use-multiple-packages
And to create a shared library, I added 'linkstatic = False' in cc_binary,
So BUILD file is
load("#rules_cc//cc:defs.bzl", "cc_binary", "cc_library")
cc_library(
name = "hello-greet",
srcs = ["hello-greet.cc"],
hdrs = ["hello-greet.h"],
)
cc_binary(
name = "hello-world",
srcs = ["hello-world.cc"],
deps = [
":hello-greet",
"//lib:hello-time"
],
linkstatic = False,
)
and after build, I confirmed that 'libhello-greet.so' was created under the bazel-bin directory.
However, if I check the hello-world executable with ldd, it is as follows.
$ ldd hello-world
~snip~
libmain_Slibhello-greet.so => /home/foo/.cache/bazel/_bazel_wrs/8e7a6d8989ff6d697373ddbabde23fa3/execroot/__main__/bazel-out/k8-fastbuild/bin/main/./../_solib_k8/libmain_Slibhello-greet 0x00007f2706f84000)
liblib_Slibhello-time.so => /home/foo/.cache/bazel/_bazel_wrs/8e7a6d8989ff6d697373ddbabde23fa3/execroot/__main__/bazel-out/k8-fastbuild/bin/main/./../_solib_k8/liblib_Slibhello-time.so 0x00007f2706f81000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2706462000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2706071000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2706da1000)
Why hello-world linking the library(libmain_Slibhello-greet.s) in the cache directory instead of linking the locally generated libhello-greet.so?
How do I change it link to libhello-greet.so?
i think that the locally created directories are all Symlinks to the output directory ~/.chache/bazel as you can check with
fed#fed-VirtualBox:~/cpp-tutorial/stage2/bazel-bin/main$ readlink -f libhello-greet.so
/home/.cache/bazel/_bazel_fed/d6678e06051dff35967a6c61fe201847/execroot/__main__/bazel-out/k8-fastbuild/bin/main/libhello-greet.so
You can find out more on the bazel output layout here https://docs.bazel.build/versions/master/output_directories.html .
However, an alternative to have your final executable linked to a shared object under a certain path is to set your environment variable
fed#fed-VirtualBox: LD_LIBRARY_PATH="/home/cpp-tutorial/stage2/main/lib/"
fed#fed-VirtualBox: export LD_LIBRARY_PATH
and then directly import the library in your BUILD file
cc_import(
name = "hello-greet",
hdrs = ["hello-greet.h"],
shared_library = "lib/libhello-greet.so",
)
cc_binary(
name = "hello-world",
srcs = ["hello-world.cc"],
deps = [
":hello-greet",
],
linkstatic = False,
)
and then your final executable will be linked to the .so under your path
fed#fed-VirtualBox:~/examples/cpp-tutorial/stage2$ ldd bazel-bin/main/hello-world
linux-vdso.so.1 (0x00007ffe72df2000)
libhello-greet.so => /home/cpp-tutorial/stage2/main/lib/libhello-greet.so (0x00007f3bba04d000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3bb9e5a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3bb9d0b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3bb9cf0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3bb9afe000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3bba057000)
bazel will do name mangling for shared libraries. you can use below workaround to static the shared library's name.
# build a shared library
cc_binary(
name = "libhello-greet.so",
srcs = [
"hello-greet.h",
"hello-greet.cc",
],
linkshared = True,
)
# input the library
cc_import(
name = "hello-greet",
shared_library = "libhello-greet.so",
hdrs = ["hello-greet.h"],
)
cc_binary(
name = "hello-world",
srcs = ["hello-world.cc"],
deps = [
":hello-greet",
"//lib:hello-time",
],
)
ldd results are as follows. You can see that the name has not changed.
linux-vdso.so.1 (0x00007fff53195000)
libhello-greet.so => /home/zero/01opencode/examples/cpp-tutorial/stage3/bazel-bin/main/../_solib_k8/_U_S_Smain_Chello-greet___Umain/libhello-greet.so (0x00007f2ca7050000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ca6aa8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2ca670a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2ca64f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ca6101000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ca6e31000)
Related
The current error I`m having is:
I build on android studio and no problem so far
Run pod install and everything checks out
I press build on XCode and this is the error I find.
Task :shared_core:linkPodDebugFrameworkIos FAILED
e: Could not find "/Users/xxxx/android/shared_core/build/classes/kotlin/ios/main/klib/shared_core.klib" in [/Users/xxxx/ios/Pods, /Users/mac/.konan/klib, /Users/mac/.konan/kotlin-native-prebuilt-macos-x86_64-1.6.10/klib/common, /Users/mac/.konan/kotlin-native-prebuilt-macos-x86_64-1.6.10/klib/platform/ios_x64]
It happens both with multiplatform 1.5.31 and 1.6.10.
Obs:
The file is there.
Both Xcode, Android Studio and Terminal and Cocoapods have Full Disk access.
Obs2: My Folder structure is
- root folder
- android folder
- ios folder
Obs3: My podspec file:
Pod::Spec.new do |spec|
spec.name = 'shared_core'
spec.version = '1.0'
spec.homepage = 'Link to the Shared Module homepage'
spec.source = { :git => "Not Published", :tag => "Cocoapods/#{spec.name}/#{spec.version}" }
spec.authors = ''
spec.license = ''
spec.summary = 'Some description for the Shared Module'
spec.vendored_frameworks = "build/cocoapods/framework/shared_core.framework"
spec.libraries = "c++"
spec.module_name = "#{spec.name}_umbrella"
spec.ios.deployment_target = '11'
spec.pod_target_xcconfig = {
'KOTLIN_PROJECT_PATH' => ':shared_core',
'PRODUCT_MODULE_NAME' => 'shared_core',
}
spec.script_phases = [
{
:name => 'Build shared_core',
:execution_position => :before_compile,
:shell_path => '/bin/sh',
:script => <<-SCRIPT
if [ "YES" = "$COCOAPODS_SKIP_KOTLIN_BUILD" ]; then
echo "Skipping Gradle build task invocation due to COCOAPODS_SKIP_KOTLIN_BUILD environment variable set to \"YES\""
exit 0
fi
set -ev
REPO_ROOT="$PODS_TARGET_SRCROOT"
"$REPO_ROOT/../gradlew" -p "$REPO_ROOT" $KOTLIN_PROJECT_PATH:syncFramework \
-Pkotlin.native.cocoapods.platform=$PLATFORM_NAME \
-Pkotlin.native.cocoapods.archs="$ARCHS" \
-Pkotlin.native.cocoapods.configuration=$CONFIGURATION \
-Pkotlin.native.cocoapods.cflags="$OTHER_CFLAGS" \
-Pkotlin.native.cocoapods.paths.headers="$HEADER_SEARCH_PATHS" \
-Pkotlin.native.cocoapods.paths.frameworks="$FRAMEWORK_SEARCH_PATHS"
SCRIPT
}
]
end
And here's my PodFile:
target 'MyTarget' do
# Comment the next line if you don't want to use dynamic frameworks
use_frameworks!
pod 'shared_core', :path => '../android/shared_core'
end
post_install do |installer|
installer.pods_project.build_configurations.each do |config|
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
end
end
I really have no idea what's going one, this project built before, and nothing changed, and now it's not finishing the build.
I have 2 opencv installation (in separate location). One is installed with apt-get (version 2.4). While another is version 3.0 installed from source code.
I notice that my catkin_make (cmake) links both opencv2.4 and opencv3.0
[ri-desktop2 robotic_vision]$ ldd devel/lib/visensor_dgem/dgem
linux-vdso.so.1 => (0x00007ffd30f5e000)
libcv_bridge.so => /opt/ros/jade/lib/libcv_bridge.so (0x00007f7eb7fa8000)
libopencv_highgui.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 (0x00007f7eb7d5d000)
libopencv_core.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4 (0x00007f7eb7926000)
libroscpp.so => /opt/ros/jade/lib/libroscpp.so (0x00007f7eb75d3000)
libroscpp_serialization.so => /opt/ros/jade/lib/libroscpp_serialization.so (0x00007f7eb73d0000)
librosconsole.so => /opt/ros/jade/lib/librosconsole.so (0x00007f7eb71a7000)
librostime.so => /opt/ros/jade/lib/librostime.so (0x00007f7eb6f7d000)
libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f7eb6d79000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7eb6b5b000)
libopencv_core.so.3.0 => /usr/local/lib/libopencv_core.so.3.0 (0x00007f7eb5b1b000)
libopencv_highgui.so.3.0 => /usr/local/lib/libopencv_highgui.so.3.0 (0x00007f7eb58dd000)
libopencv_imgproc.so.3.0 => /usr/local/lib/libopencv_imgproc.so.3.0 (0x00007f7eb4941000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7eb463d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7eb4427000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7eb4062000)
libopencv_imgproc.so.2.4 => /usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.2.4 (0x00007f7eb3bd2000)
libGL.so.1 => /usr/lib/nvidia-352/libGL.so.1 (0x00007f7eb38a2000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f7eb364d000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f7eb3427000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f7eb31b5000)
libjasper.so.1 => /usr/lib/x86_64-linux-gnu/libjasper.so.1 (0x00007f7eb2f5e000)
libIlmImf.so.6 => /usr/lib/x86_64-linux-gnu/libIlmImf.so.6 (0x00007f7eb2caf000)
libHalf.so.6 => /usr/lib/x86_64-linux-gnu/libHalf.so.6 (0x00007f7eb2a6c000)
libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f7eb242f000)
libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f7eb217c000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f7eb1f2b000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f7eb1c23000)
libgtkglext-x11-1.0.so.0 => /usr/lib/libgtkglext-x11-1.0.so.0 (0x00007f7eb1a1f000)
libgdkglext-x11-1.0.so.0 => /usr/lib/libgdkglext-x11-1.0.so.0 (0x00007f7eb17bb000)
libdc1394.so.22 => /usr/lib/x86_64-linux-gnu/libdc1394.so.22 (0x00007f7eb1547000)
libv4l1.so.0 => /usr/lib/x86_64-linux-gnu/libv4l1.so.0 (0x00007f7eb1341000)
libavcodec.so.54 => /usr/lib/x86_64-linux-gnu/libavcodec.so.54 (0x00007f7eb05ed000)
libavformat.so.54 => /usr/lib/x86_64-linux-gnu/libavformat.so.54 (0x00007f7eb02cb000)
libavutil.so.52 => /usr/lib/x86_64-linux-gnu/libavutil.so.52 (0x00007f7eb00a6000)
libswscale.so.2 => /usr/lib/x86_64-linux-gnu/libswscale.so.2 (0x00007f7eafe5f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7eafb59000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7eaf940000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7eaf738000)
libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007f7eaf504000)
libxmlrpcpp.so => /opt/ros/jade/lib/libxmlrpcpp.so (0x00007f7eaf2e6000)
libcpp_common.so => /opt/ros/jade/lib/libcpp_common.so (0x00007f7eaf0de000)
libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f7eaeec8000)
libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f7eaecb2000)
librosconsole_log4cxx.so => /opt/ros/jade/lib/librosconsole_log4cxx.so (0x00007f7eaea9e000)
librosconsole_backend_interface.so => /opt/ros/jade/lib/librosconsole_backend_interface.so (0x00007f7eae89c000)
My CMakeLists.txt
cmake_minimum_required(VERSION 2.8.3)
project(visensor_node)
find_package(catkin REQUIRED COMPONENTS
roscpp
message_generation
geometry_msgs
sensor_msgs
cv_bridge
std_msgs
image_transport
camera_info_manager
dynamic_reconfigure
cmake_modules
)
# check libvisensor version, flags not used later
find_package(libvisensor 1.1.0 REQUIRED)
add_message_files(
DIRECTORY msg
FILES visensor_imu.msg
visensor_time_host.msg
visensor_calibration.msg
)
add_service_files(
FILES
visensor_calibration_service.srv
)
generate_messages(DEPENDENCIES geometry_msgs)
include_directories(include ${catkin_INCLUDE_DIRS} ${libvisensor_INCLUDE_DIRS})
find_package(Eigen3 REQUIRED)
include_directories(${EIGEN_INCLUDE_DIR})
add_definitions(${EIGEN_DEFINITIONS})
find_package(OpenCV 3.0 REQUIRED COMPONENTS core highgui imgproc)
generate_dynamic_reconfigure_options(cfg/visensor_node.cfg)
if(NOT DEFINED CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE Release)
endif(NOT DEFINED CMAKE_BUILD_TYPE)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native -Wall -std=c++0x -D__STRICT_ANSI__")
catkin_package(
INCLUDE_DIRS include ${catkin_INCLUDE_DIRS}
CATKIN_DEPENDS
roscpp
sensor_msgs
cv_bridge
std_msgs
image_transport
camera_info_manager
)
#build and add libvisensor system library dependency
add_executable(visensor_node src/visensor_node.cpp src/visensor.cpp )
add_executable(custom_node src/custom_node.cpp include/custom_node.h)
add_dependencies(visensor_node ${${PROJECT_NAME}_EXPORTED_TARGETS}})
add_dependencies(custom_node ${${PROJECT_NAME}_EXPORTED_TARGETS}})
target_link_libraries(visensor_node ${libvisensor_LIBRARIES} ${catkin_LIBRARIES} ${OpenCV_LIBRARIES})
target_link_libraries(custom_node ${libvisensor_LIBRARIES} ${catkin_LIBRARIES} ${OpenCV_LIBRARIES})
What could possibly be going wrong.?
I recently posted this as an answer here
Libraries can be included and linked with include_directories() and link_directories() like this:
cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)
...
include_directories(${PROJECT_SOURCE_DIR})
include_directories(/path/to/opencv/OpenCV-2.4.1/include)
link_directories(/path/to/opencv/OpenCV-2.4.1/lib)
...
# Set the build type. Options are:
# Coverage : w/ debug symbols, w/o op ...
and remove the std. linking to your current OpenCV libs.
I started writing this as I was struggling to get ZF2 Asset Manager to work properly however in mid swing I managed to sort out the problem and felt the question still needs to be asked in order to help others.
If you are looking for an Asset Manager for ZF2, try out: https://github.com/RWOverdijk/AssetManager
The problems I faced was essentially due to a lack of documentation and the solution was really simple.
For asset manager to work, you essentially need to generate a cache of your files that your app can locate. Once the files have been located and are reachable, your app will speed up tremendously. The first problem I faced was the module.config.php file. The documentation is not clear in how to set this up correctly.
My original file looked like this:
'asset_manager' => [
'resolver_configs' => [
'paths' => [
__DIR__ . '/../assets',
]
],
],
Which essentially tells my application to look in the module/assets directory for any assets. This worked out the box but was VEERY slow...
I read up about caching and my modification of my file was as follows:
'asset_manager' => [
'caching' => [
'default' => [
'cache' => 'FilePath', // Apc, FilePath, FileSystem etc.
],
],
'resolver_configs' => [
'paths' => [
__DIR__ . '/../assets',
]
],
],
This did nothing... so after searching code in gitHub to see how others had implemented Asset Manager I discovered you can set the options of where to put the cache... so my new config became this:
'asset_manager' => [
'caching' => [
'default' => [
'cache' => 'FilePath', // Apc, FilePath, FileSystem etc.
'options' => [
'dir' => getcwd() . 'public',
]
],
],
'resolver_configs' => [
'paths' => [
__DIR__ . '/../assets',
]
],
],
Still my app was not working although the assets where being generated in a folder called: trunkpublic in the root of my app. After much frustration I realised that I need to update:
'dir' => getcwd() . 'public', to 'dir' => getcwd() . '/public',
Adding a slash put the folder in the public directory, which in retrospect is obvious since the app needs access to the cached files.
My final configuration is this:
'asset_manager' => [
'caching' => [
'default' => [
'cache' => 'FilePath', // Apc, FilePath, FileSystem etc.
'options' => [
'dir' => getcwd() . '/public',
//'dir' => getcwd() . '/data/cache/assets',
]
],
],
'resolver_configs' => [
'paths' => [
__DIR__ . '/../assets',
]
],
],
You will notice I have this snippet commented out:
//'dir' => getcwd() . '/data/cache/assets',
The above is super fast and is used with the Filepath option and is great for development mode, it essentially generates a hash of the file in the /data.cache/assets directory however for a production environment I prefer to have actual files saved to the assets cache found in: public/assets as this allows the app to grab the files directly without having to invoke php.
NOTE:
There was another issue I faced and this is due to misleading documentation
If you look at this line:
'cache' => 'Filesystem', // Apc, FilePath, FileSystem etc.
You may be tempted to add your files using CamelCase... however some may reauire CamelCase and others may require Normalcase... check the code for this...
works for me!!
'asset_manager' => array(
'caching' => array (
'default' => array(
'cache' => 'FilePath', // Apc, FilePath, FileSystem etc.
'options' => array(
'dir' => './public',
),
),
),
'resolver_configs' => array(
'paths' => array(
'MyModule' => __DIR__ . '/../public',
),
),
),
now i try fix flter JSMin and JSSqueeze
tank you!
I'm using output cache in zend framework 2:
$outputCache = Zend\Cache\PatternFactory::factory(
'output',
array(
'storage' => 'apc'
)
);
$outputCache->start('mySimpleViewScript');
include '/path/to/view/script.phtml';
$outputCache->end();
Please help me config time cache(ttl) and cache_dir.
Thanks.
If you pass storage by string ('apc' in your example), specific storage implementation is pulled from Zend\Cache\Storage\AdapterPluginManager as invokable with default options (ttl is 0 by default).
If you need custom options, just create your cache storage directly, it is covered by cache storage adapter documentation:
$cache = Zend\Cache\StorageFactory::factory([
'adapter' => [
'name' => 'apc',
'options' => [ 'ttl' => 3600 ],
],
]);
$outputCache = Zend\Cache\PatternFactory::factory('output', [
'storage' => $cache,
]);
cache_dir is not valid option for Apc adapter.
I have a plugin that uses OpenCV and it works perfectly on Kubuntu. Now I am trying to run the code on CentOS but when I run the pipeline, I get:
$ gst-launch videotestsrc ! opencvelement ! ximagesink
WARNING: erroneous pipeline: no element "opencvelement"
When I run ldd in Kubuntu, I get:
$ ldd .libs/libOPENCVELEMENT.so
linux-gate.so.1 => (0x0060f000)
libgstbase-0.10.so.0 => /usr/lib/libgstbase-0.10.so.0 (0x00a74000)
libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x00474000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0x006a2000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0x00110000)
libopencv_core.so.2.3 => /usr/local/lib/libopencv_core.so.2.3 (0x00730000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00209000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x002f4000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00acd000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x0031e000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x0033c000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0x00357000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0x0035d000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00c9c000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00362000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x0036b000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0x00370000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0x00e52000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x00377000)
/lib/ld-linux.so.2 (0x00a10000)
But when I run it on CentOS, I don't see opencv
$ ldd .libs/libOPENCVELEMENT.so
linux-vdso.so.1 => (0x00007fff7a1fd000)
libgstvideo-0.10.so.0 => /usr/lib64/libgstvideo-0.10.so.0 (0x00002ba0ac9b7000)
libgstcontroller-0.10.so.0 => /usr/lib64/libgstcontroller-0.10.so.0 (0x00002ba0acbc4000)
libgstbase-0.10.so.0 => /usr/lib64/libgstbase-0.10.so.0 (0x00002ba0acdeb000)
libgstreamer-0.10.so.0 => /usr/lib64/libgstreamer-0.10.so.0 (0x00002ba0ad03c000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00002ba0ad326000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00002ba0ad569000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00002ba0ad76c000)
librt.so.1 => /lib64/librt.so.1 (0x00002ba0ad970000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002ba0adb7a000)
libz.so.1 => /lib64/libz.so.1 (0x00002ba0adeb7000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00002ba0ae0cb000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ba0ae3a8000)
libm.so.6 => /lib64/libm.so.6 (0x00002ba0ae6a8000)
libc.so.6 => /lib64/libc.so.6 (0x00002ba0ae92b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ba0aec83000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ba0aee91000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ba0af0ac000)
/lib64/ld-linux-x86-64.so.2 (0x0000003f6c800000)
Here is my makefile.am, which is the same on both OS
plugin_LTLIBRARIES = libOPENCVELEMENT.la
# Plugin source files:
libOPENCVELEMENT_la_SOURCES = opencv_chain.c opencv_chain.h datasetup.h
libOPENCVELEMENT_la_CFLAGS = \
$(GST_PLUGINS_BASE_CFLAGS) \
$(GST_CFLAGS) \
$(OPENCV_CFLAGS)
libOPENCVELEMENT_la_CXXFLAGS = \
$(GST_PLUGINS_BASE_CFLAGS) \
$(GST_CFLAGS) \
$(OPENCV_CFLAGS)
libOPENCVELEMENT_la_LIBADD = \
$(GST_PLUGINS_BASE_LIBS) \
$(GST_LIBS) \
$(OPENCV_LIBS) \
-lopencv_core \
-lopencv_highgui
libOPENCVELEMENT_la_LDFLAGS = $(GST_PLUGIN_LDFLAGS)
libOPENCVELEMENT_la_LIBTOOLFLAGS = --tag=disable-static
Let me know if you need more information. Any help will be appreciated. Thank you.
Do you have all the opencv development files installed on centos as well. Run a:
grep "OPENVC_" Makefile
to check what the Make variables contain. Also you can pipe the linker (undefined symbol) output through c++filt to see the real function name instead of the mangled name.
I was able to solve this by going to /usr/lib64/pkgconfig and modified opencv.pc to explicitly have all libraries. I also had to move the plugins from /usr/lib/gstreamer-0.10 to /usr/lib64/gstreamer-0.10