similar to: boot process order, named, and compat libs

On 2/17/20 12:17 PM, Richard W.M. Jones wrote: > Unfortunately this series doesn't work with the real VDDK library :-( > > I see: > > nbdkit: debug: vddk: config_complete > nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 > > Then a little bit later during VDDK initialization it fails with: > >

Hello, I recently setup a CentOS 4.0 box (a derivative of RH). I downloaded a 4.0p1 tarball of OpenSSH and grabbed OpenSSL 0.9.7e. I configured OpenSSL with, $ ./Configure no-idea no-rc5 shared linux-pentium and it built fine. I didn't do a make install. I then configured OpenSSH. Here is a snippet of config.log: [scott at choke openssh-4.0p1]$ less config.log ... This file contains any

Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2)

On 2/13/20 8:01 AM, Richard W.M. Jones wrote: > Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this > always causes problems because VDDK comes bundled with broken > replacements for system libraries, such as libcrypto.so and > libstdc++.so. Two problems this causes which we have seen in the real > world: > > (1) User does ‘export

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

Problem: scp does not work with custom openssl library location OpenSSH & OpenSSL directory location problem. checking whether snprintf correctly terminates long strings... yes checking whether getpgrp requires zero arguments... yes checking OpenSSL header version... 90608f (OpenSSL 0.9.6h [engine] 5 Dec 2002) checking OpenSSL library version... 90608f (OpenSSL 0.9.6h [engine] 5 Dec

http://bugzilla.mindrot.org/show_bug.cgi?id=862 Summary: libcrypto open failed Product: Portable OpenSSH Version: 3.8p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-bugs at mindrot.org ReportedBy: alain.vernat at

On 08/03/2016 06:40 PM, Chris Adams wrote: > Once upon a time, Alice Wonder <alice at domblogger.net> said: >> [alice at pern root]$ ldd builddir/build/BUILDROOT/curl-7.29.0-26.el7_2.awel.libre.0.x86_64/usr/bin/curl >> |grep crypto >> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb6e00a5000) >> libcrypto.so.10 => /lib64/libcrypto.so.10

I've got a situation where I need to hook a dlopen() made by VDDK, a proprietary library, where it passes a relative name expecting to resolve to a copy of several libraries, including libstdc++.so, that it installs alongside itself, and fails to load if that resolves to the system libstdc++.so. The simplest solution of providing LD_LIBRARY_PATH is enough to load VDDK, but then poisons

Hi. I am trying to build samba 3.0.14a on an old redhat 8 box. I'm having a problem in which shared libraries are not found in the smbd, nmbd and other binaries that are produced. The server is running openldap and MIT kerberos with their libraries in /usr/local/lib and include files in /usr/local/include. Openssl is installed in /usr/local/ssl. The resulting binaries look like: --------

Answer inline. On Sun, Dec 30, 2018 at 12:59 PM James <list at xdrv.co.uk> wrote: > On 29/12/2018 13:49, Pierluigi Frullani wrote: > > > My version is 2.2.13 ( it was the last one, at the time of the first > > server setup ). > > 2.2.13 is from around May 2014. It worked but I can't see why you > wouldn't switch to the latest 2.3.4. (You might be seeing

http://bugzilla.mindrot.org/show_bug.cgi?id=841 ------- Additional Comments From dtucker at zip.com.au 2004-04-14 12:00 ------- It's likely that libcrypto.so isn't in LD_LIBRARY_PATH. Try running this and see if you get an error: $ ssh yourserver /usr/local/openssh/libexec/sftp-server or add something like: LD_LIBRARY_PATH=/usr/lib:/path/to/ssl/lib export LD_LIBRARY_PATH to your

* Richard W. M. Jones: > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote: >> I think what confuses me is that keep talking about a single binary, but >> clearly there is this separate vddk DSO, and there is talk of plugins. >> So it seems to me that multiple files are involved already? > > nbdkit is a standalone binary that happens to be able to load

Aki Tuomi wrote: >>>> ldd /usr/local/Dovecot-2.2.25/lib/dovecot/libdcrypt_openssl.so >>>> linux-gate.so.1 => (0x00dca000) >>>> libcrypto.so.1.0.0 => not found >>>> ... > > Well, then it leaves only option of using /etc/ld.so.conf > so basically add your libssl location there. You can also affect where shared

On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote: > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote: >> Howdy, >> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the >> ssl implementation. Unfortunately, this fails to work (tested on >> Debian Unstable and Gentoo):

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

http://bugzilla.mindrot.org/show_bug.cgi?id=1052 Summary: Static Compile of 4.1.pl1 fails on Solaris 9 Product: Portable OpenSSH Version: 4.1p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: bitbucket at mindrot.org

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

Once upon a time, Alice Wonder <alice at domblogger.net> said: > [alice at pern root]$ ldd builddir/build/BUILDROOT/curl-7.29.0-26.el7_2.awel.libre.0.x86_64/usr/bin/curl > |grep crypto > libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb6e00a5000) > libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fb6df3e8000) Here is your problem - unless you specify an