0

Occasionally I have to install new packages on servers. If I'm lucky, I can find an RPM, otherwise, I get to bang my head on the wall and attempt to compile a package.

This time I get to compile GnuPG to get version 2.1.15. So I download all the dependent libraries, run configure && make install, lastly I repeat for the gnupg-2.1.15 package itself, and all goes well, and make puts everything in /usr/local/ including libraries and binaries. Feeling lucky, I check the version:

$ /usr/local/bin/gpg2 --version
gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.6)

Oops. What happened, so I check the linked libraries:

$ ldd /usr/local/bin/gpg2
linux-vdso.so.1 (0x00007fff15db4000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fcab5431000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fcab521d000)
libassuan.so.0 => /lib64/libassuan.so.0 (0x00007fcab5009000)
libc.so.6 => /lib64/libc.so.6 (0x00007fcab4c47000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fcab4a43000)
/lib64/ld-linux-x86-64.so.2 (0x00005615f5c77000)

Ugh, the old built-in-system libraries have been linked. I don't compile software much, so I'm stuck here trying to figure out how to tell gcc via configure (or other?) to link the dependent libraries which were just installed in /usr/local/lib/

This is my configure command for gnupg-2.1.15:

./configure --prefix=/usr/local --with-libgpg-error-prefix=/usr/local/\
--with-libgcrypt-prefix=/usr/local --with-libassuan-prefix=/usr/local\
--with-ksba-prefix=/usr/local --with-npth-prefix=/usr/local

Running this on Fedora 24 with latest updates & kernel installed and gcc 6.2.1.

Thanks for taking the time to consider my issue.

Bob Smith
  • 15
  • 3
  • Firstly (leaving aside the question of using Fedora on servers), why are you doing this? – MadHatter Oct 03 '16 at 07:17
  • So 2.1.13, the version currently in Fedora, is too old?! – Michael Hampton Oct 03 '16 at 07:46
  • 1
    @MadHatter [What is the problem with using Fedora for servers?](http://serverfault.com/q/40408/126632) – Michael Hampton Oct 03 '16 at 07:51
  • @MichaelHampton as you yourself note in your answer, it's the mandatory annual upgrade cycle. Don't get me wrong, I love Fedora, and it runs on all my desktops and laptops. I'd just be doing two OS upgrades a week if I ran it in production, is all. (Actually, because of the short time between *n+2* being released, and *n* being dropped from support, I'd be doing no upgrades most of the time, then fifty a week for a fortnight; but you know what I mean.) – MadHatter Oct 03 '16 at 07:53
  • *So 2.1.13, the version currently in Fedora, is too old?* yes, that was my point, which is why I asked the OP why (s)he was doing this. – MadHatter Oct 03 '16 at 07:56
  • @MadHatter I do them in batches, and with (some) automation. Since everything's Ansible configured, there's almost never any significant breakage, so upgrading 100 or more servers in a day and checking the results on Zabbix is easily achievable. Then there's Atomic, which is a whole other game. – Michael Hampton Oct 03 '16 at 07:58
  • @MichaelHampton I'm sure it works for some people, but the servers I'm responsible for are spread over many clients, each of whom has a small number of custom servers with different needs. I've simply not found these giant automated installation systems to work for me - hence my dislike of frequent OS upgrade requirements. But you make an excellent point about the use of such tools in larger enterprises. – MadHatter Oct 03 '16 at 08:01

1 Answers1

0

It seems like you require a specific version of the program with its dependent libraries or you are experimenting with your system.

You can use the environment variable LD_LIBRARY_PATH to modify the search path of linker in order to find your new library and use it instead of the old one. Here is a page to provide more details about it.

You can try export LD_LIBRARY_PATH=/usr/local/path/to/lib/directory before executing your program. To make this permanent, you can modify ldconfig search paths (usually files under /etc/ld.so.conf.d) and then invoke ldconfig to update caches.

Khaled
  • 35,688
  • 8
  • 69
  • 98
  • Thanks. Setting a custom for LD_LIBRARY_PATH is the ticket. No experimentation here, [gnupg downloads](https://gnupg.org/download/index.html) has all these dependencies. Thanks again. – Bob Smith Oct 03 '16 at 07:57
  • @BobSmith it's not really the answer, just a workaround. Hand-compiling software is a **very bad idea**, because you're then committed to upgrading it all manually every time a new version is released, and to monitoring many project websites to see when upstream releases new versions. You should think *very carefully* about why you specifically need 2.1.15 before you do this. – MadHatter Oct 03 '16 at 07:59
  • @MadHatter: I don't think it is really that bad! Sometimes, you have no other option like the cases: requiring specific version or build option not supported by your system repositories. Others (less common), you need to do some tweaks to the software you are using. The OP is not clear why it is required. – Khaled Oct 03 '16 at 08:21
  • 1
    *The OP is not clear why it is required* and that's my problem with enabling him/her to do something that may be foolish. I agree that somtimes it's unavoidable, but part of our job as sysadmins is to push back when people ask for a particular version of Yet Another Tool, to make sure that the business understands (and commits to supporting for as long as need be!) the *costs* of doing this, and that the business case for doing so is still justified in that context. – MadHatter Oct 03 '16 at 08:36