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.
Related
I've read countless articles, including this which sounded almost exactly like my setup/issue:
Xdebug inside Docker on Mac M1 2021 is not working
I'm getting the error message mentioned in the title, still.
Here is how I spin up the container (which ships with PHPUnit and XDebug):
docker run --rm -it -v $(pwd):/app -v $(pwd)/xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini jitesoft/phpunit /bin/ash
Here is the debug.ini I use to overwrite the defaults:
;
; NOTE: We want to echo these contents to this file location
;
; PATH: /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
;
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20220829/xdebug.so
xdebug.mode=debug
xdebug.idekey=PHPSTORM
xdebug.start_with_request=yes
xdebug.discover_client_host=0
xdebug.client_host=host.docker.internal
xdebug.log=/var/log/xdebug.log
Here is the debug config dump:
[1m__ __ _ _
[1m\ \ / / | | | |
[1m \ V / __| | ___| |__ _ _ __ _
[1m > < / _` |/ _ \ '_ \| | | |/ _` |
[1m / . \ (_| | __/ |_) | |_| | (_| |
[1m/_/ \_\__,_|\___|_.__/ \__,_|\__, |
[1m __/ |
[1m |___/
[0mVersion => 3.2.0
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
Enabled Features (through 'XDEBUG_MODE' env variable)
Feature => Enabled/Disabled
Development Helpers => ✘ disabled
Coverage => ✔ enabled
GC Stats => ✘ disabled
Profiler => ✘ disabled
Step Debugger => ✘ disabled
Tracing => ✘ disabled
Optional Features
Compressed File Support => no
Clock Source => clock_gettime
'xdebug://gateway' pseudo-host support => yes
'xdebug://nameserver' pseudo-host support => no
Systemd Private Temp Directory => not enabled
Diagnostic Log
No messages
PHP
Build Configuration
Version (Run Time) => 8.2.1
Version (Compile Time) => 8.2.1
Debug Build => no
Thread Safety => disabled
Settings
Configuration File (php.ini) Path => /usr/local/etc/php
Loaded Configuration File => (none)
Scan this dir for additional .ini files => /usr/local/etc/php/conf.d
Additional .ini files parsed => /usr/local/etc/php/conf.d/date_timezone.ini,
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini,
/usr/local/etc/php/conf.d/memory-limit.ini
Directive => Local Value => Master Value
xdebug.mode (through XDEBUG_MODE) => coverage => debug
xdebug.start_with_request => yes => yes
xdebug.start_upon_error => default => default
xdebug.output_dir => /tmp => /tmp
xdebug.use_compression => 0 => 0
xdebug.trigger_value => no value => no value
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.log => /var/log/xdebug.log => /var/log/xdebug.log
xdebug.log_level => 7 => 7
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3
xdebug.max_nesting_level => 256 => 256
xdebug.cli_color => 0 => 0
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.halt_level => 0 => 0
xdebug.max_stack_frames => -1 => -1
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.profiler_append => Off => Off
xdebug.cloud_id => no value => no value
xdebug.client_host => host.docker.internal => host.docker.internal
xdebug.client_port => 9003 => 9003
xdebug.discover_client_host => Off => Off
xdebug.client_discovery_header => HTTP_X_FORWARDED_FOR,REMOTE_ADDR => HTTP_X_FORWARDED_FOR,REMOTE_ADDR
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.connect_timeout_ms => 200 => 200
xdebug.scream => Off => Off
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_return => Off => Off
Here is the result on the console when I try and run index.php for debugging:
[docker://jitesoft/phpunit:latest/]:php -dxdebug.mode=debug -dxdebug.client_port=9000 -dxdebug.client_host=host.docker.internal -dxdebug.client_host=host.docker.internal /opt/project/index.php
Process finished with exit code 0
Two things jump out at me
The top of the debug configure dump suggests step debugging is still disabled???
The path to the php script I want to execute on the docker side is /app/index.php not /opt/project/index.php
Thoughts?
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)
I have the following SASS code to load a custom font:
#font-face
font-family: 'Fredericka the Great'
font-style: normal
font-weight: 400
src: local('Fredericka the Great'), local('FrederickatheGreat'), asset-url('assets/fredericka_the_great.woff2') format('woff2')
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215
In development, it loads fine.
On one of my servers, it does not. Looking closer at the produced code, I noticed that in the compiled CSS, there is no hash appended where the woff-file should be loaded:
#font-face{
font-family:"Fredericka the Great";
font-style:normal;
font-weight:400;
src:local("Fredericka the Great"),local("FrederickatheGreat"),url(/assets/fredericka_the_great.woff2) format("woff2");
unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2212,U+2215}
As you can see, the compiled code produces url(/assets/fredericka_the_great.woff2), while on the server, the deployed assets look like this:
So in my opinion, the CSS should produce url(/assets/fredericka_the_great-49badd2a1e856a1d9e3a6cb6189f0426bda9f2b292376395758419c2d0c631b6.woff2). In fact, trying to load the file manually works:
Works: http://staging-audit.access4all.ch.zugangfueralle01.nine.ch/assets/fredericka_the_great-49badd2a1e856a1d9e3a6cb6189f0426bda9f2b292376395758419c2d0c631b6.woff2
Does not work: http://staging-audit.access4all.ch.zugangfueralle01.nine.ch/assets/fredericka_the_great.woff2
What's interesting though is the fact that on some other server, the same application works as expected (which seems weird, as the CSS there also lacks the hash)!
Works: http://audit.uber.space/assets/fredericka_the_great-49badd2a1e856a1d9e3a6cb6189f0426bda9f2b292376395758419c2d0c631b6.woff2
Works, too: http://audit.uber.space/assets/fredericka_the_great.woff2
(For closer CSS-inspection, go to https://audit.uber.space/assets/application-9e5ba30be64b818da5468c9b39dc20aafa0ce523315d3e6684b96d11e336f603.css - or, funnily enough, just https://audit.uber.space/assets/application.css)
What makes me VERY suspicious is the fact that when I rename the woff-file on the server to something completely different, the file is still being loaded by the website. So probably the server doesn't even send the compiled woff-file, but some completely different woff-file (maybe directly from a gem directory or something)...?
I'm unsure how to proceed now, as I don't know what's the expected behaviour, and how to fix my deployment.
For the sake of completeness, here's the config of my deployment (I use mina):
$ mina -d
------- Printing current config variables -------
:debug_configuration_variables => true
:port => 22
:releases_path => #<Proc:0x007fc881157470#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/deploy.rb:3 (lambda)>
:shared_path => #<Proc:0x007fc881157380#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/deploy.rb:4 (lambda)>
:current_path => #<Proc:0x007fc8811572b8#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/deploy.rb:5 (lambda)>
:lock_file => "deploy.lock"
:deploy_script => "data/deploy.sh.erb"
:keep_releases => 5
:version_scheme => :sequence
:execution_mode => :pretty
:bundle_bin => "bundle"
:bundle_path => "vendor/bundle"
:bundle_withouts => "development test"
:bundle_options => #<Proc:0x007fc8802da898#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/bundler.rb:6 (lambda)>
:shared_dirs => ["vendor/bundle", "log", "tmp/cache", "public/assets", "public/uploads", "tmp/sockets", "tmp/pids"]
:rails_env => "production"
:bundle_prefix => #<Proc:0x007fc8802cbeb0#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/rails.rb:5 (lambda)>
:rake => #<Proc:0x007fc8802bbb50#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/rails.rb:6 (lambda)>
:rails => #<Proc:0x007fc8802bb970#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/rails.rb:7 (lambda)>
:compiled_asset_path => "public/assets"
:asset_dirs => ["vendor/assets/", "app/assets/"]
:migration_dirs => ["db/migrate"]
:branch => "master-nine"
:remove_git_dir => true
:remote => "origin"
:git_not_pushed_message => #<Proc:0x007fc88021ab10#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-1.2.3/tasks/mina/git.rb:6 (lambda)>
:web_server => :puma
:puma_role => #<Proc:0x007fc8800e7a90#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:7 (lambda)>
:puma_env => #<Proc:0x007fc8800e77c0#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:8 (lambda)>
:puma_config => #<Proc:0x007fc8800e7590#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:9 (lambda)>
:puma_socket => #<Proc:0x007fc8800e73d8#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:10 (lambda)>
:puma_state => #<Proc:0x007fc8800e7248#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:11 (lambda)>
:puma_pid => #<Proc:0x007fc8800e7108#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:12 (lambda)>
:puma_cmd => #<Proc:0x007fc8800e6e10#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:13 (lambda)>
:pumactl_cmd => #<Proc:0x007fc8800e6d20#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:14 (lambda)>
:pumactl_socket => #<Proc:0x007fc8800e6988#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:15 (lambda)>
:puma_root_path => #<Proc:0x007fc8800e65c8#/Users/josh/.rvm/gems/ruby-2.4.1#XXX/gems/mina-puma-1.1.0/lib/mina/puma/tasks.rake:16 (lambda)>
:rvm_use_path => "$HOME/.rvm/scripts/rvm"
:application_name => "A4AA 2.0"
:domain => "zugangfueralle01.nine.ch"
:deploy_to => "XXX"
:repository => "XXX"
:user => "www-data"
:forward_agent => true
:puma_port => 3006
:shared_files => ["config/secrets.yml"]
I ran in to the same issues couple month's ago and you pretty have so much going on. This is the way I resolved it:
1.- The route, first thing is first.
The best way is to save in to app -> assets -> fonts (You create this folder). Then I recommend adding there your font file (.woff) in a way it's readable.
2.- The SASS
I specially had to add this code in to my application.scss or custom.scss
#font-face {
font-family: 'Theola Kids Regular';
font-style: normal;
font-weight: normal;
src:font-url('theola-kids.woff');
src:font-url('theola-kids.woff') format('woff');
}
Noticed the src:font-url, it tells rails to find a specific font file. I have two one as a route and the other a route format file.
3.- The Pipline
Be sure to add "fonts" to the application.rb file
Example: config.assets.paths << Rails.root.join("app", "assets", "fonts")
When finish restart your rails server and check it out. It must work with this solution.
For more details I highly recommend this article:
https://gist.github.com/anotheruiguy/7379570
Good luck!
I am trying to install hdf5-openmpi-devel in Fedora 23. When I run
sudo dnf install hdf5-openmpi-devel
I get
Last metadata expiration check: 1:12:51 ago on Mon Oct 30 22:53:47 2017.
Package hdf5-openmpi-devel-1.8.15-10.patch1.fc23.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
But when I check with ldconfig, I don't see any openmpi files:
rg#supersg: ldconfig -p | grep hdf5
libhdf5hl_fortran.so.10 (libc6,x86-64) => /lib64/libhdf5hl_fortran.so.10
libhdf5_hl_cpp.so.10 (libc6,x86-64) => /lib64/libhdf5_hl_cpp.so.10
libhdf5_hl.so.10 (libc6,x86-64) => /lib64/libhdf5_hl.so.10
libhdf5_fortran.so.10 (libc6,x86-64) => /lib64/libhdf5_fortran.so.10
libhdf5_cpp.so.10 (libc6,x86-64) => /lib64/libhdf5_cpp.so.10
libhdf5.so.10 (libc6,x86-64) => /lib64/libhdf5.so.10
Any ideas how to install hdf5-openmpi-devel in Fedora 23?
The libs are in /usr/lib64/openmpi/lib
ldd /usr/lib64/openmpi/lib/libhdf5.so.8
linux-vdso.so.1 => (0x00007fffa2d3f000)
libz.so.1 => /lib64/libz.so.1 (0x00007fade3235000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fade3030000)
libm.so.6 => /lib64/libm.so.6 (0x00007fade2d2e000)
libmpi.so.12 => /usr/lib64/openmpi/lib/libmpi.so.12 (0x00007fade2a4a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fade282d000)
libc.so.6 => /lib64/libc.so.6 (0x00007fade246a000)
/lib64/ld-linux-x86-64.so.2 (0x0000559a79df2000)
libopen-rte.so.12 => /usr/lib64/openmpi/lib/libopen-rte.so.12 (0x00007fade21ee000)
libopen-pal.so.13 => /usr/lib64/openmpi/lib/libopen-pal.so.13 (0x00007fade1f49000)
librt.so.1 => /lib64/librt.so.1 (0x00007fade1d41000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fade1b3e000)
libhwloc.so.5 => /lib64/libhwloc.so.5 (0x00007fade1900000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00007fade16f4000)
libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x00007fade14e9000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fade117f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fade0f69000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fade0d42000)
they should be automatically picked if you use the MPI wrappers mpicc, mpifort and friends
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