On Wed, Dec 12, 2018 at 3:32 PM Helmut K. C. Tessarek
<tessarek@evermeet.cx mailto:tessarek@evermeet.cx> wrote:

>
> You should create a bug report.
>
> Please note that a static configuration has some issues (e.g.
> https://bugs.php.net/bug.php?id=73609 and think there were more issues
> maybe). Basically it's not well supported so I would recommend to do a
> shared build instead otherwise you are probably on your own unless
> someone finds time to look into it.

Thanks, Jakub for your reply.

Hmm, I checked the link you sent, but this ticket has nothing to do with
linking against a static openssl library.

This ticket mentions that openssl is not supported as a shared
extension. But that is not what I'm doing.

I try to link against a static openssl library. But it works when
linking against a static openssl 1.0.2 lib.
Therefore I highly suspect that there's a problem with configure. But I
will open a ticket, and I will also try to link against a dynamic
openssl 1.1.1.

So linking against a static openssl 1.0.2 works, but against a static
openssl 1.1.1 does not work.

However, linking against a static openssl library should be supported.
Years back people even suggested to always link against a static openssl
lib because of security reasons (no hijacking of dynamic libs and
whatnot). This might not be relevant anymore, but there's no logical
reason why linking against a static openssl 1.1.1 should not work.

Ah I see! Yeah I think it should work so it might be a bug if it
doesn't. I would suggest to create a bug report.

Will do.

Thanks,
K. C.

Am 12.12.2018 um 16:37 schrieb Jakub Zelenka:

On Wed, Dec 12, 2018 at 3:32 PM Helmut K. C. Tessarek tessarek@evermeet.cx
wrote:

You should create a bug report.

Please note that a static configuration has some issues (e.g.
https://bugs.php.net/bug.php?id=73609 and think there were more issues
maybe). Basically it's not well supported so I would recommend to do a
shared build instead otherwise you are probably on your own unless
someone finds time to look into it.

Thanks, Jakub for your reply.

Hmm, I checked the link you sent, but this ticket has nothing to do with
linking against a static openssl library.

This ticket mentions that openssl is not supported as a shared
extension. But that is not what I'm doing.

I try to link against a static openssl library. But it works when
linking against a static openssl 1.0.2 lib.
Therefore I highly suspect that there's a problem with configure. But I
will open a ticket, and I will also try to link against a dynamic
openssl 1.1.1.

So linking against a static openssl 1.0.2 works, but against a static
openssl 1.1.1 does not work.

However, linking against a static openssl library should be supported.
Years back people even suggested to always link against a static openssl
lib because of security reasons (no hijacking of dynamic libs and
whatnot). This might not be relevant anymore, but there's no logical
reason why linking against a static openssl 1.1.1 should not work.

Ah I see! Yeah I think it should work so it might be a bug if it doesn't. I
would suggest to create a bug report.

Cheers

Jakub

I might be wrong, but I vaguely remember that PHp does not call
"pkg-config --static --libs openssl" with a correctly setup
PKG_CONFIG_PAATZ to get the libs needed for static compilation.
Typically OpenSSL installs correct pc files that contain pthread as such
a dependency. Without asking pkg-config some fixed decisin logic would
need to find all the needed libs.

Regards,

Rainer

Am 14.10.2019 um 10:12 schrieb Rainer Jung:

Am 13.10.2019 um 23:04 schrieb Helmut K. C. Tessarek:

Don't know about previous versions, but at least on 7.4 setting
OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config
--static --cflags/--libs return values) should work. These environment
variables allow you to bypass normal pkg-config checks, which are
generally
going to be non-static.

I've tried pretty much anything, so if you have flags and env vars
that work,
please post them here.

I think what he means is doing:

% export PKG_CONFIG_PATH=/path/to/my/openssl111/pkgconfig

where that directory should contain the pc files from your OpenSSL 1.1.1
installation.

Then (example, you results may vary):

% pkg-config --cflags openssl

-I/path/to/my/openssl111/include

So you would set

export OPENSSL_CFLAGS=/path/to/my/openssl111/include

and then

% pkg-config --libs --static openssl

-L/path/to/my/openssl111/lib -lssl -lcrypto -ldl -pthread

so you would set

export OPENSSL_LIBS="-L/path/to/my/openssl111/lib -lssl -lcrypto -ldl
-pthread"

You might try with the values you get back from the above pkg-config
command on your system.

If it doesn't work, it would be helpful, if you could then post again
your config.log so we can understand the remaining problems.

Addition to self:

plus temporarily rename libssl.so and libcrypto.so during the PHP build,
e.g. adding a trailing underscore. The versioned .so. files can stay
in place, just not *.so.

Regards,

Rainer

Hello,

I think what he means is doing:

Yep, I remember I had tried that as well, but I just went through it again to
get the info you requested:

export PKG_CONFIG_PATH=/usr/local/ssl-1.1.1/lib/pkgconfig
export OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include"
export OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -lssl -lcrypto -ldl -pthread"

If it doesn't work, it would be helpful, if you could then post again your
config.log so we can understand the remaining problems.

https://evermeet.cx/pub/logs/config.php72.log

Cheers,
K. C.

--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek <
tessarek@evermeet.cx> wrote:

Don't know about previous versions, but at least on 7.4 setting
OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config
--static --cflags/--libs return values) should work. These environment
variables allow you to bypass normal pkg-config checks, which are
generally
going to be non-static.

I've tried pretty much anything, so if you have flags and env vars that
work,
please post them here.

Here's what pkg-config --static tells me on my system:

-lssl -lcrypto -ldl -pthread

So I use this for OPENSSL_LIBS, while explicitly requesting the static .a
libs (on the assumption that only openssl should be linked statically, not
all libs):

./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
-l:libcrypto.a -ldl -pthread"

configure passes, but then during linking I get:

/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libcrypto.a(threads_pthread.o):
undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'

It looks like the "-pthread" flag gets stripped. Then I tried:

./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a
-l:libcrypto.a -ldl" CFLAGS="-pthread"

This compiles successfully.

ldd sapi/cli/php
linux-vdso.so.1 (0x00007ffd1531f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f04b79a9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f04b77a1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04b7403000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f04b71ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f04b6fe0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04b6bef000)
/lib64/ld-linux-x86-64.so.2 (0x00007f04b8bee000)

The fact that "-pthread" gets stripped from LIBS might be a bug.

Looks like the -pthread stripping happens here:
https://github.com/php/php-src/blob/5197d0cd5e1f4581db1beca1260e1315368ea911/build/php.m4#L371-L377

It doesn't get stripped as much as relocated to EXTRA_LDFLAGS (for static
builds, for shared it goes into SHARED_LIBADD). However EXTRA_LDFLAGS is
only used when linking libraries, while programs use EXTRA_LDFLAGS_PROGRAM.
This seems like an oversight, and it should be added to both.

Nikita