Hi all,
I have a number of issues with OpenLDAP on solaris 10. These are mostly to do with Samba, however, boiling the problem down I have tried to simplify things.
I have openldap-2.3.27 configured with this configure line and compiled with gcc version
./configure --prefix=/usr/local/opt/openldap/openldap-2.3.27 --enable-crypt --enable-ldap --enable-slapd=no --enable-shared=no
I have tried to compile the following simple program:
$ more ldaptest.c #include <ldap.h>
main() { char *ldapname="Dn=this is a long DN"; char *result;
result=ldap_dn2ad_canonical( ldapname ); }
With the command line /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
This gives this error: Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//ccKJLi7T.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
looking as the libraries: $ /usr/ccs/bin/nm /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a | grep ldap_dn2ad_canonical [57] | 3116| 120|FUNC |GLOB |0 |1 |ldap_dn2ad_canonical
However when I compile against the dynamic libraries compilation works.
/usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib -lldap -llber ldaptest.c
I am at the limit of my understanding. Can anyone help.
Regards
Rob
--On Wednesday, December 06, 2006 4:21 PM +0000 Robert Bannocks R.Bannocks@nhm.ac.uk wrote:
Hi all,
I have a number of issues with OpenLDAP on solaris 10. These are mostly to do with Samba, however, boiling the problem down I have tried to simplify things.
I have openldap-2.3.27 configured with this configure line and compiled with gcc version
Since you are starting from scratch, I'd recommend building 2.3.30.
./configure --prefix=/usr/local/opt/openldap/openldap-2.3.27 --enable-crypt --enable-ldap --enable-slapd=no --enable-shared=no
crypt is platform specific, and it is generally recommended not to use it.
I have tried to compile the following simple program:
$ more ldaptest.c # include <ldap.h>
main() { char *ldapname="Dn=this is a long DN"; char *result;
result=ldap_dn2ad_canonical( ldapname );}
With the command line /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
Your paths on your -L lines don't match.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
With the command line /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
Your paths on your -L lines don't match.
For that matter, I think you're confusing big L with little l. Typically you'd, assuming those paths are right,
gcc -I/usr/local/opt/openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib -lldap -llber ldaptest.c
big L is search path, little l is library name (-lfoo => libfoo.{a,so})
Looks like you're trying to use .a static libraries. If you use .so shared libraries, you'll probably want an RPATH. You can Google for that or ask the Solaris community for help.
I *am* trying to use static libraries. Appols for the confusion over the -L and -l. I am now trying things more directly:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//ccUaa9gP.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Doing this with 2.3.30 is no help either:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.30/include /usr/local/opt/openldap/openldap-2.3.30/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.30/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//cc2EWpQ9.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Why is this symbol not found with the static libraries? With the dynamic ones things go fine:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.so /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.so ldaptest.c $ ldd a.out libldap-2.3.so.0 => (file not found) liblber-2.3.so.0 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2
I believe that this is an openldap issue not a Solaris one.
Regards,
Rob
-----Original Message----- From: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Sent: 06 December 2006 22:46 To: Robert Bannocks Cc: openldap-software@openldap.org; Quanah Gibson-Mount Subject: Re: Solaris 10 and openldap - help needed.
With the command line /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
Your paths on your -L lines don't match.
For that matter, I think you're confusing big L with little l.
Typically
you'd, assuming those paths are right,
gcc -I/usr/local/opt/openldap/openldap-2.3.27/include - L/usr/local/opt/openldap/openldap-2.3.27/lib -lldap -llber ldaptest.c
big L is search path, little l is library name (-lfoo =>
libfoo.{a,so})
Looks like you're trying to use .a static libraries. If you use .so
shared
libraries, you'll probably want an RPATH. You can Google for that or
ask
the Solaris community for help.
Maybe. Is the symbol actually in your libldap.a? e.g.
$ nm /usr/local/lib/libldap.a | grep _dn2ad_ [118] | 134| 21|OBJT |GLOB |0 |5 |$XBGxIqAd5tbFHwZ.ldap_dn2ad_canonical.__func__ [117] | 3136| 124|FUNC |GLOB |0 |2 |ldap_dn2ad_canonical
If you're seeing good results with --enable-shared=yes, maybe try different config lines that build both the static and shared. I don't immedately see how that would matter, but autoconf might be turning off some part you need. Bottom line, I can get your sample program to compile (I don't have static libsasl2.a, it'd be fairly meaningless), as below. I'd also be wary that your .a file is a real archive and not some magical libtool wrapper, and that it didn't get borked by a program like GNU strip (which, historically at least, has been very dangerous on Solaris).
$ /opt/SUNWspro/bin/cc -I/usr/local/include -{L,R}/usr/local/lib foo.c /usr/local/lib/lib{ldap,lber}.a /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -lsasl2 -lnsl -lsocket -lresolv -o foo "foo.c", line 4: warning: old-style declaration or incorrect type for: main $ ldd foo # no libldap.so libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
$ gcc -R/usr/local/lib foo.c /usr/local/lib/lib{ldap,lber}.a /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -lsasl2 -lnsl -lsocket -lresolv -o foo $ ldd foo libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
On Thu, 7 Dec 2006, Robert Bannocks wrote:
I *am* trying to use static libraries. Appols for the confusion over the -L and -l. I am now trying things more directly:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//ccUaa9gP.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Doing this with 2.3.30 is no help either:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.30/include /usr/local/opt/openldap/openldap-2.3.30/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.30/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//cc2EWpQ9.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Why is this symbol not found with the static libraries? With the dynamic ones things go fine:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.so /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.so ldaptest.c $ ldd a.out libldap-2.3.so.0 => (file not found) liblber-2.3.so.0 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2
I believe that this is an openldap issue not a Solaris one.
Regards,
Rob
-----Original Message----- From: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Sent: 06 December 2006 22:46 To: Robert Bannocks Cc: openldap-software@openldap.org; Quanah Gibson-Mount Subject: Re: Solaris 10 and openldap - help needed.
With the command line /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.27/include -L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
Your paths on your -L lines don't match.
For that matter, I think you're confusing big L with little l.
Typically
you'd, assuming those paths are right,
gcc -I/usr/local/opt/openldap/openldap-2.3.27/include - L/usr/local/opt/openldap/openldap-2.3.27/lib -lldap -llber ldaptest.c
big L is search path, little l is library name (-lfoo =>
libfoo.{a,so})
Looks like you're trying to use .a static libraries. If you use .so
shared
libraries, you'll probably want an RPATH. You can Google for that or
ask
the Solaris community for help.
I have now recompiled openldap into 2 versions
# export CFLAGS="-D_AVL_H" # make distclean && ./configure --prefix=/usr/local/opt/openldap/openldap-2.3.30-shared --enable-ldap --enable-slapd=no --enable-static=no --enable-shared=yes && make depend && make
and
# export CFLAGS="-D_AVL_H" # make distclean && ./configure --prefix=/usr/local/opt/openldap/openldap-2.3.30-static --enable-ldap --enable-slapd=no --enable-static=yes --enable-shared=no && make depend && make
The results with the shared ones are : $ /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.30-shared/include /usr/local/opt/openldap/openldap-2.3.30-shared/lib/libldap.so ldaptest.c -o ldaptest $ ldd ldaptest libldap-2.3.so.0 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2
The results with the static ones are : $ /usr/sfw/bin/gcc -I/usr/local/opt//openldap/openldap-2.3.30-static/include /usr/local/opt/openldap/openldap-2.3.30-static/lib/libldap.a ldaptest.c -o ldaptest Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//cco5elQD.o ld: fatal: Symbol referencing errors. No output written to ldaptest collect2: ld returned 1 exit status
Running nm on libldap.a gives: $ /usr/ccs/bin/nm /usr/local/opt/openldap/openldap-2.3.30-static/lib/libldap.a | grep _dn2ad [57] | 3116| 120|FUNC |GLOB |0 |1 |ldap_dn2ad_canonical
So there is something odd here.
-----Original Message----- From: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Sent: 07 December 2006 14:32 To: Robert Bannocks Cc: openldap-software@openldap.org Subject: RE: Solaris 10 and openldap - help needed.
Maybe. Is the symbol actually in your libldap.a? e.g.
$ nm /usr/local/lib/libldap.a | grep _dn2ad_ [118] | 134| 21|OBJT |GLOB |0 |5 |$XBGxIqAd5tbFHwZ.ldap_dn2ad_canonical.__func__ [117] | 3136| 124|FUNC |GLOB |0 |2 |ldap_dn2ad_canonical
If you're seeing good results with --enable-shared=yes, maybe try different config lines that build both the static and shared. I don't immedately see how that would matter, but autoconf might be turning
off
some part you need. Bottom line, I can get your sample program to
compile
(I don't have static libsasl2.a, it'd be fairly meaningless), as
below.
I'd also be wary that your .a file is a real archive and not some
magical
libtool wrapper, and that it didn't get borked by a program like GNU
strip
(which, historically at least, has been very dangerous on Solaris).
$ /opt/SUNWspro/bin/cc -I/usr/local/include -{L,R}/usr/local/lib foo.c /usr/local/lib/lib{ldap,lber}.a /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -lsasl2 -lnsl -lsocket -lresolv -o foo "foo.c", line 4: warning: old-style declaration or incorrect type for: main $ ldd foo # no libldap.so libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
$ gcc -R/usr/local/lib foo.c /usr/local/lib/lib{ldap,lber}.a /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -lsasl2
-lnsl
-lsocket -lresolv -o foo $ ldd foo libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-V210/lib/libc_psr.so.1
On Thu, 7 Dec 2006, Robert Bannocks wrote:
I *am* trying to use static libraries. Appols for the confusion
over
the -L and -l. I am now trying things more directly:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//ccUaa9gP.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Doing this with 2.3.30 is no help either:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.30/include /usr/local/opt/openldap/openldap-2.3.30/lib/libldap.a /usr/local/opt/openldap/openldap-2.3.30/lib/liblber.a ldaptest.c Undefined first referenced symbol in file ldap_dn2ad_canonical /var/tmp//cc2EWpQ9.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status
Why is this symbol not found with the static libraries? With the dynamic ones things go fine:
$ /usr/sfw/bin/gcc -I/usr/local/opt/openldap/openldap-2.3.27/include /usr/local/opt/openldap/openldap-2.3.27/lib/libldap.so /usr/local/opt/openldap/openldap-2.3.27/lib/liblber.so ldaptest.c $ ldd a.out libldap-2.3.so.0 => (file not found) liblber-2.3.so.0 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2
I believe that this is an openldap issue not a Solaris one.
Regards,
Rob
-----Original Message----- From: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Sent: 06 December 2006 22:46 To: Robert Bannocks Cc: openldap-software@openldap.org; Quanah Gibson-Mount Subject: Re: Solaris 10 and openldap - help needed.
With the command line /usr/sfw/bin/gcc
-I/usr/local/opt//openldap/openldap-2.3.27/include
-L/usr/local/opt/openldap/openldap-2.3.27/lib/libldap.a -L/usr/local/opt/openldap-2.3.27/lib/liblber.a ldaptest.c
Your paths on your -L lines don't match.
For that matter, I think you're confusing big L with little l.
Typically
you'd, assuming those paths are right,
gcc -I/usr/local/opt/openldap/openldap-2.3.27/include - L/usr/local/opt/openldap/openldap-2.3.27/lib -lldap -llber
ldaptest.c
big L is search path, little l is library name (-lfoo =>
libfoo.{a,so})
Looks like you're trying to use .a static libraries. If you use .so
shared
libraries, you'll probably want an RPATH. You can Google for that
or
ask
the Solaris community for help.
[nm shows the symbol, ld/collect2 can't find it]
So there is something odd here.
Sure looks like it. I'd lose GNU binutils and possibly gcc. (Or maybe try gcc -c and /usr/ccs/bin/ld by hand.) Sun Studio 11 is now free (as in beer) at sun.com, and might be worth trying. I've found it produces better sparc code than gcc.
On 12/7/06, Aaron Richton richton@nbcs.rutgers.edu wrote:
[nm shows the symbol, ld/collect2 can't find it]
So there is something odd here.
Sure looks like it. I'd lose GNU binutils and possibly gcc. (Or maybe try gcc -c and /usr/ccs/bin/ld by hand.) Sun Studio 11 is now free (as in beer) at sun.com, and might be worth trying. I've found it produces better sparc code than gcc.
As a slight aside- Can you share your experiences building slapd with the sun compiler?
On Thu, Dec 07, 2006 at 01:08:30PM -0500, matthew sporleder wrote: [...]
As a slight aside- Can you share your experiences building slapd with the sun compiler?
Yes, works. I disagree with libtool on the subject of placing (or not) object search paths into the generated output, and hence have to throw a few extra LDFLAGS=-R... in but that is not a Sun CC specific matter.
Do you have specific questions?
Sincerely, Ralph Rößner
Yes, that's more a question of the Solaris dynamic linker design than the compiler. Sun Studio has been good with OpenLDAP. OpenLDAP has a fairly standards-compliant code base, and the few times something that's not C99 compliant have slipped in, the issue is quickly resolved on the ITS. We currently have the end-to-end OpenLDAP chain (e.g. slapd, cyrus-sasl, openssl, etc.) compiled using Sun Studio and it works fine for both v8+ and v9 (64-bit) code.
On Fri, 8 Dec 2006, Ralph RöÃ~_ner wrote:
On Thu, Dec 07, 2006 at 01:08:30PM -0500, matthew sporleder wrote: [...]
As a slight aside- Can you share your experiences building slapd with the sun compiler?
Yes, works. I disagree with libtool on the subject of placing (or not) object search paths into the generated output, and hence have to throw a few extra LDFLAGS=-R... in but that is not a Sun CC specific matter.
Do you have specific questions?
Sincerely, Ralph Rößner
I tested it on Linux with your test code and it has the same problems with the static libraries whereas with the shared libraries it builds without a problem. So, it is likely a gcc issue with static lib builds rather than an openldap issue.
On Thu, 2006-12-07 at 11:55 -0500, Aaron Richton wrote:
[nm shows the symbol, ld/collect2 can't find it]
So there is something odd here.
Sure looks like it. I'd lose GNU binutils and possibly gcc. (Or maybe try gcc -c and /usr/ccs/bin/ld by hand.) Sun Studio 11 is now free (as in beer) at sun.com, and might be worth trying. I've found it produces better sparc code than gcc.
At 08:50 AM 12/7/2006, Robert Bannocks wrote:
So there is something odd here.
The only thing odd here is your (mis)use of gcc. As this really is not the place to discuss (im)proper use of gcc, I will just make a couple of quick comments: 1) the order you have specified linking to occur in is simply wrong (the object file generated by compiling ldaptest.c should be linked in before dependent libraries are linked in), 2) gcc offers flags to enable static-only linking.
-- Kurt
openldap-software@openldap.org
-
Aaron Richton -
Kurt D. Zeilenga -
matthew sporleder -
Patrick Shinpaugh -
Quanah Gibson-Mount -
Ralph Rößner -
Robert Bannocks