threads / discuss / 58496

2.38.0 rc1 and explicit openssl version

Subject: 2.38.0 rc1 and explicit openssl version

## tl;dr

3 messages between Sep 22, 2022 and Sep 22, 2022.

replies: 2people: 3as markdown or json

Lana Deere· Sep 22, 2022, 18:35 UTC · lore

I built 2.38.0 rc1 from the tar file today.  One of the configure
options I used was "--with-openssl=<path>/openssl/3.0.5".  As
expected, configure reported
    configure: Setting OPENSSLDIR to<path>/openssl/3.0.5

When it got as far as linking git-imap-send, the link command pointed
at the subdirectory "lib" within the openssl/3.0.5 installation.
    gcc ... -o git-imap-send ...  -L<path>/openssl/3.0.5/lib ...

However, this version of openssl put the libraries into a "lib64" subdirerctory rather than into a "lib" subdirectory so the link failed. An easy workaround is to put a symlink from lib64 to lib inside the openssl directory. It would be nice, though, if the configure command could figure this out automatically.

.. Lana (lana.deere@gmail.com)

Todd Zullinger· Sep 22, 2022, 18:48 UTC · re: Lana Deere · lore

Re: 2.38.0 rc1 and explicit openssl version

Lana Deere wrote:

Show 14 quoted lines

> I built 2.38.0 rc1 from the tar file today.  One of the configure
> options I used was "--with-openssl=<path>/openssl/3.0.5".  As
> expected, configure reported
>     configure: Setting OPENSSLDIR to<path>/openssl/3.0.5
> 
> When it got as far as linking git-imap-send, the link command pointed
> at the subdirectory "lib" within the openssl/3.0.5 installation.
>     gcc ... -o git-imap-send ...  -L<path>/openssl/3.0.5/lib ...
> 
> However, this version of openssl put the libraries into a "lib64"
> subdirerctory rather than into a "lib" subdirectory so the link
> failed.  An easy workaround is to put a symlink from lib64 to lib
> inside the openssl directory.  It would be nice, though, if the
> configure command could figure this out automatically.

I don't use the configure script, but I think you can specify the lib dir via --with-lib=lib64. (The same can be done using config.mak or passing parameters directly to make with the lib argument, e.g. make lib=lib64 ...)

If I'm reading correctly, that would apply to all packages which were configured via one of the --with-$package=$path options.

-- 
Todd

rsbecker@nexbridge.com· Sep 22, 2022, 18:55 UTC · re: Lana Deere · lore

RE: 2.38.0 rc1 and explicit openssl version

On September 22, 2022 2:36 PM, Lana Deere wrote:

Show 13 quoted lines

>I built 2.38.0 rc1 from the tar file today.  One of the configure options I used was "-
>-with-openssl=<path>/openssl/3.0.5".  As expected, configure reported
>    configure: Setting OPENSSLDIR to<path>/openssl/3.0.5
>
>When it got as far as linking git-imap-send, the link command pointed at the
>subdirectory "lib" within the openssl/3.0.5 installation.
>    gcc ... -o git-imap-send ...  -L<path>/openssl/3.0.5/lib ...
>
>However, this version of openssl put the libraries into a "lib64"
>subdirerctory rather than into a "lib" subdirectory so the link failed.  An easy
>workaround is to put a symlink from lib64 to lib inside the openssl directory.  It
>would be nice, though, if the configure command could figure this out
>automatically.

The OpenSSL team moved the 64-bit builds to lib64 as of 3.0.x. This is very likely to be retained in 3.1.x. I am working on a change that moves the runnable parts of OpenSSL 64-bit to /bin64. The 32-bit builds are still in /lib and /bin. My team hit this issue when first trying to build git and curl with 3.0.1. We control where we pick up libraries on the make command line using the CFLAGS and LDFLAGS variables so the internal git makefile does not need to know where the libraries are. This also avoids needing symlinks that can cause DLL conflicts between 32 and 64 models.

Regards, Randall