-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load system libraries in case of custom library location #135
Comments
On 19/02/2023 16:03, Ganesh Kandu ( गणेश कांदु ) wrote:
Hi,
|/lib64/libkrb5.so.3| NEEDED by |libmsodbcsql|, |libcrypto.so.1.1| is
NEEDED by |/lib64/libkrb5.so.3|
|/lib64/libkrb5.so.3| is loading |libcrypto.so.1.1| from
|/usr/local/apps/openssl-11/lib/libcrypto.so.1.1| insted of
|/lib64/libcrypto.so.1.1| and Setting |LD_LIBRARY_PATH, PATH|
doesn't work
What could be solution of it ?
Not sure, but I am close to 100% certain its not a unixODBC problem.
Maybe try using ldd to see what libs are needed. Not sure what is using
/usr/local/apps, that's not a location I have seen before.
|
see but with PHP it load |
On CentOS and Ubuntu |
On 19/02/2023 17:16, Ganesh Kandu ( गणेश कांदु ) wrote:
|ldd -v msodbcsql|
i noticed |libk5crypto.so.3| Need |libcrypto.so.1.1| on Almalinux only
On CentOS and Ubuntu |libk5crypto.so.3| doesn't load |libcrypto.so.1.1|
|Again, everything about this looks like a not a unixODBC problem.|
|
I've seen this before with Microsoft's ODBC drivers. When loading in to Node.js on Red Hat, the OpenSSL libraries used by Node conflict with those that the driver wants to use. The problem is really with the driver (really with ELF, but you're not changing that). If the driver doesn't want conflicts, it needs to either a) use the system libraries or b) dlopen() its vendor libraries instead of directly linking to them. |
On 20/02/2023 16:25, Kevin Adler wrote:
I've seen this before with Microsoft's ODBC drivers. When loading in
to Node.js on Red Hat, the OpenSSL libraries used by Node conflict
with those that the driver wants to use. The problem is really with
the driver (really with ELF, but you're not changing that). If the
driver doesn't want conflicts, it needs to either a) use the system
libraries or b) dlopen() its vendor libraries instead of directly
linking to them.
Yep, I have seen similar in the past, but in this case I don't think its
the drivers fault as I think the MS drivers are built with their own ssl
libs instead of linking to a shared lib(s), the problem here is with the
krb5 lib that is looking for a different build of openssl. Looks like
php has committed to loading both openssl 3.0 and 1.1 from its own
location which is then colliding with the krb5 requirements.
Looks like I would guess a build problem in the krb5 lib.
https://bugzilla.redhat.com/show_bug.cgi?id=1829790
Having a quick grep in my tree of openssl versions, I can find some
EVP_KDF_* entry points in openssl 3.0 but still no EVP_KDF_ctrl. Maybe
the solution is to rebuild or use a different libkrb5
|
Well usually distro packages are built against the same version of OpenSSL, so they should work cohesively but I see now that PHP is coming from /usr/local/apps, so presumably not a distro package. It's pulling in OpenSSL 3 libraries, but trying to use Kerberos libraries from the system which are linked to OpenSSL 1.1. Yep, this is the equivalent of "DLL Hell" on Linux and other ELF platforms. Whichever symbol gets loaded first wins, so you can't really load libraries that link to different versions of OpenSSL in the same process. The only real way to get around this that I know of is to dlopen it and dlsym the functions you need, which was why I suggest this for the driver. @lurcher I think your suggestion is correct. Likely need to either rebuild Kerberos to use OpenSSL 3 (likely still issues once the driver gets loaded and wants its own OpenSSL 1.1 libraries) or rebuild PHP, etc with OpenSSL 1.1. And yes, this is definitely a packager issue not a unixODBC issue. |
Later versions of the msodbcsql17 and msodbcsql18 are flexible and will use the latest OpenSSL available on the system, precisely to avoid this problem, but it looks like in this case it's the other libs it depends on which have conflicting OpenSSL versions. https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/programming-guidelines#bkmk-openssl |
Its system's
I think |
Transitive dependencies are not something we have any control over. |
Hi,
My PHP is build with custom OpenSSL and
-rpath
, when unixODBC trying to loadlibmsodbcsql
its usingphp
's -rpath
that causing error.LD_DEBUG=all php -r '$con=new PDO("sqlsrv:Server=domain.com,1433;Database=db", "user", "password");'
/lib64/libkrb5.so.3
NEEDED bylibmsodbcsql
,libcrypto.so.1.1
is NEEDED by/lib64/libkrb5.so.3
/lib64/libkrb5.so.3
is loadinglibcrypto.so.1.1
from/usr/local/apps/openssl-11/lib/libcrypto.so.1.1
insted of/lib64/libcrypto.so.1.1
and SettingLD_LIBRARY_PATH, PATH
doesn't workWhat could be solution of it ?
The text was updated successfully, but these errors were encountered: