home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.linux.slackware      I think its the one without Selinux crap      87,272 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 85,802 of 87,272   
   Henrik Carlqvist to Chris Vine   
   Re: Oauth 2.0   
   06 May 22 05:38:50   
   
   freeserve.co.uk> 28cf0056   
   From: Henrik.Carlqvist@deadspam.com   
      
   On Thu, 05 May 2022 20:19:59 +0100, Chris Vine wrote:   
   > Probably the best way is to install openssl-1.1 in a different   
   > prefix such as /opt/openssl-1.1, and when compiling fetchmail set   
   > PKG_CONFIG_PATH to first look in /opt/openssl-1.1/lib64/pkgconfig and   
   > set LD_LIBRARY_PATH to /opt/openssl-4.1/lib64.  When running fetchmail   
   > you would also need to set LD_LIBRARY_PATH, say by starting fetchmail   
   > via a shell script.   
      
   Yes, that will probably be neccessary, on Slackware 14.2   
   "ldd /usr/bin/fetchmail" shows:   
      
           linux-vdso.so.1 (0x00007ffe78bc2000)   
           libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f98e49ac000)   
           libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f98e4791000)   
           libssl.so.1 => /lib64/libssl.so.1 (0x00007f98e451d000)   
           libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007f98e40c5000)   
           libc.so.6 => /lib64/libc.so.6 (0x00007f98e3cfc000)   
           libdl.so.2 => /lib64/libdl.so.2 (0x00007f98e3af7000)   
           /lib64/ld-linux-x86-64.so.2 (0x0000557b6be1a000)   
      
   So fetchmail is dynamically linked to /lib64/libssl.so.1 which is a   
   symbolic link to libssl.so.1.0.0 which comes from the openssl-1.0.2u   
   (which by the way was updated again just some day ago)   
      
   If you are lucky, fetchmail and other applications will work better out-   
   of-the box with the new 1.1 versions of the dynamic libraries from   
   openssl-1.1, but maybe something will break.  If so, there is no better   
   suggestion than to install then newer version of openssl in another   
   prefix and recompile selected applications against the newer version.   
   Maybe you want to statically link those recompiled applications to avoid   
   the need to set LD_LIBRARY_PATH before running the recompiled   
   applications.   
      
   You will not be able to have both versions of openssl installed next to   
   each other in their ordinary directory structure as they probably both   
   want to use the symbolic link libssl.so.1 and they probably both want to   
   use the same header files in /usr/include/openssl.   
      
   regards Henrik   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca