I am trying to load a JPEG image using the cvLoadImage function and it fails. I get the output "image not loaded" (see the code below). However a window appears but no picture.
When trying to load png pictures the cvLoadImage operation is successful, i.e. the picture is presented in a window. Is there a package that I might be missing or what am I doing wrong?
I am using openCV on Ubuntu.
IplImage* img = NULL;
if( argc > 1 )
img = cvLoadImage(argv[1], 1);
if(img == 0)
printf("image not loaded \n")
Jpeg's load fine under OpenCv, I just checked it. Check to see that you got
the path correct
that the image you are loading is actually jpeg (or some kind of format actually supported by opencv.)
Actually the path is correct. I do not know if it is the way that I am building OpenCV that is incorrect:
General configuration ================================================
CXX: g++
CXXCPP: g++ -E
CPPFLAGS:
CXXFLAGS:
LDFLAGS:
Install path: /usr/local
Debug flags
Optimization flags -DNDEBUG -O3 -g -march=pentium4 -ffast-math -fomit-frame-pointer
MMX/SSE/SSE2/SSE3: -mmmx -msse -msse2 -msse3
OpenMP support: -fopenmp
External BLAS & LAPACK: no
HighGUI configuration ================================================
Windowing system --------------
Use Carbon / Mac OS X: no
Use gtk+ 2.x: yes
Use gthread: yes
Image I/O ---------------------
Use ImageIO / Mac OS X: no
Use libjpeg: yes
Use zlib: yes
Use libpng: yes
Use libtiff: no
Use libjasper: no
Use libIlmImf/OpenEXR: no
Video I/O ---------------------
Use QuickTime / Mac OS X: no
Use xine: no
Use gstreamer: no
Use ffmpeg: no
Use dc1394 & raw1394: no
Use v4l: yes
Use v4l2: yes
Use unicap: no
Wrappers for other languages =========================================
SWIG
Python no
Octave no
Additional build settings ============================================
Build demo apps yes
Now run make ...
I have rebuilt openCV as well as changed to root user when doing it instead of typing sudo. Now the jpg files can be opened. I might have lost the sudo 'somewhere in the installation of openCV procedure earlier on, which lead to some mismatch.
Related
I have been attempting to link a MACHO formatted object file on Linux, but I have failed miserably. So far, I have created the object file by running:
nasm -fmacho -o machoh.o hello.o
I have tried linking using:
clang --target=x86_64-apple-darwin machoh.o
but that failed. I have attempted using GCC, LD, and other linkers but I have still failed miserably. Are there any ideas on how I could solve my problem?
Thank you very much.
The most accessible solution would be lld, the LLVM linker.
lld does not ship with clang, but is a separate package.
sudo apt install lld
If you installed a version of clang that isn't the default (e.g. clang-12 explicitly), then you should use the same version for lld (i.e. lld-12).
Get a MacOS SDK from somewhere. This GitHub repo archives them.
If you're uncomfortable using the above, the "legitimate" way of obtaining it without a Mac would be:
Create an Apple ID
Go to https://developer.apple.com/download/all/
Download the "Command Line Tools for Xcode <version>"
Mount or extract the dmg
Extract the XAR package
For each ".pkg" folder inside, run pbzx <Payload | cpio -i
Find the Library/Developer/CommandLineTools/SDKs/MacOSX.sdk inside.
Feed both of the above to clang:
clang --target=x86_64-apple-darwin -fuse-ld=lld --sysroot=path/to/MacOSX.sdk machoh.o
I have tried linking using: clang --target=x86_64-apple-darwin machoh.o
but that failed.
Failed how? Details matter.
Anyway, there are 3 commonly used linkers on Linux: BFD-ld, Gold, and (newest) LLD.
Of these, Gold is an ELF-only linker, and will not work for Mach-O.
BFD-ld is only configured to support a few emulations (use ld --help to see which ones) in my distribution. BFD does appear to support Mach-O, so it's probably possible to build a Linux BFD-ld cross-linker with such support.
LLD should support Mach-O out of the box, but you are probably not using LLD.
So your first step should be to figure out which linker clang --target=x86_64-apple-darwin ... uses, and then make it use the one which does support Mach-O.
A directory teeming with demonstration files called ncurses-examples-20200725 is available here:
[ftp://ftp.invisible-island.net/ncurses-examples/current/ncurses-examples.tar.gz][1]
I wanted to study the workings of the form_driver_w example so I built the programs in accordance with the README file.
If I run ./form_driver_w, the result is a command line statement: "This program requires the wide-ncurses and forms library".
That outcome occurs because the following statement is not true:
#if USE_WIDEC_SUPPORT && USE_LIBFORM && (defined(NCURSES_VERSION_PATCH) && NCURSES_VERSION_PATCH >= 20131207)
Trying to trace how and where in the labyrinth of header files and compiler switches USE_WIDEC_SUPPORT is set to true is diabolically difficult. Furthermore, since the source code uses form_driver_w, I would have expected the compiler to link to ncursesw. However the compiler call is like this:
gcc -g -O2 -o form_driver_w ../ncurses-examples-20200725/form_driver_w.o ../ncurses-examples-20200725/popup_msg.o -L/lib64 -I. -I. -I../test -DHAVE_CONFIG_H -DDATA_DIR=\"/usr/local/share\" -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XPG5 -g -O2 -DNCURSES_STATIC -lform -lmenu -lpanel -lncurses -lutil -lm
My Debian Bullseye installation includes a binary called form_driver_w in the /usr/lib/ncurses/examples/ directory. That binary runs correctly. I do not know how it was compiled.
Compiling and running form_driver_w must be a trivial task. Does anybody know how to do it?
You'd have to configure using ncursesw:
configure --with-screen=ncursesw
(and, of course, have the development library available).
The place to find this information is by running
configure --help
which lists a few options:
General Options:
--disable-stripping do not strip (debug info) installed executables
--enable-string-hacks work around bogus compiler/loader warnings
--with-pkg-config{=path} enable/disable use of pkg-config
--disable-echo do not display "compiling" commands
Curses Version-dependent Options:
--with-ncurses-wrap-prefix naming-prefix for ncurses wrapped-variables
--disable-widec disable checks for wide-character functions
--with-curses-dir=DIR directory in which (n)curses is installed
--with-screen=XXX use specified curses-libraries
--with-ncursesw use wide ncurses-libraries
--with-ncurses use ncurses-libraries
--with-pdcurses compile/link with pdcurses X11 library
--with-curses-colr compile/link with HPUX 10.x color-curses
--with-curses-5lib compile/link with SunOS 5lib curses
--with-Xaw3d link with Xaw 3d library
--with-Xaw3dxft link with Xaw 3d xft library
--with-neXtaw link with neXT Athena library
--with-XawPlus link with Athena-Plus library
--with-x use the X Window System
--with-x11-rgb=FILE file containing X11 rgb information (EPREFIX/lib/X11/rgb.txt)
--with-form-libname=XXX override form basename of library
--with-menu-libname=XXX override menu basename of library
--with-panel-libname=XXX override panel basename of library
--disable-panel disable checks for panel functions
--disable-menu disable checks for menu functions
--disable-form disable checks for form functions
Testing/development Options:
--enable-warnings test: turn on gcc compiler warnings
--with-dmalloc test: use Gray Watson's dmalloc library
--with-dbmalloc test: use Conor Cahill's dbmalloc library
--with-valgrind test: use valgrind
--disable-leaks test: free permanent memory, analyze leaks
--disable-rpath-hack don't add rpath options for additional libraries
Background
I have read countless GitHub project threads and everything I can find on StackOverflow about this problem, though so far no luck. I have a Mac 10.14 box running with the stock CommandLineTools and/or Xcode. I'm trying to "port" a Python wrapper library I have written around an older C and C++ library using CTypes in Python3. It works well already on Ubuntu Linux. However, there is no end to the problems I have been coming across since moving to a Mac platform. There just doesn't seem to be an easy answer to fixing what I'm trying to do on the broken Mac OS platform right now -- at least for the uninitiated Linux person like myself.
I have one question right off the bat before I describe how I'm compiling the dylib I'm trying to load up with CTypes: Do I now need to sign my dylib somehow before I can use it on Mac 10.14? Otherwise, I guess my question boils down to how the $%^# (and that is truncated speak for what I do mean right now) can I deal with shared / dynamic libraries on Mac with a Python C extension interface?
My preference is to not even touch Xcode and just use the stock Mac tools that come with the system out of the box. My solution must work on the command line without defering to some auto configuration magic that Xcode will give you in GUI form. Really, this is all fairly painless for what it is under Linux.
Compilation and linking
The scenario is actually more complicated than I can describe. I will just sketch what seems to me to be the relevant parts of the solution, and then let you all experts who have gotten this working before tell me the obvious missteps in between.
I'm compiling the older C/C++ source code library as a static archive first using the following
gcc (read clang) options on Mac (some of them get ignored):
-O0 -march=native -force_cpusubtype_ALL -fPIC -I../include -fPIC -m64 \
-fvisibility=default -Wno-error -lc++ -lc++abi
Then I'm compiling and linking with a combination of
-Wl,-all_load $(LIBGOMPSTATIC).a $(LIBGMPSTATIC) -Wl,-noall_load \
-ldl -lpthread -lc++ -lc++abi
and
-dynamiclib -install_name $(MODULENAME) \
-current_version 1.0.0 -compatibility_version 1.0
to generate the dylib output.
For comparison, on Linux, the analogs to these flags that work are approximately
-Wl,-export-dynamic -Wl,--no-undefined -shared -fPIC \
-fvisibility=default -Wl,-Bsymbolic
-Wl,-Bstatic -Wl,--whole-archive $(LIBGOMPSTATIC).a $(LIBGMPSTATIC) -Wl,--no-whole-archive \
-Wl,-Bdynamic -Wl,--no-as-needed -ldl -lpthread
and
-Wl,-soname,$(MODULENAME)
The dylib output
The above procedure gives me a dylib file that I can scan with nm to see the symbols I am trying to import with CTypes. This is a good start. When I try to run the test python script to test my CTypes wrapper library, I get a SEGFAULT immediately. Since gdb is apparently useless on Mac these days (sorry), I used the stock llvm to load up a brew-installed python3 with extra debugging symbols:
lldb /usr/local/Cellar/python-dbg\#3.7/3.7.6_13/bin/python3
(lldb) run myscript.py
Process 75435 launched: '/usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3' (x86_64)
Process 75435 stopped
* thread #2, stop reason = exec
frame #0: 0x0000000100005000 dyld`_dyld_start
dyld`_dyld_start:
-> 0x100005000 <+0>: popq %rdi
0x100005001 <+1>: pushq $0x0
0x100005003 <+3>: movq %rsp, %rbp
0x100005006 <+6>: andq $-0x10, %rsp
Target 0: (Python) stopped.
(lldb) bt
* thread #2, stop reason = exec
* frame #0: 0x0000000100005000 dyld`_dyld_start
(lldb) c
... redacted path information ...
File "/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
return self._dlltype(name)
File "/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(GTFoldPython.dylib, 6): image not found
Process 75435 exited with status = 1 (0x00000001)
I do have each of the environment variables PYTHONAPPSDIR=/usr/local/Cellar/python-dbg#3.7/3.7.6_13, PYTHONPATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH set to correct paths.
So the question is what do I try next to get this working? Many, many hours of thanks in advance!
In my case, the issue turned out to be two things.
The first is that I was running my python script with a different version of python than the C extensions were linked with. For example, the following is the output of my python3-config --ldflags command:
-L/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7dm-darwin -lpython3.7dm -ldl -framework CoreFoundation
So running it with /usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3 caused errors for me. This can be resolved by running the script with /usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3.7dm. Not an obvious fix given that brew installs each with an only slightly modified tap formula.
Second, in my C code, I am frequently writing to an extern'ed character buffer that lives on the stack. When this happens, the default clang stack protection mechanisms throw a SIGABRT at the script. To avoid this, you can recompile by passing the following flags to both the compiler and linker (might be more disabling than is actually needed):
-fno-stack-check -fno-stack-protector -no-pie -D_FORTIFY_SOURCE=0
With these two fixes in place my script runs. And still crashes for other reasons related to multithreading with Python in C. However, this is to be expected, but still has yet to show up in my testing on Linux.
Thanks to #l'L'l for helping me to work through this.
First of all: I have read all similar posts and have been looking for over a Week. The Question is not repeated and I searched a lot.
Basically i m trying to compile a simple helloWorld c++ program with docker using clang as cross compiler for raspberry pi 3.
I am using VM Ubuntu 18.04
compiler clang 8
when i cross compile the code in docker using clang:
fatal error: 'bits/c++config.h' no such file or directory ...
here is CMakeLists.txt file
cmake_minimum_required(VERSION 3.7.2)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(triple arm-linux-gnueabihf)
set(CMAKE_C_COMPILER clang)
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_CXX_COMPILER_TARGET ${triple})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17")
set(DCMAKE_CROSSCOMPILING=True)
set(DLLVM_DEFAULT_TARGET_TRIPLE=arm-linux-gnueabihf)
set(DLLVM_TARGET_ARCH=ARM)
set(DLLVM_TARGETS_TO_BUILD=ARM)
#executing...
project (arm_cross)
add_executable(hello hello.cpp )
i expected after invoke make to get executable file for arm
I have never dealt with docker. But half a year ago, I also had an issue of cross compiling code for raspberry, under mac os though. Anyways, I used clang as a toolchain, and finally I have succeed.
Key point is to provide clang with good target rootfs. I just mounted real raspberry through sshfs.
Another thing is that I didn't put compiler settings into CMakeLists.txt but provided cmake with toolchain file.
My cmake toolchain file:
SET(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
# Custom toolchain-specific definitions for your project
set(PLATFORM_ARM "1")
set(PLATFORM_COMPILE_DEFS "COMPILE_GLES")
# There we go!
# Below, we specify toolchain itself!
SET(TARGET_TRIPLE arm-linux-gnueabihf)
# Specify your target rootfs mount point on your compiler host machine
SET(TARGET_ROOTFS /Volumes/rootfs-${TARGET_TRIPLE})
# Specify clang paths
SET(LLVM_DIR /Users/stepan/projects/shared/toolchains/llvm-7.0.darwin-release-x86_64/install)
SET(CLANG ${LLVM_DIR}/bin/clang)
SET(CLANGXX ${LLVM_DIR}/bin/clang++)
# Specify compiler (which is clang)
SET(CMAKE_C_COMPILER ${CLANG})
SET(CMAKE_CXX_COMPILER ${CLANGXX})
# Specify binutils
SET (CMAKE_AR "${LLVM_DIR}/bin/llvm-ar" CACHE FILEPATH "Archiver")
SET (CMAKE_LINKER "${LLVM_DIR}/bin/llvm-ld" CACHE FILEPATH "Linker")
SET (CMAKE_NM "${LLVM_DIR}/bin/llvm-nm" CACHE FILEPATH "NM")
SET (CMAKE_OBJDUMP "${LLVM_DIR}/bin/llvm-objdump" CACHE FILEPATH "Objdump")
SET (CMAKE_RANLIB "${LLVM_DIR}/bin/llvm-ranlib" CACHE FILEPATH "ranlib")
# You may use legacy binutils though.
#SET(BINUTILS /usr/local/Cellar/arm-linux-gnueabihf-binutils/2.31.1)
#SET (CMAKE_AR "${BINUTILS}/bin/${TARGET_TRIPLE}-ar" CACHE FILEPATH "Archiver")
#SET (CMAKE_LINKER "${BINUTILS}/bin/${TARGET_TRIPLE}-ld" CACHE FILEPATH "Linker")
#SET (CMAKE_NM "${BINUTILS}/bin/${TARGET_TRIPLE}-nm" CACHE FILEPATH "NM")
#SET (CMAKE_OBJDUMP "${BINUTILS}/bin/${TARGET_TRIPLE}-objdump" CACHE FILEPATH "Objdump")
#SET (CMAKE_RANLIB "${BINUTILS}/bin/${TARGET_TRIPLE}-ranlib" CACHE FILEPATH "ranlib")
# Specify sysroot (almost same as rootfs)
SET(CMAKE_SYSROOT ${TARGET_ROOTFS})
SET(CMAKE_FIND_ROOT_PATH ${TARGET_ROOTFS})
# Specify lookup methods for cmake
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
# Sometimes you also need this:
# set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
# Specify raspberry triple
set(CROSS_FLAGS "--target=${TARGET_TRIPLE}")
# Specify other raspberry related flags
set(RASP_FLAGS "-D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS")
# Gather and distribute flags specified at prev steps.
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${CROSS_FLAGS} ${RASP_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CROSS_FLAGS} ${RASP_FLAGS}")
# Use clang linker. Why?
# Well, you may install custom arm-linux-gnueabihf binutils,
# but then, you also need to recompile clang, with customized triple;
# otherwise clang will try to use host 'ld' for linking,
# so... use clang linker.
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=lld)
My article with detailed description is here.
Hopefully it will help.
I also would separate this problem on two steps:
1. Get it compiled by clang.
2. Integrate compilation settings into docker.
Good luck!
Solution as follow what i did
Firstly backup /usr/include then move /usr/arm/include file to up. Finally run your 32 bit arm application.
This step can be automated by simple shell script.
Working with embedded C-projects. There are libraries, include files and so on - for micro controllers. No need for me to use GCC for a host machine and OS (Linux Mint 64 bit). As a rule...
But now I'm trying to compile mspdebug project from a Github - with a GCC of course. And I get an error at the very begin of make:
mspdebug$ make
cc -DUSE_READLINE -O1 -Wall -Wno-char-subscripts -ggdb -I. -Isimio -Iformats -Itransport -Idrivers -Iutil -Iui -DLIB_DIR=\"/usr/local/lib/\" -o util/btree.o -c util/btree.c
util/btree.c:19:20: fatal error: assert.h: No such file or directory
#include <assert.h>
^
compilation terminated.
I search for the includes in all possible paths (I've got the list of them via gcc -v command) - there are no assert.h file, as well, as stdio.h and so on. Except virtual box directories there is only one place (where GCC does not search includes): /usr/lib/syslinux/com32/include
AFAIK, all standard libs and includes are installed with the GCC. So I try to reinstall GCC (4.8.4) - nothing changes.
What is the normal way to give GCC all standard environment it needs?
Thanks to the right direction set by Sam Varshavchik I found the info in the stackoverflow. So I did the following:
1) installed build-essential:
sudo apt-get install build-essential
2) installed libusb (since my try to build the package revealed the absence of usb.h):
sudo apt-get install libusb-dev
And it is OK! The mspdebug (v.023) is compiled and successfully tested!
So, Linux Mint 17.2 (at least) requires installing some libs to a GCC, the most basic is build-essential.
assert.h is not part of gcc, it's a part of glibc.
Most likely, your Linux distribution puts the system headers into a separate package that you need to install.
Fedora, for examples, puts the header files in the glibc-headers package. However, you can't be using Fedora, because Fedora's gcc package has a dependency on glibc-headers, to make sure that it gets pulled in.
Whatever Linux distribution you're using, you need to research which distribution package will install the system header files you need to build stuff with.