I would like to do some development for which I need boost. (I'm using Fedora 19). The installation on the boost site seems straightforward and I'm pretty much ready. However, I found that I already have some shared boost libraries but I don't have any headers. Furthermore, I have a lot of installed software that uses the shared libs. For example
ldd /usr/bin/checkpto
produces
linux-vdso.so.1 => (0x00007fff7b115000)
libhuginbase.so.0.0 => /usr/lib64/hugin/libhuginbase.so.0.0 (0x0000003a92c00000)
libboost_thread-mt.so.1.53.0 => /lib64/libboost_thread-mt.so.1.53.0 (0x0000003a98200000)
libboost_system-mt.so.1.53.0 => /lib64/libboost_system-mt.so.1.53.0 (0x0000003a98600000)
...
Now I want to do a full boost install, but what will happen to all the binaries I have that already depend on the existing boost libraries? Will I have to maintain two sets? As you might guess from the ldd output, there are no symlinks to those libraries. They are all files. Could yum resolve the dependencies and update the binaries that depend on them?
Thanks!
It depends on whether you need a different version of the boost library than that available in the Fedora repository.
If you do not need a different version, you can simply install all the boost library packages from the Fedora repository including the ...-devel packages which provide the library headers.
If you do a different version, you will have to obtain the boost source distribution, build it and install it yourself. You just need to make sure that you DO NOT install it in the default system locations (e.g. /usr/include, /usr/lib, /usr/lib64). That way, your version can live side by side with the Fedora versions in perfect harmony.
Related
I have configured Julia portable or standalone according to the link:Julia portable or standalone
But I want to update to the latest version of Julia 1.5.1.
How to proceed?
Should I add all the packages again?
Is there a way to import it to the new version?
Julia does not support version upgrade. It perhaps might work for some packages but you are always risking to running into issues.
Hence you need to delete the .julia folder (or set a new JULIA_DEPOT_PATH location which is configured by system variable) and just reinstall all the packages.
However if you for some reason strongly want to reuse the .julia folder you can try:
https://discourse.julialang.org/t/a-proper-introduction-on-how-to-update-julia-somewhere-accessible/28166
I have installed Qt Creator 4.10.2 on Fedora 31 (KDE), using the standard 'dnf install'. Everything seems to work fine, except one thing: the documentation. When I highlight a Qt class (e.g. QApplication) and then press F1, I get the message "No documentation available". However, when I go to Tools > Options > Help > Documentation, I see six entries:
org.qt-project.qtcmake.5132 (auto-detected)
org.qt-project.qtcmake.600
org.qt-project.qtcreator.4102 (auto-detected)
org.qt-project.qtdoc.5132 (auto-detected)
org.qt-project.qtdoc.600
I have looked at the other StackOverflow questions relating to this issue, and they don't seem to answer my question. Does anyone know what I have to do to get the documentation in Qt Creator?
You are not alone!
You probably need to install a couple of additional rpms. The QApplication class belongs to the 'Qt Widgets' module, which would appear in your help configuration as:
org.qt-project.qtwidgets.5132 (auto-detected)
Linux vendors like Fedora usually divide library documentation in several RPM packages. You need to guess which ones you are interested and install them as needed. QtWidgets is probably packaged together with other modules in a qtbase package like this one (which is for Qt 5.12.3, but you seem to be developing with 5.13.2). Sorry, I don't have a Fedora installation at hand right now. Please try to search the available RPM packages yourself. Good luck!
I tend to not use the Qt packages provided by the Linux vendors. For me, it is much more convenient to use the qt online installers. You may install several releases side-by-side on your $HOME and you will get the full documentation and examples for each one. There are newer versions than the ones available on Fedora repositories. You may install v5.14.1 right now and try it on your software.
I ran into the issue (9/2022) as well and was able to do the following on Redhat 8 to install all documentation for qtcreator:
% sudo yum install qt5-doc
In pre-buildout-times one would install ZOPE2 by downloading the tarball of http://old.zope.org/Products/Zope/ and do the configure/make/install-procedure.
Since ZOPE version 2.12 releases are made on pypi. Would it still be possible to install newer ZOPE2-versions the same way manually without using buildout?
Perspectively Plone is ment to be put on top ZOPE2, but to narrow down the question for now, an answer only concerning ZOPE2 is very welcome.
I may be late to the party but:
As a starting point: There is the projects installation docs at https://zope.readthedocs.io/en/2.13/INSTALL-virtualenv.html which worked fine (and is without buildout) the last time I tried.
Since I use virtualenv and pip a lot, the above method becomes cumbersome fast (installation from different path than pypi and local equivalent, accidentally upgrading wrong packages when installing more packages) I made an almost pure reference installation and then just did a pip freeze > zope_2.13_requirements.txt.
Now I can just create a new virtualenv and do a quick pip install -r zope_2.13_requirements.txt, can do it directly via pipy and have a fresh installation whenever I need.
The main part of the question probably is that you probably want to use Zope 3 and not legacy Zope 2 (which e.g. Plone still depends on). Zope is not a signle, coherent, entity. What components of Zope stack you want to use (zope.interface, zope.component, ZODB, Medusa web server, Zope management interface, others?) All are individual Python packages and can be used as is in any Python application with normal Python package workflow.
Buildout is nothing but scripts, templates and Python package installer with advanced dependency solving.
You can still install all Zope packages by hand, resulting a lenghty requirements.txt. Zope 2 comes with command line scripts for creating and maintaining databases and you can call these scripts by hand, no need to go through buildout. You can also create configuration files by hand, e.g. looking the examples generated by buildout if you have some specific legacy project in mind.
For example, substanced, a CMS based on Pyramid and ZODB, does not rely on buildout. Pyramid internally uses zope.interface, zope.component and various other packakages.
I have made an application using QtWebKit, Qt4. I have the binary generated in Fedora 16. Now, I want to run that application on another PC (running some other Fedora version), where Qt is not installed. How can I package my Qt application so that it can run on a platform where Qt is not installed? Is there any command line utility as well as QtCreator utility to do so. I have tried "deploy all" command, but it didn't have any affect.
Create an Installer with the Qt Installer Framework and just supply all needed shared libraries (Win/OSX) or compile statically. Under Linux there is always the problem between system-wide libraries or bundled libraries. The documentation https://qt-project.org/doc/qt-5.0/qtdoc/deployment.html should give you a good start
Obviously, you need to have access to the qt libraries, which are exactly the same version that you used to compile your application.
There are two options :
link qt libraries statically
create a RPM package (see this how)
Also check Deploying Qt Applications.
Since you're deploying using rpm, to systems where Qt 4 rpms are available, you don't need to do anything besides simply adding a dependency on the qt to your rpm's specfile. The user installing your package using yum localinstall will get the Qt dependencies automatically installed. That's the correct way of doing it - it will keep your package size small.
Of course you need a separate rpm build for every fedora/centos major version out there, but that's almost always a requirement.
If your package needs newer Qt version than the one provided by the platform packages, you can still make a specific version dependency (say qt >= 4.7.0) and have a readme that indicates that newer packages can be obtained from a 3rd party repository (epel etc.)
For deployment under Linux I've used Bitrock Installer Tool.
The main thing before deploying is to check your dependencies. You can do that by using command:
ldd appName | grep libQt
After that you'll see list of dependencies. You'll have to set environment variable LD_LIBRARY_PATH to let linker know where're your libraries. To do that:
export LD_LIBRARY_PATH=.
. means current directory
And after that:
./appName $*
After that you'll be able to use your executable with Bitrock Installer Tool.
I use qt-creator 5.2 and install qwt6.1.0 on the mac os 10.9. I follow the guide,and install the qwt6.1.0 success.
I use these cmd:
cd $QwtDir
qmake -spec macx-g++
make
sudo make install
sudo ln -s /usr/local/qwt-6.1.0/lib/qwt.framework/qwt /usr/lib/qwt
But when I compile the program, It occurs this problem:
dyld: Library not loaded: qwt.framework/Versions/6/qwt
what should I do?
I finally found the Solution: Just copy the qwt.framework to the Libary/Frameworks Folder and everything should work from now. I was looking for like 3 Hours for finding the right solution after reinstalling everything etc. Hope this helps.
From the Mac Developer Library:
Third-party frameworks can go in a number of different file-system locations, depending on certain factors.
Most public frameworks should be installed at the local level in /Library/Frameworks.
If your framework should only be used by a single user, you can install it in the ~/Library/Frameworks subdirectory of the current user; however, this option should be avoided if possible.
If they are to be used across a local area network, they can be installed in /Network/Library/Frameworks; however, this option should be avoided if possible.
For nearly all cases, installing your frameworks in /Library/Frameworks is the best choice. Frameworks in this location are discovered automatically by the compiler at compile time and the dynamic linker at runtime. Applications that link to frameworks in other directories, such as ~/Library/Frameworks or /Network/Library/Frameworks, must specify the exact path to the framework at build time so that the dynamic linker can find it. If the path changes (as it might for a user home directory), the dynamic linker may be unable to find the framework.