I was trying to build OpenSSL-1.0.1e for RHEL5 platform.
I got few file not found errors from rpmbuild, after further analysis i found that package builder was searching for libssl.so.10 and libcrypto.so.10. But, the actual files created were libssl.so.6 and libcrypto.so.6.
So, i have replaced the soversion macro with 6 instead of 10.
The package building was successful.
Is there any issues replacing the library version number for latest openssl with 6 instead of 10 in RHEL5 platform ?
If any interfaces have been removed going from .6 to .10, it is very possible that it breaks applications requiring a symbol that existed in the actual .6 but not in your .10 renamed to .6. Read [1] for more information about sonames.
In any case, this is definitely bad practice and should be avoided. If you have an application which requires a newer version of OpenSSL than what comes with RHEL5, I'd rather just bundle the newer libraries with your application and use LD_LIBRARY_PATH to have the directory containing the bundled libraries be searched before the system directores.
[1] http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Related
I have freetype2 installed on my system but I am also trying to install it from source, as well.
My installed version is here: /usr/lib64/pkgconfig/freetype2.pc. That file is listed as version 20.0.14.
To compile another tool, namely fontconfig, I need freetype2 >= 21.0.15.
So I downloaded freetype2 from its source git repo.
The trouble I'm having is that repository doesn't list any version even close to 21.0.15+. All of the tags in that repository are listed as VER-2-6-2, VER-2-9, VER-2-9-1, etc. And the generated freetype.pc file which is created after compilation are also listed as 2.6.2, 2.9, 2.9.1, etc. The version number is not 21.0.15 or even 20.0.14, which my CentOS 7.6 already has.
What determines the listed version in the freetype.pc file? Where can I find the version of freetype that will create a .pc file of >= 21.0.15+? Any clarification would be greatly appreciated.
Apparently the reason is because I was building freetype using CMake. And in the CMakeLists.txt, it's defining a version based on the version of freetype.
# . `CMakeLists.txt' is provided as-is since it is normally not used by the
# developer team.
So it's unsupported. That's why the version number doesn't match.
In reality, the version number actually comes from libtool. See this table. e.g. I was building 2.10.0 freetype, so the freetype.pc should have been written with a version of 23.0.17
And if you build using configure, instead of cmake, you can find that exact same version 23.0.17 listed as "23:0:17" in the builds/unix/configure.raw file.
I am running stack Version 2.1.3, x86_64 hpack-0.31.2 on cygwin. A Haskell project that I am trying to build requires the use of regex-pcre-0.94.4 which in turn requires the pcre library. The exact message I get is:
$ stack build
regex-pcre> configure
regex-pcre> Configuring regex-pcre-0.94.4...
regex-pcre> Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe: Missing dependency
on a foreign library:
regex-pcre> * Missing C library: pcre
regex-pcre> This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is already
installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
There does not seem to be an easy way of obtaining a relatively recent version of pcre binaries for Windows (the ones at http://gnuwin32.sourceforge.net/packages/pcre.htm are too old for my purposes). There is a video showing how to build the binaries from source but before I go that route, there are some relatively recent precompiled binaries available at https://github.com/dragokas/PCRE but I have no idea what to do with them or where to place them. This is beginning to look like a lot of work that I am wondering if its worth it or I should just drop the idea of doing it in Windows and move to Linux. Any ideas or suggestions?
PS. I also notice that cygwin already has a pcre library (/bin/cygpcre2-16-0.dll). but as this looks like a 16-bit library I assume it won't work, and again I am not sure how to tell stack to use this.
Here I found the answer:
regex-pcre doesn't support Windows, at least the current
regex-pcre.cabal doesn't work well on Windows.
Try regex-pcre-builtin, it's the same as regex-pcre, but with
PCRE sources bundled in. I don't know why the author doesn't merge it
into regex-pcre, but creating a new package for this.
I had to change only name regex-pcre to regex-pcre-builtin (as versioning is the same) in my .cabal file that installs dependencies with stack build. (example: ./your-project-name.cabal)
I am trying to build a program as most others available on linux:
configure, make, make install.
However when I try to configure it I get the following message:
checking for gtk-config... no
checking for GTK - version >= 1.2.0... no
*** The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: error: Cannot find GTK: Is gtk-config in path?
I have got gtk 2.x on the host machine. And when I run which and locate on gtk-config I get nothing back. Since I have the source what patches can I apply to fix this?
You need to install the development files for GTK 1.2; the name of the package depends on your distribution.
I'd like to warn you, though, that GTK 1.2 was last released 15 years ago, in 2001, and hasn't been updated since — which also implies that the application you're trying to build is also hopelessly outdated.
GTK+ 2.0.0 was also released in 2001 and it's currently in deep maintenance mode (the latest version is 2.24.29 and was released in 2015); GTK+ 3.0.0 was released in 2011, and it's the currently developed version of the API.
You cannot really apply patches to compile an application written with the GTK 1.x API using any newer major versions of GTK+ (e.g. 2.x or 3.x); each time the major version of GTK is bumped, the API is changed in a non-compatible way. You would need to port the application to the new API.
Additionally, if an application depends on GTK 1.x it's also likely that it will depend on older versions of existing libraries; or deprecated ones. You will need to find all the dependencies and ensure that they can be installed in parallel with the ones you have installed in your system.
You could try using the compatibility wrappers developed by OpenSUSE team that try to emulate GTK1.2 by some wrappers and/or automatically patching source code to be compiled, to be able to use GTK2.0 instead.
Have a look at https://github.com/openSUSE/gtk1-compat - perhaps it may work for you. I didn't test it, however, myself.
The release notes for RedHawk 2.0 say that the GPP device previously written in Python has been replaced with one written in "Written in C++, so it is more responsive". But I find it still running in Python (according to ps command python is running GPP.py, and the $SDRROOT/dev/devices/GPP/GPP.spd.xml which also has softpkg version="1.10.0". Was my installation defective and I still have parts of the 1.10 runtime system? My IDE says 2.0.
It sounds like REDHAWK 2.0 was not properly installed on your system, the IDE and the framework/assets are separate and it is possible to get into a situation with conflicting versions depending on the installation steps taken.
Determining what version of REDHAWK you have installed can be determined in a handful of ways. If you installed via yum or rpm you can check the versions of the rpms installed with:
rpm -qa | grep -i redhawk
The redhawk package, and redhawk-ide package should both be at 2.0. Note that the REDHAWK assets are versioned independently.
If you installed via source, you can use the package config files to obtain version information. The framework keeps it's pc files in $OSSIEHOME/lib64/pkgconfig:
cat $OSSIEHOME/lib64/pkgconfig/ossie.pc
Will print out version information for the core framework installed. Depending on what is installed, there are pc files for the framework, bulkio, frontend, and burstio.
I am sorry. The GPP-2.0.0-3.el6.x86_64 DOES contain an ELF executable for GPP device. But the rpm does not install unless I manually erase the GPP-1.10 pkg. Until erased yum says "nothing to do" for some reason. I saw the source code in GPP-debuginfo but did not notice the executable in GPP-2.0.0 since it was all caps and looked like the directory.
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.