We have Matlab R2017a installed on a RHEL 7.3 machine and I can provide verbose installation instructions if necessary. We have the Matlab library paths saved in /etc/ld.so.conf.d/matlab.conf and have run ldconfig to make sure the paths get picked up. Matlab works and everything is functional. However, Matlab seems to come bundled with it's own versions of libraries such as libstdc++, libicui18n, and others.
I'm trying to build and link a non-Matlab executable with the two libraries mentioned above and it's linking against Matlab's and not the system. How can I tell the linker to use the system provided libraries? I'm pretty sure this isn't a Matlab-specific problem, but that happens to be the environment I'm working in. Any thoughts would be greatly appreciated.
Here is what our /etc/ld.so.conf.d/matlab.conf file looks like. Based on some testing, it does look like all three of these are necessary.
/opt/MATLAB/R2017a/bin/glnxa64
/opt/MATLAB/R2017a/runtime/glnxa64
/opt/MATLAB/2017a/sys/os/glnxa64
There are libraries installed in the runtime that depend on libraries installed in sys/os. The libraries in sys/os are the ones conflicting with the RHEL system libraries (such as libstdc++).
Related
I started to learn wxWidgets some days ago and I found it really good, but when I tried to "export" it to another platform, it didn't work. I expected that, but when I searched how to distribute wxWidgets apps, I didn't find that much, except to install all the wxWidgets library on that platform.
I use Debian 10, while the other platform where I need to export my app uses Lubuntu. It says that it needs a wxgtk3.0 library, but I guess that library will need even more libraries.
How do I export my wxWidgets application without asking the user to manually install and build all the library on its platform? Maybe even using .deb package (if really needed). Thanks in advance.
Please understand that every single distribution uses it own format comparing to Windows where there is an Installation Wizard or OSX where there is a Bundle.
Now, you can create a deb file where you set everything up.
So you can create an rpm (which is basically the same thing as deb, just for different distribution).
This is the best way as it ensures that all dependencies and their versions are satisfied.
Hope this helps!
Many Linux distributions have wxWidgets packages, so one possibility would be to simply ask users to install these packages when they need to use your application. This is not really different from installing GTK libraries or even X11 (or Wayland) that your application also depends on -- the only difference is that these libraries are almost surely already installed on any Linux desktop system, while wxWidgets ones might not be.
Another alternative is to link your application statically with wxWidgets libraries. This will make it much bigger and will prevent the users from upgrading the libraries on their system to improve the application behaviour, but can be simpler for the users to install. Note that if you choose the static linking route, you typically need to build your application on the oldest distribution you want to support (which is probably not Debian 10, which is relatively recent), as this is a simple way to ensure that it doesn't require newer versions of the (other, non-wx) libraries than the ones already present on the user's system.
I'm working on a project, which targets both Windows and Linux (and possible in the future MacOS). It consists of some applications with several shared libraries. It is written in modern C++ and modern CMake. It also uses 3rd-party libraries like Qt, OpenCV, Boost, GraphicsMagick, samplerate, sndfile. Those dependencies are handled through Conan package manager. I'm building both on Linux (Ubuntu 18.04, GCC 8.1) and Windows (via WSL - also Ubuntu 18.04, MinGW-w64 8.1). I'm using fairly recent versions of 3rd-party libraries with custom built options (strictly speaking - different versions than available on Ubuntu's APT, e.g. Qt v5.11.3, or custom built of GraphicsMagick)
I'm using CPack. On Windows I'm building NSIS installer, but on Linux I would like to use DEB generator (may be other if needed). All of my targets (written apps and shared libs) have appropriate CMake's INSTALL configurations, so they are copied correctly into the generated installers (component based installation). The real problem comes with packaging of 3rd-party dependencies.
Problem
Strictly speaking, I have no idea, how to do it well using CMake+CPack+Conan, both on Linux and Windows. I've read a lot of articles and posts, but I'm stucked. I would like to have something, that automatically bundles into the installer all 3rd party libraries used by project with needed plugins and, what is the most important, with needed system/compiler libraries (libgomp, libstdc++ and so on).
Possible solution
To my surprise, on Windows, this task is fairly easy, because every DLL used by app (my libs, 3rd-party libs and system/compiler libs) needs to be located where executable is. I'm engaging Conan into this, by importing all used DLLs into bin directory. In the end, in most naive way of packaging, I will just copy the bin directory into the installer and it should work. But I'm not sure, if this approach is OK.
On Linux, things are more complicated. First, there is arleady a package manager. Unfortunately, libraries/compilers available there are too old for me (e.g. on APT there is only Qt 5.9.6 ) and are built using different compile options. So, the only way for me is to ship them with my software (like in Windows). There are also issues with searching for dynamic libraries by ld, RPATH handling and so on. At the moment, the only solution I see is to write something like 'launcher' for my app, which sets LD_LIBRARY_PATH before program starts. After that, in this case we can just copy bin or lib directory to the DEB installer and this should work. But still, I don't know if this is correct approach.
Other solutions
I've also looked into other solutions. One of them was BundleUtilities from CMake. It doesn't work for me. It has a lot of problems in recognizing, whether some library is system or local one. Especially in WSL, where it stucked in processing dependencies to USER32.dll, KERNEL32.dll. BundleUtilities in Windows worked for me only with MSYS, but in MSYS I've failed to compile some 3rd-party libraries (GraphicsMagicks via Conan) and that's the reason, why I'm using WSL.
Summary
I'm looking for good and verified method of packaging C++ projects with multiple apps, libs and shipped 3rd-party libs, both for Windows and Linux. How are you doing things like this? Are you just copying bin and/or lib dirs to the installers? How (in terms of CMake/CPack code) are you doing that? INSTALL(DIRECTORY ...), or similar? I'm not sure, but I think that this problem should be already solved in the industry. ;)
Thanks for all suggestions.
First, Conan is a package manager for development, not for distribution, that's why you didn't find an easy way to solve your problem. Second, most of discussions are made at Conan issue, including bugs and questions. There you will find a big community + Conan devs which are very helpful.
with needed system/compiler libraries
This is not part of Conan. Why you don't use static linkage for system libraries?
Talking about CPack, we have an open discussion about it usage with Conan: https://github.com/conan-io/conan/issues/5655
Please, join us.
I see few options for your case:
on package method, run self.copy and all dependencies from self.cpp_deps, which includes all libraries, so you can run Cpack
Use Conan deploy generator to deploy all artifacts, and using a hook you can run cpack or any other installer tool
Out friend SSE4 is writing a new blog post about Deployment + Conan, I think it can help you a lot. You can read a preview here.
Regards!
I'm currently working on a Linux project. This project needs to run under every Linux distribution (without installing any package/libraries/others for the clients) and it's a bit hard to do it well.
I already tried to do it myself, see this, i have also tried to use CDE but it didn't work well since i got an error with some distribution. For example:
Ubuntu 8.04: Impossible to read the header ELF
Debian 7.8: version of GLIBC_2.14 not found
So, i would like to know if there is a way to get a package of my program who can run under every Linux distribution.
Thanks
Edit: I would like to avoid the static compilation, since my program is pretty big.
There are big differences between linux distributions, especially version of libraries and package management system.
The only way how to do it is to build/compile your project against all libraries you need to use statically, and distribute them with your project.
For example skype and ejabberd do it this way.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
I have a little application running on Linux and want to port it to Windows. I found that with Cygwin i will be able to do it simple by linking the application with the cygwin1.dll library which make available a lot of the POSIX and other standard functions. I read the FAQ and the User Guide on the site of Cygwin but didn't find or didn't understand how can I link my source with this library.
My application uses GTK+ and I successfully compiled and link it on Windows with MinGW but I have to disable some of the functionality .Now that I find Cygwin I would like to link with it to make available again this functionality.
Generally you compile your source inside of Cygwin to produce the Windows binary. I'm pretty sure Cygwin will take care of linking to the proper dlls for you.
When you finally get the binary compiled, make sure that the cygwin1.dll is in the PATH specified by Windows.