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
Related
I am trying to build a windows openssl library for a rasbery pi pico microcontroller, with an arm cortex m0 processor.
I downloaded the openssl library from the official site and unzipped it. Installed MSYS2 and launched it. It indicated the path to the directory with the openssl library:
cd /C/openssl-3.0.0-beta1
Selected settings for the config file:
./Configure gcc --cross-compile-prefix=arm-none-eabi- --prefix=/K/OpenSSL-x32-arm -mcpu=cortex-m0plus PROCESSOR=ARM -DL_ENDIAN no-shared -DNO_SYSLOG -DOPENSSL_NO_X509 -DOPENSSL_NO_X509V3 -DOPENSSL_NO_X509_VFY no-idea no-camellia no-seed no-bf no-cast no-des no-rc4 no-rc5 no-md2 no-md4 no-ripemd no-mdc2 no-dsa no-dh no-ec no-ecdsa no-ecdh no-sock no-ssl2 no-ssl3 no-err no-engine no-hw
and started compiling:
make depend && make
it throws an error:
In file included from c:\msys64\mingw64\arm-none-eabi\include\dirent.h:39,
from crypto/LPdir_unix.c:44,
from crypto/o_dir.c:28:
c:\msys64\mingw64\arm-none-eabi\include\sys\dirent.h:10:2: error: #error "<dirent.h> not supported"
10 | #error "<dirent.h> not supported"
What am I doing wrong?
The raspberry pi pico does not actually have a filesystem, so it does not support file operations. Furthermore, it only has 246kb of programmable memory. Are you sure you want to blow it all on OpenSSL? There are far smaller TLS stacks such as Mbed-TLS (<30kb) and WolfSSL (<100kb).
When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.
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
I am trying to build a 32 bit lib of curl for OSX, on a 64 bit OSX installation (Yosemite 10.10.5), according to the documentation. I've tried calling ./configure with a number of different arguments, but this is the one that I would expect to cover all bases:
CFLAGS='-m32 -arch i386' LDFLAGS='-arch i386' ./configure --host=i386-apple
I've tried different hosts as well, such as x86-apple, x86-apple-darwin, i386-apple-darwin, etc. They all build without issues, as far as I can see, but when I try to build my other 32 bit project that links to the resultant dylib, I get the following error message
warning: ignoring file [...]/libcurl.a, file was built for archive which is not the architecture being linked (i386)
And then several variations on
Undefined symbols for architecture i386:
"_curl_easy_cleanup" [...]
A call to
lipo -info libcurl.a
Yields the following result
fatal error: [...]/lipo: archive with no architecture specification: libcurl.a
What am I doing wrong? Is my ./configure call badly formed, am I missing a flag or an argument? According to the installation instructions, people have successfully compiled to i386 Mac OS X, so I'm assuming there's something I'm missing
Maybe it's late, but since I just hit the same wall... You can try specifying in configure options:
./configure --build=i386-darwin --host=x86_64-darwin
As far as I can tell, host denotes the architecture of the machine on which you are building, while build is the target architecture.
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.