Good day! I've got a problem with linkage on Linux using gcc. For example, I've compiled project on one machine and linked it with libGLEW. When I'm trying to run it on another machine - it can't find libGLEW, because first machine has libGLEW.so.1.7 and second has libGLEW.so.1.10.
ldd shows me, that it dependent on 'libGLEW.so.1.7'.
after creating symlink 'libGLEW.so.1.7 => libGLEW.so.1.10' everything works fine, but is there a way, to store 'libGLEW.so' as dependency instead of 'libGLEW.so.1.7'?
What makes you sure the function interface of GLEW doesn't have changed?
Or even the content of version 1.1 to 1.7 is still the same?
If it is build with 1.7, it also depends on 1.7.
So you shouldn't run it on another version of GLEW, except the api documentation of GLEW tells you that this cross versioning is possible for some reason (But I couldn't imagine that).
Otherwise also build it with GLEW 1.1 in addition
(because as if all features you use from 1.7 are also supported by 1.1 and for some reason you have to support both versions), so to serve different versions fo your programm for different versions of GLEW would be the best and valid way.
If that is not the case make it for the user as requirement to be on Glew version 1.7 or higher.
But there is no safe way of working around to archive what you want.
And there is not a gcc or any compiler command for that at all.
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 am compiling a product under Debian 7.5. During compiling using makefile, I incur in an error :
undefined reference to `memcpy#GLIBC_2.14'
In my system it is installed libc6_2.13.
I am aware that that component cannot be upgraded painlessly, but I'd like to understand if I can have the 2.14 concurrent with it just for this task, then I won't need it anymore. I have looked for a solution since yesterday, but i am wandering.
I need to understand if it is possible or not to use GLIBC 2.14 on my linux version just for a one shot compiling, without damaging it, or if I can
Notes: I cannot change system distro.
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 am building a redistrbutable .so file.
However when my users try to use it they get the dreaded /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.9' not found error.
Doing an objdump, it seems its this particular symbol in my binary that is causing the issue:
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l##GLIBCXX_3.4.9
How do i tell my gcc/g++ to compile/link against an older version of GLIBXX so that my users dont get this error?
Or is the only way out of this conundrum to install a separate older version of linux which has an GLIBXX?
How do i tell my gcc/g++ to compile/link against an older version of GLIBXX so that my users dont get this error?
There is no way to do that. Your only choices are:
build with older g++ version, or
link libstdc++.a statically into your shared library, and hide its symbols (this may also have licensing implications, check with your lawyer).
package your version of libstdc++.so.6 together with your library, and ask users who have an older version to arrange to pick up your newer version instead (also has licensing implications, but I believe these are easier to satisfy).
You are building for GLIBCXX_3.4.9, hence your users also need to have at least GLIBCXX_3.4.9.
I have built a static version of qt and download a static version of glibc. Now I would like to link glibc statically to my qt application. I know about going into the .pro and adding the line LIBS += -L path/to/static_lib but I am wondering if these that is enough? Will it still link glibc statically even though the OS I am building on has the dynamic libraries also? The reason I am doing this is to deploy the application in a standalone manner. (After installing and updating Red Hat 5.3 glibc_2.9 was not found on the target computer)
Passing -static to gcc will force it to link statically when possible.
Alternatively, download and install CentOS 5 and build on that.
As you discovered, linking fully statically with glibc is not possible, because for instance nss support is loaded dynamically.
However, the required glibc version depends mostly on the features you actually use.
Anyway, I think you should instead use Linux Standard Base, also
because of reasons exposed here.