I followed a guide on how to install AWS C++ SDK on Solaris here, and I got it to install successfully. The issue is that the AWS libraries installed are 32 bit instead of 64 bit. By default the AWS attempts to link to 64 bit library files on my OS, but because the AWS libraries are 32 bit it results in the following error:
ld: fatal: file /usr/lib/64/libssl.so: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to libaws-cpp-sdk-core.so
collect2: error: ld returned 1 exit status
gmake[2]: *** [aws-cpp-sdk-core/CMakeFiles/aws-cpp-sdk-core.dir/build.make:2480: aws-cpp-sdk-core/libaws-cpp-sdk-core.so] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:173: aws-cpp-sdk-core/CMakeFiles/aws-cpp-sdk-core.dir/all] Error 2
gmake: *** [Makefile:128: all] Error 2
Running file on one of the .so files (e.g. libaws-cpp-sdk-core.so) returns the following:
ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped
Doing the same for a library file already on my OS (e.g. libssl.so) returns the following:
ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped
I have been able to get everything working in 32 bit by having AWS link to the 32 bit versions of the library files it tries to link to, but I cannot find any information on how to build the AWS libraries in 64 bit and I have no idea where else to look. Any and all help is greatly appreciated.
Check comments of question for answer.
Please help me figure out what is going on with my system. When I type
rpm -qa|grep qt
I get:
qt5-rpm-macros-5.6.2-1.el7.noarch
qt-x11-4.8.5-13.el7.i686
qt5-qtxmlpatterns-5.6.2-1.el7.x86_64
qt-creator-4.1.0-3.el7.x86_64
qt5-qtbase-gui-5.6.2-1.el7.x86_64
qt-4.8.5-13.el7.i686
qt5-qttools-libs-clucene-5.6.2-1.el7.x86_64
qt-x11-4.8.5-13.el7.x86_64
qt5-qttools-libs-designercomponents-5.6.2-1.el7.x86_64
qt5-qtdeclarative-5.6.2-1.el7.x86_64
qt5-qtdoc-5.6.2-1.el7.noarch
qt5-qtquickcontrols-5.6.2-1.el7.x86_64
dbusmenu-qt-0.9.2-7.el7.x86_64
qt-4.8.5-13.el7.x86_64
qt5-qttools-libs-help-5.6.2-1.el7.x86_64
qt5-qtwebchannel-5.6.2-1.el7.x86_64
qt5-qtbase-common-5.6.2-1.el7.noarch
qt5-qttools-common-5.6.2-1.el7.noarch
polkit-qt-0.103.0-10.el7_0.x86_64
qt5-qtwebkit-5.6.2-1.el7.x86_64
qt5-qtbase-devel-5.6.2-1.el7.x86_64
qt5-qtbase-5.6.2-1.el7.x86_64
qt5-qtsensors-5.6.2-1.el7.x86_64
qt5-qttools-libs-designer-5.6.2-1.el7.x86_64
qt-settings-19-23.5.el7.noarch
qt-devel-4.8.5-13.el7.i686
qt5-qtscript-5.6.2-1.el7.x86_64
qt-creator-data-4.1.0-3.el7.noarch
qt5-qtlocation-5.6.2-1.el7.x86_64
And a few more commands and results:
arch = x86_64
qmake --version = QMake version 2.01 Using Qt version 4.8.5 in /usr/lib
My confusion:
Why are both 32 and 64 bit rpms of qt installed?
Why do I see qt5 rpms installed on a 4.8 system?
How do I know which rpms to install when installing new libraries, 32 or 64?
I am asking because I tried to install the phonon 64 bit version and get error from pro file:
/usr/bin/ld: skipping incompatible /usr/lib64/libphonon.so when searching for -lphonon
/usr/bin/ld: cannot find -lphonon
And when I tried to install 32 bit version I get dependency issues on 12 .so files, for example:
libpulse-mainloop-glib.so.0 is needed by phonon-4.6.0-10.el7.i686
libpulse-mainloop-glib.so.0(PULSE_0) is needed by phonon-4.6.0-10.el7.i686
libpulse.so.0 is needed by phonon-4.6.0-10.el7.i686
libgstreamer-0.10.so.0 is needed by phonon-backend-gstreamer-2:4.6.3-3.el7.i686
Which I cant locate anywhere on my system. Please fill in my gaps and explain what I'm seeing if possible
Compiling Xcode Project fails with following errors:
'missing required architecture arm64 in file /Users/*/Git/ocr/opencv2.framework/opencv2'
It works well, if i change Architectures(under Build Settings) to (armv7, armv7s) instead of (armv7, armv7s).
How to change the opencv python build script, to add arm64 support to opencv2.framework?
The latest OpenCV iOS framework supports 64 bit by default
It can be downloaded at: OpenCV download page
I modified the following to make it build, though I haven't got an arm64 iOS device to test at the moment.
Edit: I also had to follow https://stackoverflow.com/a/17025423/1094400
Assuming "opencv" is the folder containing the opencv source from Github:
in each of gzlib.c, gzread.c, gzwrite.c located in opencv/3rdparty/zlib/ add:
#include <unistd.h>
at the top after the existing include.
In addition open opencv/platforms/ios/cmake/Modules/Platform/iOS.cmake and change line 88 from:
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_BIT)" CACHE string "Build architecture for iOS")
to:
set (CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_INCLUDING_64_BIT)" CACHE string "Build architecture for iOS")
Furthermore change the buildscript at opencv/platforms/ios/build_framework.py in lines 99 and 100 from:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "i386"]
to:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386", "x86_64"]
The resulting library will include the following:
$ xcrun -sdk iphoneos lipo -info opencv2
Architectures in the fat file: opencv2 are: armv7 armv7s i386 x86_64 arm64
Although I have a remaining concern regarding opencv/platforms/ios/cmake/Toolchain-iPhoneOS_Xcode.cmake which defines the size of a data pointer to be 4 in lines 14 and 17.
It should be 8 for 64bit I guess, so as I haven't tested if the compiled library is working for arm64 I would suggest further investigations at this point if it does not run properly.
micahp's answer was almost perfect, but missed the simulator version. So modify platforms/ios/build_framework.py to:
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386", "x86_64"]
You'll need to download the command line tools for Xcode 5.0.1 and then run
python opencv/platforms/ios/build_framework.py ios
Try to wait a next month. Will release a new XCode with more powerful supporting of 32/64 bit.
https://developer.apple.com/news/index.php?id=9162013a
Modify "build_frameworks.py" to:
def build_framework(srcroot, dstroot):
"main function to do all the work"
targets = ["iPhoneOS", "iPhoneOS", "iPhoneOS", "iPhoneSimulator"]
archs = ["armv7", "armv7s", "arm64", "i386"]
for i in range(len(targets)):
build_opencv(srcroot, os.path.join(dstroot, "build"), targets[i], archs[i])
put_framework_together(srcroot, dstroot)
#Jan, I followed your instructions, but OpenCV still doesn't run on arm64. You made such a detailed and wonderful answer - why not check it out on a simulator and see if you can make it run? :-)
FWIW, I think it might be harder than it seems. On the openCV stackoverflow clone, there's an indication that this problem might be non-trivial.
Instead of using terminal commands given in the opencv installation guide in official website, use the following commands. Worked for me.
cd OpenCV-2.3.1
mkdir build
cd build
cmake -G "Unix Makefiles" ..
make
sudo make install
I was having a similar error, but the issue wasn't related with the arm64 coompilation.fixed adding the framework libc++.dylib
Like previously referred here, ___sincos_stret can not be found when compiling a project that uses this symbol using the Xcode5 command line tools.
In the above referenced thread a solution is posted for IOS targets (passing -miphoneos-version-min=5.0 to the compiler), is there a solution for desktop (x64) targets?
It for example happens for me when trying to compile polycode.
Edit 2:
Strangely, after compiling the libraries referenced in the previous error manually, the error now happens to be located in lto.o, which is an internal llvm header itself...
undef: ___sincos_stret
Undefined symbols for architecture x86_64:
"___sincos_stret", referenced from:
_mdct_init in lto.o
_dradfg in lto.o
I'm running OSX 10.9 DP with Xcode 5. This is the link step.
stret is Apple-speak for "returns a structure". ___sincos_stret is an LLVM optimisation — if you write code that calls sin(n) and then cos(n) and uses both results then the compiler will make one call to the structure-returning sincos method, receiving a structure with both things in it. It's faster to work out both at once rather than individually if the operand is the same.
On a superficial browsing I can't see a sin or cos in initInterTab2D but I expect something is being inlined.
While poking around I tried:
cd /Applications/Xcode.app/Contents/Developer/Platforms
grep -lr ___sincos_stret *
Via that and using nm on likely results, I found the ___sincos_stret function is exposed in both iOS since 7.0 and OS X since 10.9 as part of their libsystem_m.dylibs. E.g. if your Xcode is installed in the default place, try:
nm /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
And/or:
nm /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
You'll see the symbol in either of those. So the correct solution would be to set an older deployment target in Xcode, or do the equivalent in your makefile.
You want -mmacosx-version-min=10.8 (or whatever your targeted OS version is).
It seems like un- and reinstalling Xcode5 DP and the OSX 10.9 command line tools solved the problem. I guess there was a problem with updating from the previous versions.
Open the following file in a text editor
/opt/local/etc/macports/macports.conf
and add there a lines like
# MACOSX_DEPLOYMENT_TARGET - osx version to be compatible with earlier OSX version.
macosx_deployment_target 10.8
MACOSX_DEPLOYMENT_TARGET 10.8
I am trying to build omniORB libraries on RHEL 5.5.
I tried running configure with
CC=gcc and CXX=g++ and PYTHON=bin/omnipython
I run into this problem where it complains about
gmake[3]: Entering directory `/home/local/NT/jayanthv/omniORB-4.1.4/src/lib/omniORB'
../../../bin/omniidl -bcxx -p../../../src/lib/omniORB -Wbdebug -Wba -p../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../idl/Naming.idl
omniidl: ERROR!
omniidl: Could not open IDL compiler module _omniidlmodule.so
omniidl: Please make sure it is in directory /home/local/NT/jayanthv/omniORB-4.1.4/lib
omniidl: (or set the PYTHONPATH environment variable)
omniidl: (The error was '/home/local/NT/jayanthv/omniORB-4.1.4/lib/_omniidlmodule.so: wrong ELF class: ELFCLASS64')
So, I tried to use the Intel C++ compiler instead, with
export CXX=/opt/intel/Compiler/11.1/080/bin/ia32/icc
export LD_LIBRARY_PATH=/opt/intel/Compiler/11.1/080/lib/ia32
export PYTHON=/home/local/NT/jayanthv/omniORB-4.1.4/bin/omnipython
But, now it complains about
../../../bin/omniidl -bcxx -p../../../src/lib/omniORB -Wbdebug -Wba -p../../../src/lib/omniORB -Wbdebug -v -ComniORB4 ../../../idl/Naming.idl
omniidl: ERROR!
omniidl: Could not open IDL compiler module _omniidlmodule.so
omniidl: Please make sure it is in directory /home/local/NT/jayanthv/omniORB-4.1.4/lib
omniidl: (or set the PYTHONPATH environment variable)
omniidl: (The error was '/home/local/NT/jayanthv/omniORB-4.1.4/lib/_omniidlmodule.so: undefined symbol: __cxa_pure_virtual')
The OS is RHEL 5.5 with x86_64 architecture, and I am trying to build the 32 bit binaries. Would appreciate any insight into this problem.
That's because omniidl is implemented as a Python extension module.
The Python executable you are using is a 64 bit executable, so it
can't load a 32 bit library.
Check this out http://objectmix.com/object/196129-compiling-omniorb-32bits-libraries-64bits-machine-suse.html
I finally found the magic combination to building omniORB on Linux using Intel compiler.
You see where it complains about '__cxa_pure_virtual' not found, this happens under gcc because it can't find a lib called libstdc++
So, make CC="icc -lstdc++" or CC="gcc -lstdc++" depending on which compiler you are using . Do the same for CXX (if using g++, specify it at g++)
And for Python, I used the omnipython which is a python1.5, PYTHON=bin/omnipython
which means it is looking relative to the omniORB root path.
You can see where it complains about 'wrong ELF class: ELFCLASS64', this is because you are trying to link a 32 bit binary using a 64 bit linker.
So, force your compiler and linker flags to 32.
CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Once done, run your configure
./configure --prefix=/opt/omniInst --build=i686-pc-linux-gnu
Run gmake followed by gmake install, and you will see all the binaries and libs under omniInst or whichever prefix directory you suggested.