You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Michael Cunningham <m....@xpedite.com> on 2001/12/13 23:41:03 UTC

apache-api/9115: ap_set_string_slot:

>Number:         9115
>Category:       apache-api
>Synopsis:       ap_set_string_slot:
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Thu Dec 13 14:50:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     m.cunningham@xpedite.com
>Release:        1.3.22
>Organization:
apache
>Environment:
Solaris 8, latest patch cluster. 
>Description:
Hiya,

I am attempting to get Auth_ldap-1.6.0 to work with 
Apache 1.3.22/Openldap 2.0.18 on Solaris 8 fully patched with the latest
patch clusters. I am using gcc version 3.0.2 and all the other 
latest gnu utilities to make/link/ar etc. 

I spoke with te auth_ldap creator and he feels that this is probably 
and Apache problem. 

Everything compiles and links fine.. apache works well without auth_ldap.
Openldap works great using ssl/tls and not.. 

When I try to activate auth_ldap with a loadmodule I get the following. 

LoadModule auth_ldap_module   libexec/auth_ldap.so

ldap-solaris # ./httpd
Syntax error on line 205 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/auth_ldap.so into server: ld.so.1:
./httpd: fatal: relocation error: file
/usr/local/apache/libexec/auth_ldap.so: symbol ap_set_string_slot:
referenced symbol not found

When doing an ldd -d on auth_ldap.so I get the following.. 

ldap-solaris # ldd -d  /usr/local/apache/libexec/auth_ldap.so
libldap.so.2 =>  /usr/lib/libldap.so.2
liblber.so.2 =>  /usr/lib/liblber.so.2
libresolv.so.2 =>        /usr/lib/libresolv.so.2
libssl.so.0.9.6 =>       /usr/lib/libssl.so.0.9.6
libcrypto.so.0.9.6 =>    /usr/lib/libcrypto.so.0.9.6
libc.so.1 =>     /usr/lib/libc.so.1
libgcc_s.so.1 =>         /usr/lib/libgcc_s.so.1
libsocket.so.1 =>        /usr/lib/libsocket.so.1
libnsl.so.1 =>   /usr/lib/libnsl.so.1
libdl.so.1 =>    /usr/lib/libdl.so.1
libmp.so.2 =>    /usr/lib/libmp.so.2
        symbol not found: ap_set_string_slot  
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        symbol not found: ap_set_flag_slot
(/usr/local/apache/libexec/auth_ldap.so)
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
        symbol not found: ap_dummy_mutex
(/usr/local/apache/libexec/auth_ldap.so)

So it looks like the auth_ldap code cant find these 
apache functions which are compiled directly into apache's httpd. 
Any idea why? It looks like apache is exporting these functions
correctly.  Auth_ldap can find all sorts of other apache api
functions.. just not these. 

Thanks for any help you can offer.. 

Mike
-----------------------------------------------------------------
The environment is as follows.. 

PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin
LDFLAG=-L /usr/lib -L/usr/local/lib -R /usr/local/include -R
/usr/include/openssl EDITOR=vi LOGNAME=root PS1=ldap-solaris # 
SHELL=/bin/ksh
HOME=/
LD_LIBRARY_PATH=
TERM=xterm
PWD=/export/home/apache-test/old/apache_1.3.22
TZ=US/Eastern

Apache was configured with this command.. and it works well without
auth_ldap

./configure --enable-module=so --enable-module=auth

Auth_ldap was configured with this command..
LIBS=-lresolv CC=gcc ./configure --with-apxs=/usr/local/apache/bin/apxs

creating cache ./config.cache
checking for apxs... /usr/local/apache/bin/apxs
checking whether apxs works... yes
checking for ber_init in -llber... yes
checking for ldap_init in -lldap... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for working const... yes
checking for vprintf... yes
checking for strdup... yes
checking for strerror... yes
updating cache ./config.cache
creating ./config.status
creating Makefile

ldap-solaris # more config.log (for auth_ldap)
This file contains any messages produced by compilers while running
configure, to aid debugging if configure makes a mistake.

configure:620: checking for apxs
configure:649: checking whether apxs works
configure:722: checking for ber_init in -llber
configure:741: gcc -o conftest    conftest.c -llber -lnsl -lresolv 1>&5
configure:769: checking for ldap_init in -lldap
configure:788: gcc -o conftest    conftest.c -lldap  -llber -lresolv 1>&5
configure:836: checking how to run the C preprocessor
configure:857: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:916: checking for ANSI C header files
configure:929: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:996: gcc -o conftest    conftest.c -lldap -llber -lresolv 1>&5
configure:1021: checking for working const
configure:1075: gcc -c   conftest.c 1>&5
configure:1097: checking for vprintf
configure:1125: gcc -o conftest    conftest.c -lldap -llber -lresolv 1>&5
configure:1204: checking for strdup
configure:1232: gcc -o conftest    conftest.c -lldap -llber -lresolv 1>&5
configure:1204: checking for strerror
configure:1232: gcc -o conftest    conftest.c -lldap -llber -lresolv 1>&5

>How-To-Repeat:
by compiling all this software unfortunatly... 
>Fix:
It appears to be some sort of wierd linking issue since 
the httpd binary cant even find functions that are included 
in itself. Possible it might be an extern "c" naming issue 
as well. I am not sure. I am a novice C coder. 
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]
 
 
 referenced symbol not found