LDAP build broken - Externals

10 years ago by Stanislav Malyshev — view source

unread

Hi!

I've been rebuilding my checkout of master and I've discovered LDAP
build is broken:

Undefined symbols for architecture x86_64:
"_ldap_control_find", referenced from:
_zif_ldap_control_paged_result_response in ldap.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

Looks like it comes from commit 4f7808ec50b279e1088cd01dbd502498617f2aca
which replaced ldap_find_control with ldap_control_find, however my LDAP
library on Mac OS X 10.9 has _ldap_find_control but not
_ldap_control_find. configure worked fine however - so we need to either
add check in configure of ifdefs.

Thanks,

Stas Malyshev
smalyshev@gmail.com

10 years ago by come.bernigaud@opensides.be — view source

unread

I've been rebuilding my checkout of master and I've discovered LDAP
build is broken:

Undefined symbols for architecture x86_64:
"_ldap_control_find", referenced from:
_zif_ldap_control_paged_result_response in ldap.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

Hello,

Which library are you building against?
We tried to understand which libs PHP-LDAP was supposed to support but found nothing besides openldap so we went and based our cleanup on a requirement being openldap>=2.4.
Are you using an older version, or an other library? Which one?

10 years ago by Ferenc Kovacs — view source

unread

On Sun, Jul 5, 2015 at 7:02 PM, Côme BERNIGAUD come.bernigaud@opensides.be
wrote:

I've been rebuilding my checkout of master and I've discovered LDAP
build is broken:

Undefined symbols for architecture x86_64:
"_ldap_control_find", referenced from:
_zif_ldap_control_paged_result_response in ldap.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

Hello,

Which library are you building against?
We tried to understand which libs PHP-LDAP was supposed to support but
found nothing besides openldap so we went and based our cleanup on a
requirement being openldap>=2.4.
Are you using an older version, or an other library? Which one?

hi,

I can reproduce the issue mentioned by Stas, with the default libldap.dylib
on Mac OSX 10.10.14 (latest version).
The interesting thing is that the header file contains the function:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ grep
'ldap_control_find' /usr/include/ldap.h
ldap_control_find LDAP_P((
LDAP_CONST char *oid,
LDAPControl **ctrls,
LDAPControl ***nextctrlp ));

but the precompiled library does not:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ nm -gU
/usr/lib/libldap.dylib|grep find
0000000000008dee T _ldap_find_control

The version information for ldap here reports it's version as 2.4.28, but I
wouldn't be surprised if this is different from the official upstream.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

10 years ago by come.bernigaud@opensides.be — view source

unread

I can reproduce the issue mentioned by Stas, with the default libldap.dylib on Mac OSX 10.10.14 (latest version).
The interesting thing is that the header file contains the function:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ grep 'ldap_control_find' /usr/include/ldap.h
ldap_control_find LDAP_P((
LDAP_CONST char *oid,
LDAPControl **ctrls,
LDAPControl ***nextctrlp ));

but the precompiled library does not:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ nm -gU /usr/lib/libldap.dylib|grep find
0000000000008dee T _ldap_find_control

The version information for ldap here reports it's version as 2.4.28, but I wouldn't be surprised if this is different from the official upstream.

Wow… why would they have it in the header and remove it from the build -_-
Could you tell me the value of the constant LDAP_API_VERSION?

10 years ago by Ferenc Kovacs — view source

unread

On Mon, Jul 6, 2015 at 10:05 AM, Côme BERNIGAUD <come.bernigaud@opensides.be

wrote:

I can reproduce the issue mentioned by Stas, with the default
libldap.dylib on Mac OSX 10.10.14 (latest version).
The interesting thing is that the header file contains the function:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ grep
'ldap_control_find' /usr/include/ldap.h
ldap_control_find LDAP_P((
LDAP_CONST char *oid,
LDAPControl **ctrls,
LDAPControl ***nextctrlp ));

but the precompiled library does not:
[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ nm -gU
/usr/lib/libldap.dylib|grep find
0000000000008dee T _ldap_find_control

The version information for ldap here reports it's version as 2.4.28, but
I wouldn't be surprised if this is different from the official upstream.

Wow… why would they have it in the header and remove it from the build -_-
Could you tell me the value of the constant LDAP_API_VERSION?

[tyrael@Ferencs-MacBook-Pro php-src.git (master ✗)]$ grep LDAP_API_VERSION
/usr/include/ldap.h
#define LDAP_API_VERSION 3001

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

10 years ago by come.bernigaud@opensides.be — view source

unread

It gives me 3001 as API-Version.

Does that help you? Any other values that might be of interest?

As far as I can see that it's 3001 since 2004 at least.....

Yeah it does not help, this is the same version official openldap is giving.
The Mac Os build seems to be so broken…

We have to add a work-around.
Possibilities are:

Add a test in the configure for this method and disable if it’s not there, tell Mac users to get a real openldap.
Add the same kind of test but set a define with it and add ifdefs in the code to use ldap_find_control instead
Add the same test but in the ifdef declare an ldap_control_find method which calls ldap_find_control.

10 years ago by come.bernigaud@opensides.be — view source

unread

Am 06.07.15 um 10:15 schrieb Côme BERNIGAUD:

Possibilities are:

Add a test in the configure for this method and disable if it’s not
there, tell Mac users to get a real openldap.

That might be the best solution but I think it's not really practical.
Even the brew-installation (currently) uses the internal LDAP-library.

I agree this would be ideal but seems kind of harsh for Mac users

Add the same kind of test but set a define with it and add ifdefs in
the code to use ldap_find_control instead

Add the same test but in the ifdef declare an ldap_control_find method
which calls ldap_find_control.

This sounds like the best solution to it. At least as long as the two
functions are interchangeable. From a first glance at the code I've seen
that the function-signature is different of the both, but I don't know
whether that can be overcome.

Going this way would mean that the code change is concentrated on one
place (as far as I see it) which would make it easier to maintain.
Otherwise we'd have multiple ifdefs scattered arouond the source-code.
Or did I missinterpret that?

Yeah, this was the idea, concentrating the changes in one place.
I’m gonna check if it’s easy to implement.

10 years ago by Anatol Belski — view source

unread

Hi Come,

-----Original Message-----
From: Côme BERNIGAUD [mailto:come.bernigaud@opensides.be]
Sent: Monday, July 6, 2015 10:45 AM
To: Andreas Heigl; PHP internals
Subject: Re: [PHP-DEV] Re: LDAP build broken

Am 06.07.15 um 10:15 schrieb Côme BERNIGAUD:

Possibilities are:

Add a test in the configure for this method and disable if it’s not
there, tell Mac users to get a real openldap.

That might be the best solution but I think it's not really practical.
Even the brew-installation (currently) uses the internal LDAP-library.

I agree this would be ideal but seems kind of harsh for Mac users

Add the same kind of test but set a define with it and add ifdefs
in the code to use ldap_find_control instead

Add the same test but in the ifdef declare an ldap_control_find
method which calls ldap_find_control.

This sounds like the best solution to it. At least as long as the two
functions are interchangeable. From a first glance at the code I've
seen that the function-signature is different of the both, but I don't
know whether that can be overcome.

Going this way would mean that the code change is concentrated on one
place (as far as I see it) which would make it easier to maintain.
Otherwise we'd have multiple ifdefs scattered arouond the source-code.
Or did I missinterpret that?

Yeah, this was the idea, concentrating the changes in one place.
I’m gonna check if it’s easy to implement.
I've also another symbol error with today's master

/usr/bin/ld.bfd.real: ext/ldap/.libs/ldap.o: undefined reference to symbol 'ber_scanf@@OPENLDAP_2.4_2'
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2: error adding symbols: DSO missing from command line

On
cat /etc/issue
Ubuntu 14.04.2 LTS \n \l

Probably should be added to the configure checks as well.

Regards

Anatol

10 years ago by come.bernigaud@opensides.be — view source

unread

I've also another symbol error with today's master

/usr/bin/ld.bfd.real: ext/ldap/.libs/ldap.o: undefined reference to symbol 'ber_scanf@@OPENLDAP_2.4_2'
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2: error adding symbols: DSO missing from command line

The call to ber_scanf is from a commit of 2010 adding pagination support through controls.
Some people already got your error in 2013: http://www.linuxquestions.org/questions/linux-server-73/adding-package-to-the-linker-command-line-4175446734-print/

It seems they fixed it by adding -llber manually in the makefile, which means the configure script failed to add it somehow.
Could you investigate why the lines in config.m4:

if test -f $LDAP_LIBDIR/liblber.a || test -f $LDAP_LIBDIR/liblber.$SHLIB_SUFFIX_NAME; then
PHP_ADD_LIBRARY_WITH_PATH(lber, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)

Does not do their job? What are the values of LDAP_LIBDIR, SHLIB_SUFFIX_NAME?
Where is liblber in your Ubuntu installation and how is it named?

Côme

10 years ago by Anatol Belski — view source

unread

Hi Come,

-----Original Message-----
From: Côme BERNIGAUD [mailto:come.bernigaud@opensides.be]
Sent: Monday, July 6, 2015 3:18 PM
To: Anatol Belski; 'Andreas Heigl'; 'PHP internals'
Subject: Re: [PHP-DEV] Re: LDAP build broken

I've also another symbol error with today's master

/usr/bin/ld.bfd.real: ext/ldap/.libs/ldap.o: undefined reference to symbol
'ber_scanf@@OPENLDAP_2.4_2'
/usr/lib/x86_64-linux-gnu/liblber-2.4.so.2: error adding symbols: DSO missing
from command line

The call to ber_scanf is from a commit of 2010 adding pagination support
through controls.
Some people already got your error in 2013:
http://www.linuxquestions.org/questions/linux-server-73/adding-package-to-
the-linker-command-line-4175446734-print/

It seems they fixed it by adding -llber manually in the makefile, which means the
configure script failed to add it somehow.
Could you investigate why the lines in config.m4:

if test -f $LDAP_LIBDIR/liblber.a || test -f
$LDAP_LIBDIR/liblber.$SHLIB_SUFFIX_NAME; then
PHP_ADD_LIBRARY_WITH_PATH(lber, $LDAP_LIBDIR,
LDAP_SHARED_LIBADD)

Does not do their job? What are the values of LDAP_LIBDIR,
SHLIB_SUFFIX_NAME?
Where is liblber in your Ubuntu installation and how is it named?

The vars are '/usr/lib' and 'so' ... yep, it obviously does wrong dir search. On 64-bit Ubuntu it's multilib as I've posted earlier /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2, so test -f would clearly fail. But actually, it should fail to configure then.

What I've found out yet is that the error only happens with the static build. Where by in both cases, either shared or static, -lldap is present, but no -llber. That Ubuntu version also doesn't have pkg-config for ldap, otherwise one could prefer it actually. Heh, strange it is. Do you think adding an explicit check for x86_64-linux-gnu would make sense? Actually it doesn't sound right.

Regards

Anatol