We are building rpm for openssl 1.0.1g for Redhat5.9 and Redhat 6.4
Steps followed:-
1-Download the openssl 1.0.1 g tar file
2-Created the following dir structure
/myrpm/BUILD
/rpm/SOURCES
/rpm/SPECS/
/rpm/RPMS
3-./config
4-make
5-make install
Our goals:-
-We need to change the soname and realname of the library and link it properly
-We also need fips enabled with openssl.
-Include these changed sonames to our rpm while rpmbuild
Currently the
soname creates as libbssl.so and libcrypto.so
real name as libssl.so.1.0.0 and libcrypto.so.1.0.0
But we required in following formats :-
soname ->libbssl.so.10 and libcrypto.so.10
realname ->libssl.so.1.0.1g and libcrypto.so.1.0.1g
It was not properly linking the sonames with realnames and not including these libraries in the rpm while building through rpmbuild command.
We have changed the Makefile and Makefile.shared but we need some options in openssl.spec file which create and link the soname and realname and also include these libraries in our rpm as mentioned above.
Any help on this will be appreciated.
Thanks,
#PP
Related
I am trying to install opendkim on amazon linux ec2 instance. When compiling from source I get:
configure: error: no strlcpy/strlcat found
so I installed libbsd from source. once that is installed I can go to the man page of strlcat and strlcpy but I can't access those functions. I verified that the shared libraries are installed. The output of the libbsd install stated to use one of the 4 options:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
I ran
export LD_RUN_PATH=/usr/local/lib
export LD_LIBRARY_PATH=/usr/local/lib/
Additionally my /etc/ld.so.conf contains
include ld.so.conf.d/*.conf
and my /etc/ld.so.conf.d/libbsd.conf contains
/usr/local/lib/libbsd
Lastly checking my libbsd library nm -D /usr/local/lib/libbsd.so contains:
000000000000de30 T strlcat
000000000000ded0 T strlcpy
So my questions how do I either, expose strlcat and strlcpy to the command line? Or how to I do the "use the `-Wl,-rpath -Wl,LIBDIR' linker flag" option, or in general what am i doing wrong in linking to shared libraries? Any help is appreciated. Thanks!
So wasn't ever able to link against the libraries but I was able to resolve the dependencies. The binary rpm from centos installed perfectly :
sudo wget http://dl.fedoraproject.org/pub/epel/7/x86_64/l/libbsd-0.6.0-3.el7.x86_64.rpm
sudo yum localinstall ./libbsd-0.6.0-3.el7.x86_64.rpm
sudo wget http://dl.fedoraproject.org/pub/epel/7/x86_64/l/libbsd-devel-0.6.0-3.el7.x86_64.rpm
sudo yum localinstall ./libbsd-devel-0.6.0-3.el7.x86_64.rpm
when i try to execute the Linux executable on other fresh machine my program gives an error for dependency of OpenSSL.
For running my program smoothly it requires libssl.so and libcrypto.so preloaded.
How can i remove this dependency using make file or any other solution on Linux
It seems that you linked your executable with OpenSSL libraries dynamically. So your executable needs libcrypto.so and libssl.so. You have two ways:
OpenSSL is pretty widely distributed in Linux environment and most probably is pre-installed on the Linux you are running your executable on. So the problem may be in the required version of the libraries - your executable may be compiled with e.g. OpenSSL 1.0.1 and Linus has 0.9.8. Or the problem could be with the path of the libraries. In RadHat OpenSSL libraries are in /lib64 by default. So you need either to build your application with the same or compatible version of OpenSSL as present on Linux where you run or provide the correct path by setting LD_LIBRARY_PATH
You can link your executable static with OpenSSL libraries:
gcc -lsome_dynamic_lib code.c libcrypto.a libssl.a
I have Ubuntu 14.04. It came with openssl 1.0.1f. I want to install another openssl version (1.0.2) and I want to compile it by myself.
I configure it as follows:
LDFLAGS='-Wl,--export-dynamic -L/home/myhome/programs/openssl/i/lib
-L/home/myhome/programs/zlib/i/lib'
CPPFLAGS='-I/home/myhome/programs/openssl/i/include
-I/home/myhome/programs/zlib/i/include'
./config --prefix=/home/myhome/programs/openssl/i \
zlib-dynamic shared --with-zlib-lib=/home/myhome/programs/zlib/i/lib \
--with-zlib-include=/home/myhome/programs/zlib/i/include
make
make install
After install, when i check the binary with ldd openssl, and the result is:
...
libssl.so.1.0.0 => /home/myhome/programs/openssl/i/lib/libssl.so.1.0.0 (0x00007f91138c0000)
libcrypto.so.1.0.0 => /home/myhome/programs/openssl/i/lib/libcrypto.so.1.0.0 (0x00007f9113479000)
...
which looks fine. But when I check ldd libssl.so, the result is:
...
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fac70930000)
...
It still uses the system version of libcrypto. I tried different ways to
build, but result is always stays the same.
My question is how to configure the build in a way, that it can hardcode all binary and library dependencies of shared libraries without using LD_LIBRARY_PATH, or anything like that.
My question is how to configure the build in a way, that it can hardcode all binary and library dependencies of shared libraries without using LD_LIBRARY_PATH, or anything like that.
OpenSSL supports RPATH's out of the box for BSD targets (but not others). From Configure:
# Unlike other OSes (like Solaris, Linux, Tru64, IRIX) BSD run-time
# linkers (tested OpenBSD, NetBSD and FreeBSD) "demand" RPATH set on
# .so objects. Apparently application RPATH is not global and does
# not apply to .so linked with other .so. Problem manifests itself
# when libssl.so fails to load libcrypto.so. One can argue that we
# should engrave this into Makefile.shared rules or into BSD-* config
# lines above. Meanwhile let's try to be cautious and pass -rpath to
# linker only when --prefix is not /usr.
if ($target =~ /^BSD\-/)
{
$shared_ldflag.=" -Wl,-rpath,\$(LIBRPATH)" if ($prefix !~ m|^/usr[/]*$|);
}
The easiest way to do it for OpenSSL 1.0.2 appears to be add it as a CFLAG:
./config -Wl,-rpath=/usr/local/ssl/lib
The next easiest way to do it for OpenSSL 1.0.2 appears to be add a Configure line and hard code the rpath. For example, I am working on Debian x86_64. So I opened the file Configure in an editor, copied linux-x86_64, named it linux-x86_64-rpath, and made the following change to add the -rpath option:
"linux-x86_64-rpath", "gcc:-m64 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl/lib::
-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib -ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:
${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
Above, fields 2 and 6 were changed. They correspond to $cflag and $ldflag in OpenSSL's builds system.
Then, Configure with the new configuration:
$ ./Configure linux-x86_64-rpath shared no-ssl2 no-ssl3 no-comp \
--openssldir=/usr/local/ssl enable-ec_nistp_64_gcc_128
Finally, after make, verify the settings stuck:
$ readelf -d ./libssl.so | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
$ readelf -d ./libcrypto.so | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
$ readelf -d ./apps/openssl | grep -i rpath
0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
Once you perform make install, then ldd will produce expected results:
$ ldd /usr/local/ssl/lib/libssl.so
linux-vdso.so.1 => (0x00007ffceff6c000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007ff5eff96000)
...
$ ldd /usr/local/ssl/bin/openssl
linux-vdso.so.1 => (0x00007ffc30d3a000)
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f9e8372e000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f9e832c0000)
...
OpenSSL has a Compilation and Installation on its wiki. This has now been added to the wiki at Compilation and Installation | Using RPATHs
It's 2019, and OpenSSL might have changed a little, so I'll describe how I solved this, on the odd chance someone else might find it useful (and in case I ever need to figure out this command line argument again for myself).
I wanted to build OpenSSL in a way that would cross-compile (using docker containers, because I'm dealing with freakishly old Linux kernels yet modern compilers), yet provide an install that did not depend upon absolute paths, as would be the case using rpath as I've seen described in jww's answer here.
I found I can run OpenSSL's Configure script in this way to achieve what I want (from a bash prompt):
./Configure linux-x86 zlib shared -Wl,-rpath=\\\$\$ORIGIN/../lib
This causes the generated Makefile to build the executables and the shared objects in a way that makes the loader look for dependencies first in "./../lib" (relative to the location of the executable or the shared object), then in the LD_LIBRARY_PATH, etc. That wacky combination of characters properly gets past the bash command line, the script, and the Makefile combinations to create the -rpath argument according to how the linker requires it ($ORIGIN/../lib).
(Obviously, choose the other options that make sense to you.. the key here is in the -Wl,-rpath=\\\$\$ORIGIN/../lib option).
So, if I called ./Configure with a prefix of '--prefix=/opt/spiffness', and later decided to rename 'spiffness' to 'guttersnipe', everything will still work correctly, since the paths are relative rather than absolute.
I have not tried passing the argument into ./config to see if it works there since my use case was a bit special, but I suspect it would. If I were not attempting to cross-compile with dockerized containers, I would prefer using ./config to ./Configure, as it does a decent enough job of examining the current environment to see what kind of binaries to create.
I hope this is useful.
On linux can we repackage a installed rpm if so how.I remember that the a rpm can be generated from the installed binaries
rpm -??? > my.rpm
Also the later i.e, the newer rpm should work on a different machine
There is also rpmrebuild
http://rpmrebuild.sourceforge.net
Actually there is a simple but "tricky" way; it is just : rpm -e --repackage package-name
It will output the RPM in /var/spool/repackage/.
Example:
# rpm -e --repackage samba3x-client
# file /var/spool/repackage/samba3x-client-3.5.4-0.83.el5_7.2.i386.rpm
/var/spool/repackage/samba3x-client-3.5.4-0.83.el5_7.2.i386.rpm: RPM v3 bin i386 samba3x-client-3.5.4-0.83.el5_7
Why tricky? Because it actually remove the program prior packaging it, just so you know.
This is possible, but not with the rpm command. I wrote a perl script that does this; it crafts a spec file based on the outputs of rpm -q and does a "build" which just copies the installed files from the system.
You can find it here: https://github.com/cormander/rogue-beret-tools/blob/master/scripts/rpm-repack
Usage example, re-packaging the mailx rpm:
Query it:
$ rpm -ql mailx
/bin/mail
/etc/mail.rc
/usr/bin/Mail
/usr/lib/mail.help
/usr/lib/mail.tildehelp
/usr/share/man/man1/Mail.1.gz
/usr/share/man/man1/mail.1.gz
Repack it:
$ ./rpm-repack -p mailx
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.9773
+ umask 022
+ cd /usr/src/redhat/BUILD
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
Processing files: mailx-8.1.1-44.2.2
Provides: mailx
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) rtld(GNU_HASH)
Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/tlkN4yrYEi
Wrote: ~/rpmbuild/RPMS/i386/mailx-8.1.1-44.2.2.i386.rpm
Query the newly built package:
$ rpm -qpl ~/rpmbuild/RPMS/i386/mailx-8.1.1-44.2.2.i386.rpm
/bin/mail
/etc/mail.rc
/usr/bin/Mail
/usr/lib/mail.help
/usr/lib/mail.tildehelp
/usr/share/man/man1/Mail.1.gz
/usr/share/man/man1/mail.1.gz
The code isn't at all elegant, but functional. It does copy a lot of the rpm info (everything from rpm -qi and most of the scripts), but it isn't by any means comprehensive. Also, it can't copy the GPG signature, nor will it have the same checksums as the original RPM file.
NOTE: This is not a "proper" way to build and distribute RPM packages, and was mainly written for troubleshooting and educational purposes.
I think that most rpm based distributions how have official package rpmrebuild (or in the almost official 3'rd party repos like epel, rpmfusion ... etc). I think nowadays this would be your best option for repackaging installed packages.
rpmbuild generates RPM under which directory?
I checked the RPMS directory:-
[root#tom adil]# ls /usr/src/redhat/
BUILD RPMS SOURCES SPECS SRPMS
[root#tom adil]# ls /usr/src/redhat/RPMS/
athlon i386 i486 i586 i686 noarch
[root#tom adil]#
How to decide rpmbuild outputs in which of the above sub-directories?
Is it controlled by spec file? What is the default option?
I thought uname -p but its not the case probable uname -i is used.
Linked to my last question Difference between "machine hardware" and "hardware platform"
The binary package is named according to the %_build_name_fmt macro. By default this macro contains %{ARCH}/ at the beginning, so that is where the binary package is placed.
Following on from your last comment, by default the RPM will go into the subdirectory that matches the platform you're building on. You can override this by passing the --target parameter to rpmbuild, but this only applies where valid; for example, you can use --target i386 on an x86_64 system to build a 32-bit RPM, but you can't build a 64-bit RPM on a 32-bit platform.
The RPM goes to the RPMS folder and the source RPM to the SRPMS. This is not controlled by the spec file - this is convention. What exactly are you trying to do?