I've developed an application for GNU/Linux that uses the OpenSSL library. This application is supposed to run in both Debian and Red Hat-based distributions.
What is the best strategy to ensure the user's system will have the OpenSSL library installed? Should I include a dependency on the .deb or .rpm for a specific version of the OpenSSL? How can I handle systems with older versions of OpenSSL, such as 0.9.8, and newer ones with 1.0.0? Or is it best to statically link it?
Thank you
Ubuntu uses Debian packages (.deb), RedHat uses RPM. You will have to create two different spec files to build packages for these two distributions, at least.
When you dynamically link against different versions of the library, you should really build several versions of your executable as well. Usually, the .so API is only guaranteed to stay the same for a major version. I.e. 0.9.4 will be compatible to 0.9.9, but not 1.0.1.
Related
The PostgreSQL used to provide EDB package for Linux x86_64 till version 10.15 like postgresql-10.15-1-linux-x64-binaries.tar.gz.
Now we want to upgrade PostgreSQL to version 13.1 and EDB package for it is not available.
Hence we want to create the package our own using documentation link. But we are able to compile package but it is not including all required files such and header and libs for SSL, tar.
How to generate a complete relocatable package like postgresql-10.15-1-linux-x64-binaries.tar to run PostgreSQL as standalone software on RHEL6/7/8 SUSE, SLES12/15 Linux versions.
or
Are there any special instructions to generate PostgreSQL 13.1 package like postgresql-10.15-1-linux-x64-binaries.tar?
I recommend that you use the PGDG packages.
Building from source is of course also an option, but I recommend that you do not try to create standalone binary packages. The proper way for that would be linking the software statically, which is not supported by the build process and would require you to have static libraries for all referenced software.
You could attempt to add all linked shared libraries to the software distribution, but you would have to make sure that these libraries are used instead of the ones on the default shared library path, which is difficult.
It seems to me that you are trying to re-invent the wheel here, and the wheel in this case is a docker container. Use that and stop worrying.
For easy deployment, I'd like to ship an installation of Postgres as part of the application. Is it possible to include an already compiled and runnable version of Postgres that can be launched as process? I was able to do such thing with a Windows and MacOS version, but haven't found anything about Linux on that matter yet. Perhaps someone has tried this before and can share some insights...
You haven't stated what linux OS you're using.
Assuming it's a Redhat variant why not package your application as an RPM package? You could then declare a dependency on the standard Postgres package which would be automatically installed yum. Same principle applies if you're using Debian based systems, just a different packaging format.
From the user's perspective the OS's native packaging format is always the easiest way to install your application. Just requires effort to package it properly.
You can find cross-platform binaries from these pages on PostgreSQL official website:
For easy GUI .run installers, use links provided at http://www.enterprisedb.com/products-services-training/pgdownload.
If your target machine has no X installed on it, or you want to automate installation process with shell scripts, then you can download RPM or Deb packages from http://community.openscg.com/se/postgresql/packages.jsp
I found these links on http://www.postgresql.org/download/linux/ubuntu/, under "Cross distribution packages" and "Graphical installer".
I quote from those pages:
Note: The cross distribution packages do not fully integrate with the platform-specific packaging systems.
You must have root priviliges to install these packages, however, none of your systems library files will be altered. The supporting libraries that these binaries require are included locally as part of the install. This is the "special sauce" that allows identical binaries to run on different linux distro's.
I have a set of programs for analyzing radiation data and I want to build packages for Red Hat Linux versions 4.x - 6.x. Is it possible to build these packages on a single build server running a single version of Red Hat Linux or do I need to build the version 4.x package on a server running version 4.x and the version 5.x package on a server running version 5.x?
If I can build packages for several versions on a single server, must that server be running the newest version or the oldest version of the OS?
You need to build toolchain for different OS environments (toolchain for Redhat 4.x and 5.x) and with in toolchain you can build packages for specific OS. toolchain is like a chroot environments.
You can create multiple Virtual machine using KVM and build many version of packages using single node..
You can use UML (User Mode Linux) which is quite interesting... Check out following Link
http://uml.devloop.org.uk/howto.html
You can build your packages in a chroot jail. You can use mach to do so.
Here's a tutorial on building packages with mach you could refer to, though it may be outdated.
A C program compiled here runs fine on our Ubuntu servers. But when a somebody else tries to run it on their particular Linux server they get the following errors:
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./myprog-install)
./myprog-install: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./myprog-install)
Do I need to upgrade our glibc libraries and recompile? Or are they missing something on their server?
If I run apt-cache show libc6 my Ubuntu tells me the version is:
Package: libc6
Priority: required
Section: libs
Installed-Size: 9368
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss#lists.ubuntu.com>
Original-Maintainer: GNU Libc Maintainers <debian-glibc#lists.debian.org>
Architecture: i386
Source: eglibc
Version: 2.11.1-0ubuntu7.10
If I look at http://packages.ubuntu.com/hardy/libc6 the current version appears to be 2.7-10ubuntu8.1.
I'm confused by the numbers. On the one hand 2.11-1-0 is a higher number than 2.7-11. On the other hand 7.10 is a lower number than 8.1.
Is it just a matter of me upgrading the C library package and recompiling do you think? Or is the other person's server missing some needed library there for compatibility?
You have built on glibc-2.11 system. You are trying to run on a system with glibc-2.3 or older. That's not going to work.
Is it just a matter of me upgrading the C library package
No: upgrading your glibc will only make things worse.
You may want to try solutions listed here.
Is this something we can reasonably request the other party to upgrade their system to support, rather than downgrade our compiler?
Usually the client will strongly resist requests to upgrade their system: it's working fine for them as is, and any upgrade can break other existing applications.
If you are planning to distribute binaries on Linux (as opposed to building them on the target system), then you need to learn how to make binaries that will run everywhere, or you need to state your requirements (minimum kernel and libc versions, etc.) and turn clients who can't meet these requirements away.
Update:
Why did they get two errors. Why didn't they just get one for GLIBC_2.11.1 which is apparently what I built with?
Symbol versioning doesn't work that way.
When a new symbol is introduced, it is marked with the current libc version, e.g. readdir64##GLIBC_2.2, posix_spawn##GLIBC_2.15, etc.
When you link a program that uses both of the above symbols, and try to run it on e.g. glibc-2.1 system, you would get two errors.
But if you link a program that doesn't use any of the above symbols, e.g.
int main() { return 0; }
then your program will just run without any errors.
Update 2:
they don't have to add both GLIBC_2.4 and GLIBC2.7 to their Linux system, do they?
No, they don't. The GLIBC_2.11 will have all the previous symbols in it. In fact, they couldn't install both glibc-2.4 and 2.7 even if they wanted to: it is quite difficult to have multiple versions installed at the same time, and impossible to have multiple versions installed in default location.
You've built it against a version of glibc that is too new. Build it against an older version of glibc, preferably the one that they are using.
you need to build on a system that uses same versions of libraries as you do. This is where docker and VM's are very convenient. There is probably a pre-made docker image for whatever version the customer has.
I'm attempting to build a binary package that can be run on multiple Linux distributions. It's currently built on Ubuntu 10.04, but it fails on Ubuntu 8.04 with the following error:
./test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./test)
./test: /usr/lib/libstdc.so.6: version `GLIBC_2.11' not found (required by ./test)
What's the preferred way to solve this problem? Is there a way to install an old glibc on a new box and build against it, or do I have to build on an old distribution? And if I build against an old glibc, will it work on a new glibc?
Or, alternatively, are there just some handy compiler flags or packages I could install to solve the problem?
The best solution I've found is to install a virtual machine running Debian stable, and build on that. Debian stable is old enough that any packages built with it will run on any other Debian-based distribution like Ubuntu. You may have to work around non-critical bugs that have been fixed in later versions of various software but not backported to Debian stable.
If you really want to make sure it runs on every recent distribution, you might also consider statically linking against a libC you select. However you may then still run into problems if you use features that are only provided by newer kernels (newer system calls e.g.).