Linking with warning and then undefined reference - cmake

I am trying to compile an application with Cmake.
Almost at the end of the state: 100%
I got:
/../lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld: warning: libIMGegl.so, needed by /arm-linux-gnueabi/lib/libEGL.so, not found (try using -rpath or -rpath-link)
and then a lot of messages of
undefined reference to 'something'
Where can I added -rpath or -rpath-link
This is my CMAKE FLAG:
set(CMAKE_C_FLAGS "-O2 -mcpu=cortex-a9 -mfpu=vfp -mfloat-abi=softfp -g -mtune=xscale -msoft-float -fpic -mthumb-interwork -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -fomit-frame-pointer -fno-strict-aliasing ${CMAKE_ARM_LINUX_FLAGS}" CACHE INTERNAL "")

Related

cmake extract substring from variable

I have variable CC_OPTIONS has value set like below
-arch arm64 -mcpu=abc1 -c --debug -O2 -static -fstack-protector -ffreestanding -nostartfiles -std=c11
I wanted to extract -mcpu=abc1 from CC_OPTIONS
Tried below approach, but getting more than what i wanted.
string(REGEX REPLACE ".*mcpu=(.*)\ .*" "\\1" CPU_TYPE "${CC_OPTIONS}")
any suggestions?
If you use if(MATCHES) you can get character groups of the match using CMAKE_MATCH_<n>
set(MY_VAR "-arch arm64 -mcpu=abc1 -c --debug -O2 -static -fstack-protector -ffreestanding -nostartfiles -std=c11")
if (MY_VAR MATCHES "^([^ ]+ +)*(-mcpu=[^ ]+)( +[^ ]+)*$")
message(STATUS "Found match: ${CMAKE_MATCH_2}")
else()
message(FATAL_ERROR "mismatch")
endif()
Like that:
cmake_minimum_required (VERSION 2.8.11)
project (HELLO)
set(CC_OPTIONS "-arch arm64 -mcpu=abc1 -c --debug -O2 -static -fstack-protector -ffreestanding -nostartfiles -std=c11")
message(${CC_OPTIONS})
string(REGEX MATCH "\\-mcpu=[^ $]+" CPU_TYPE ${CC_OPTIONS})
message(${CPU_TYPE})
Example:
$ cmake .
-arch arm64 -mcpu=abc1 -c --debug -O2 -static -fstack-protector -ffreestanding -nostartfiles -std=c11
-mcpu=abc1
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ja/cmake

relocation R_X86_64_PC32 against symbol can not be used when making a shared object when fPIC was already used

I have looked at numerous posts regarding resolving this type of linker error, in most cases, people just forgot to compile with -fPIC, sometimes people had trouble with inline functions, etc. that is not the case here. I am trying to wrap a c++ library for python using Pybind11. In this process, I want to link some static libraries (one of them is newmat11) into a .so file.
I build the newmat11 library using an automake system with -fPIC (here's some output...)
...
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT newmat8.lo -MD -MP -MF .deps/newmat8.Tpo -c newmat8.cpp -fPIC -DPIC -o newmat8.o
...
ar cru libnewmat11.a bandmat.o cholesky.o evalue.o fft.o jacobi.o hholder.o myexcept.o newfft.o newmat1.o newmat2.o newmat3.o newmat4.o newmat5.o newmat6.o newmat7.o newmat8.o newmat9.o newmatex.o newmatrm.o solution.o sort.o submat.o svd.o
Indeed, when I run readelf --relocs libnewmat11.a, I see plenty of relocated symbols. Here's one that's giving me trouble:
$readelf --relocs libnewmat11.a | grep ZTIN6NEWMAT17Sing
000000001d20 013c00000002 R_X86_64_PC32 0000000000000000 _ZTIN6NEWMAT17Singular - 4
Relocation section '.rela.data.rel.ro._ZTIN6NEWMAT17SingularExceptionE' at offset 0x21280 contains 3 entries:
000000005b0b 013c00000001 R_X86_64_64 0000000000000000 _ZTIN6NEWMAT17Singular + 0
0000000009fc 008d00000002 R_X86_64_PC32 0000000000000000 _ZTIN6NEWMAT17Singular - 4
Relocation section '.rela.data.rel.ro._ZTIN6NEWMAT17SingularExceptionE' at offset 0x20b38 contains 3 entries:
000000008280 008d00000001 R_X86_64_64 0000000000000000 _ZTIN6NEWMAT17Singular + 0
...
Everything seems ok so far, but when I run python3 setup.py build I get this error:
running build
running build_py
running build_ext
building 'mytest' extension
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I../.. -I../../mhfe -I/usr/include/python3.8 -I/usr/local/include/newmat11/include -c src/my_python_binding.cpp -o build/temp.linux-x86_64-3.8/src/my_python_binding.o -std=c++11 -DPYBIND11_PYTHON_VERSION=3.8
...
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.8/src/my_python_binding.o -L/usr/lib64python3.8 -o build/lib.linux-x86_64-3.8/mytest.cpython-38-x86_64-linux-gnu.so -fPIC -Wl,--whole-archive /usr/local/lib/newmat11/lib/libnewmat11.a -Wl,--no-whole-archive
/usr/bin/ld: /usr/local/lib/newmat11/lib/libnewmat11.a(newmat8.o): relocation R_X86_64_PC32 against symbol `_ZTIN6NEWMAT17SingularExceptionE' can not be used when making a shared object; recompile with -fPIC
As noted above, I'm building the static lib with -fPIC and I can see the relocation symbols in the .a file. Is there something about R_X86_64_PC32 that makes it incompatible with shared objects? I think I would need to have it produce R_X86_64_PLT32 relocation symbols instead, but I'm really not sure. I can see other R_X86_64_PLT32 relocation symbols in the library, but not for the symbol in question. Also, for the record, I'm not familiar with all of the flags that setuptools is adding to the build, perhaps one of them is giving me trouble?
All help appreciated.
I found a solution.
Although my build was using -fPIC for the dependent library, I noticed that I wasn't using --with-pic in my configure for automake. I added it just to see what the difference would be.
readelf --relocs now shows:
000000001a90 01390000002a R_X86_64_REX_GOTP 0000000000000000 _ZTIN6NEWMAT17Singular - 4
Relocation section '.rela.data.rel.ro._ZTIN6NEWMAT17SingularExceptionE' at offset 0x20f30 contains 3 entries:
000000005a54 013900000001 R_X86_64_64 0000000000000000 _ZTIN6NEWMAT17Singular + 0
0000000009fc 008c0000002a R_X86_64_REX_GOTP 0000000000000000 _ZTIN6NEWMAT17Singular - 4
Relocation section '.rela.data.rel.ro._ZTIN6NEWMAT17SingularExceptionE' at offset 0x20830 contains 3 entries:
0000000082b6 008c00000001 R_X86_64_64 0000000000000000 _ZTIN6NEWMAT17Singular + 0
This has R_X86_64_REX_GOTP relocation symbol types. I also found that my linker error has been resolved.
I can't see any difference in the compile flags after adding --with-pic, so at the compiler level, I'm not sure what the difference is. In any case, hopefully this will help somebody with a similar problem.

Android Studio NDK iostream file not found and does not able to enable neon in CMakeList

I am new on using NDK and CMake, and got the problem when I compiled my C++ library, Android studio keeps compiling that
Error:(28, 2) error: "NEON support not enabled"
Error:error: 'neon_vector_type' attribute is not supported for this
target
Error:(17, 10) fatal error: 'iostream' file not found
I have see some solution saying that I should add APP_STL := stlport_static in Application.mk
However, I am using CMakeLists instead of Application.mk.
So I added -DANDROID_ARM_NEON=TRUE -DAPP_STL=stlport_static on CMAKE_C_FLAGS, but it still produce the same error
This is my CMakeLists
set (pathToProject /home/user/project)
set (pathToOpenCv /home/user/project/OpenCV330)
FILE(GLOB_RECURSE cppfiles src/main/cpp/src/*)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED on)
find_package(OpenMP)
add_definitions(-fPIC)
add_definitions(-fopenmp)
add_definitions(-Ofast)
add_definitions(-DANDROID_STL=c++_shared)
add_definitions(-flax-vector-conversions)
add_definitions(-fopenmp)
cmake_minimum_required(VERSION 3.4.1)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -fpermissive -DANDROID_ARM_NEON=TRUE -DAPP_STL=stlport_static")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
include_directories(${pathToProject}/app/src/main/cpp/src/include)
include_directories(${pathToOpenCv}/sdk/native/jni/include)
add_library(lib_opencv SHARED IMPORTED)
add_library(native-lib SHARED src/main/cpp/native-lib.cpp )
add_library(mylibrary SHARED ${cppfiles} )
set_target_properties(lib_opencv PROPERTIES IMPORTED_LOCATION ${pathToProject}/app/src/main/jniLibs/${ANDROID_ABI}/libopencv_java3.so)
find_library(log-lib log)
target_link_libraries(
native-lib
${log-lib}
lib_opencv
mylibrary
)
Updated:
I also found 1 more compiling message, looks like the -std=c++11 is not actually applied while compiling
[10/11] Building CXX object CMakeFiles/mylibrary.dir/src/main/cpp/src/yuv420sp.cpp.o
FAILED: /home/user/Downloads/android-ndk-r14b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --target=i686-none-linux-android --gcc-toolchain=/home/user/Downloads/android-ndk-r14b/toolchains/x86-4.9/prebuilt/linux-x86_64 --sysroot=/home/user/Downloads/android-ndk-r14b/platforms/android-24/arch-x86 -Dmylibrary_EXPORTS -I../../../../src/main/cpp/include -I/home/user/git/project/OpenCV-android-sdk3.3.0/sdk/native/jni/include -I../../../../src/main/cpp/build/include -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mstackrealign -Wa,--noexecstack -Wformat -Werror=format-security -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -mstackrealign -Wa,--noexecstack -Wformat -Werror=format-security -O0 -fno-limit-debug-info -O0 -fno-limit-debug-info -fPIC -MD -MT CMakeFiles/mylibrary.dir/src/main/cpp/src/object_wrap.c.o -MF CMakeFiles/mylibrary.dir/src/main/cpp/src/object_wrap.c.o.d -o CMakeFiles/mylibrary.dir/src/main/cpp/object_wrap.c.o -c /home/user/git/project/app/src/main/cpp/object_wrap.c
In file included from /home/user/git/project/app/src/main/cpp/src/object_wrap.c:209:
/home/user/git/project/app/src/main/cpp/src/object.h:17:10: fatal error: 'iostream' file not found
#include <iostream>
^
Also tried to set the flag in app gradle, still not working
externalNativeBuild {
cmake {
cppFlags "-std=c++11", "-Wno-error=format-security"
arguments "-DANDROID_STL=gnustl_static", "-DANDROID_ARM_NEON=TRUE"
}
}
if I set -DANDROID_STL=stlport_static, it will give two more error
Error:(25, 10) fatal error: 'thread' file not found
Error:(424, 14) fatal error: 'array' file not found
After changing the to gcc toolchain in gradle, problem solved.
arguments "-DANDROID_TOOLCHAIN=gcc","-DANDROID_ARM_NEON=TRUE" ,"-DANDROID_STL_FORCE_FEATURES=OFF"
cppFlags "-std=gnu++11", "-Wno-error=format-security"

Error linking with clang+llvm

I am trying to apply LLVM optimizations to a few Image Feature Extraction algorithms which have been implemented using openCV. The LLVM-based profiler works fine with simple programs (For instance, HelloWorld), and the feature extraction algorithms too work separately as expected.
However I was unable to use the profiler for the algorithms and got the following error while linking the OpenCV libraries to the optimized code.
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-g' '-L/home/silky/opencv/share/OpenCV/3rdparty/lib' '- L/home/silky/opencv/OpenCVInstall/x86/lib' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as --gdwarf2 --64 -o /tmp/ccAhPffW.o out.s
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-g' '-L/home/silky/opencv/share/OpenCV/3rdparty/lib' '-L/home/silky/opencv/OpenCVInstall/x86/lib' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/home/silky/opencv/share/OpenCV/3rdparty/lib -L/home/silky/opencv/OpenCVInstall/x86/lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. /tmp/ccAhPffW.o -lpthread -lrt -lopencv_calib3d -lopencv_core -lopencv_features2d -lopencv_flann -lopencv_highgui -lopencv_imgproc -lopencv_ml -lopencv_objdetect -lopencv_video -lopencv_nonfree -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o
/tmp/ccAhPffW.o:(.debug_info+0x49a14): undefined reference to `.Lline_table_start1'
collect2: ld returned 1 exit status
I've used the following commands to compile and link the files.
clang -emit-llvm -c -Wall -g -O0 -DCLOCK_GETTIME_TIMING -DOPENCV_2_4 -I/home/opencv/OpenCVInstall/x86/include -o ThreadManager.bc FeatureExtraction/ThreadManager.cpp
clang -emit-llvm -c -Wall -g -O0 -DCLOCK_GETTIME_TIMING -DOPENCV_2_4 -I/home/opencv/OpenCVInstall/x86/include -o FeatureExtraction.bc FeatureExtraction/FeatureExtraction.cpp
llvm-link FeatureExtraction.bc ThreadManager.bc -o FE.bc
clang $CFLAGS -o profiler.o cacheSim.cpp //LLVM profiler
opt -load /home/llvm/llvm/Debug+Asserts/lib/cacheProf.so -cacheProf FE.bc>out.bc
llc FE.bc -o out.s
g++ -v -g out.s profiler.o -L/home/opencv/share/OpenCV/3rdparty/lib -L/home/opencv/OpenCVInstall/x86/lib -lpthread -lrt -lopencv_calib3d -lopencv_core -lopencv_features2d -lopencv_flann -lopencv_highgui -lopencv_imgproc -lopencv_ml -lopencv_objdetect -lopencv_video -lopencv_nonfree
Could some one please tell me if I am linking the files or loading the files in a wrong way?
Is clang compilation different from how g++ works?

why is Xcode / clang translating my "-fno-objc-arc" to "-fno_objc_arc"?

i have attempted to follow the advice at SF for turning off objective-C arc per file for one file by placing "-fno-objc-arc" next in the compilation flags for the file in the "Compile Sources" section of my build phases for my project.
this isn't working for me, in that ARC-related errors are still generated.
i see in the log for the file for which i attempted to do this the following warning:
"clang: warning: argument unused during compilation: '-fno_objc_arc'"
i notice that it shows underscores instead of dashes. when i look at the generated compile line, it also shows underscores instead of dashes.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c
-arch armv7 -fmessage-length=0 -std=gnu99 -fobjc-arc -Wno-trigraphs -fpascal-strings -O0
-Werror-implicit-function-declaration -Wmissing-field-initializers -Wno-missing-prototypes -Wreturn-type
-Wno-implicit-atomic-properties -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function
-Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wuninitialized -Wno-unknown-pragmas
-Wno-shadow -Wno-four-char-constants -Wno-sign-compare -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof
-Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wno-deprecated-implementations -DDEBUG=1
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk
-Wprotocol -Wdeprecated-declarations -g -Wno-conversion -Wno-sign-conversion -mthumb "-DIBOutlet=__attribute__((iboutlet))"
"-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)"
-miphoneos-version-min=5.1 -iquote /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/myproj-generated-files.hmap
-I/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/myproj-own-target-headers.hmap
-I/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/myproj-all-target-headers.hmap
-iquote /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/Voyeur.build/myproj-project-headers.hmap
-I/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Products/Debug-iphoneos/include
-I/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/DerivedSources/armv7
-I/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/DerivedSources
-F/x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Products/Debug-iphoneos -fno_objc_arc
-include /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/PrecompiledHeaders/myproj-Prefix-adnhewmpoabuzebrrqoplkebnugj/myproj-Prefix.pch
-MMD -MT dependencies -MF /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/Objects-normal/armv7/mySource.d
--serialize-diagnostics /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/Objects-normal/armv7/mySource.dia
-c /x/git/myproj/subdir/mySource.m
-o /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp/Build/Intermediates/myproj.build/Debug-iphoneos/myproj.build/Objects-normal/armv7/mySource.o
to answer my own question, the underscores were probably a remnant of having typed them in poorly at first, forgetting i had done this, but being stuck with them in the derived data cache.
the quick fix for this was to
close the project in Xcode
remove the folder /x/xcode/DerivedData/myproj-eqyvffptnyujnsgcmhlqunfmfytp
re-open the project in Xcode
re-build and re-run
in looking at the log generated after making these changes, the value there is appropriately "-fno-objc-arc", appearing later than "-fobjc-arc", and as per another stackoverflow.com answer, the last one on the command-line wins.