Can't compile OpenLDAP with Berkekey DB: File format not recognized
by ben＠fallinganvils.com
This is my first openldap install.
I am installing by compiling from source on a debian box logged in as myself in my home directory. Berkeley DB is not installed systemwide. LDAP libraries are installed systemwide, but I want to install the whole openldap tarball in my home directory and use that/run an ldap server etc. Only libraries are installed systemwide. No ldap server software is installed systemwide.
I do have root access, but I don't think I should need it.
If I can get it installed under /home/ben, after some experimentation, I'll install it in /home/openldap after creating an openldap user.
I don't know what the debian system uses the ldap libraries it came with for, but I should be able to use my own local version without dealing with that I would think.
This is what I do :
1) Install Berkeley DB 4.6.21 in /home/ben/opt/bdb
$ cd db-4.6.21/build_unix
$ ../dist/configure --prefix=/home/ben/opt/bdb
$ make && make install
$ export LD_RUN_PATH=/home/ben/opt/bdb/lib
$ export CPPFLAGS='-I /home/ben/opt/bdb/include'
$ export LDFLAGS='-L /home/ben/opt/bdb/lib'
$ cd
2) Install OpenLDAP
$ cd openldap-2.4.6
$ ./configure --prefix=/home/ben/opt/openldap
$ make depend
$ make
Making all in /home/ben/src/openldap/openldap-2.4.6
Entering subdirectory include
make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/include'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/include'
Entering subdirectory libraries
make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries'
Making all in /home/ben/src/openldap/openldap-2.4.6/libraries
Entering subdirectory liblutil
make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil'
Entering subdirectory liblber
make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber'
/bin/sh ../..//libtool --mode=link cc -static -g -O2 -L /home/ben/opt/bdb/lib -o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv
cc -g -O2 /home/ben/opt/bdb/lib -o dtest dtest.o -L/home/ben/src/openldap/openldap-2.4.6/libraries/liblber ./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv
/usr/bin/ld: /home/ben/opt/bdb/lib: No such file: File format not recognized
collect2: ld returned 1 exit status
make[2]: *** [dtest] Error 1
make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber'
make[1]: *** [all-common] Error 1
make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries'
make: *** [all-common] Error 1
3) Let's investigate:
$ ls /home/ben/opt/bdb
bin docs include lib
$ ls -l /home/ben/opt/bdb/lib
-rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb-4.6.a
-rw-r--r-- 1 ben ben 813 Nov 28 21:44 libdb-4.6.la
-rwxr-xr-x 1 ben ben 1248813 Nov 28 21:44 libdb-4.6.so
lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb-4.so -> libdb-4.6.so
-rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb.a
lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb.so -> libdb-4.6.so
$ vi libdb-4.6.a
The first bit looks like:
!<arch>
/ 1196286289 0 0 0 27970 `
^@^@^E0^@^@m\xea^@^@m\xea^@^@m\xea^@^@m\xea^@^@u"^@^@
Not sure what that means, but someone might...
$ vi libdb-4.so
The first bit looks like:
^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^C^@^C^@^A^@^@^@\xf0i^A^@4^@^@^@x\xde^Q^@^@^@^@^@4^
@ ^@^D^@(^@^_^@^\^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@\xe8\x85^Q^@\xe8
Hey! more nonsense, but ELF is familiar and seems like a plausable for a linux library...
I also get this error with openldap-2.3.39 and db-4.5.20
I could not use openldap-2.3.39 with db-4.6.21 because I get incompatible version. The configure scripts looks for db versions 4.2 though 4.5 and spits out that error otherwise.
Anyway, thanks for any help.
15 years, 6 months
(ITS#5252) Several SQL Bugs in back-sql
by h.goebel＠goebel-consult.de
Full_Name:
Version: 2.3.38
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (79.207.201.247)
Debugging marks in sql-statement may lead to wrong results.
The interface I implemented yields statements like this when using Thunderbird
for searching for 'Klaus'. Thunderbird tries to look up in email, name and given
name.
Ans in my setup, search is restricted to "(objectclass=evolutionPerson)".
SELECT DISTINCT
ldap_entries.id,res_partner_address.id,
text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM
ldap_entries,res_partner_address,ldap_entry_objclasses
WHERE
res_partner_address.id=ldap_entries.keyval
AND ldap_entries.oc_map_id=1
AND 9=9
AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id
AND ldap_entry_objclasses.oc_name='evolutionPerson'))
AND (( upper(email) LIKE '%KLAUS%')
OR (upper(name) LIKE '%KLAUS%')
OR 7=7
OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%')))
1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done
on email, name or givenname. Thus all records are returned.
2) "2=2 OR" renders the restriction to a specific objectclass useless.
In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this
part away. And exactly this is the problem.
15 years, 6 months
Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com
Ralf Haferkamp wrote:
> On Donnerstag, 29. November 2007, hyc(a)symas.com wrote:
>> rhafer(a)suse.de wrote:
>>> Full_Name: Ralf Haferkamp
>>> Version: All
>>> OS: Linux, glibc 2.7
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (89.166.161.148)
>>>
>>>
>>> Newer versions of glibc (2.7) in my case might return duplicate addrinfo
>>> structs in the results under certain circumstances. According to the
>>> friendly glibc maintainer ;) this is not a bug:
>>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
>>> Unfortunately he doesn't give a reason for this change in behavior.
>> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and
>> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
> The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK
> and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons
> that the glibc author seemingly doesn't want to share with the outer world.
We're calling getaddrinfo with hints.ai_family = AF_UNSPEC, so we should be
getting both IPv4 and IPv6 addresses back. In this case, converting the V6
address to V4 format is obviously not desired.
Also RFC2553 pretty much forbids this: (Page 25)
Also note that the
IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
be returned and a query of the address not performed.
Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
false for "::" and "::1".
>>> BTW, I didn't find any reference in the related RFCs that state that the
>>> getaddrinfo results need to be unique (nor the opposite).
>>> In my current builds I simply patched slapd to check the getaddrinfo()
>>> results for uniqueness in the slap_get_listner_addresses() function. Has
>>> anybody a better idea how to fix this?
>> I'm sure there's nothing that states that the returned info is required to
>> be unique. The returned data must accurately reflect the host databases
>> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts,
>> then it's reasonable to get it returned twice. But if it's only in there
>> once, then returning it twice is a bug.
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 6 months
Re: (ITS#5251) getaddrinfo might return duplicate results
by rhafer＠suse.de
On Donnerstag, 29. November 2007, hyc(a)symas.com wrote:
> rhafer(a)suse.de wrote:
> > Full_Name: Ralf Haferkamp
> > Version: All
> > OS: Linux, glibc 2.7
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (89.166.161.148)
> >
> >
> > Newer versions of glibc (2.7) in my case might return duplicate addrinfo
> > structs in the results under certain circumstances. According to the
> > friendly glibc maintainer ;) this is not a bug:
> > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
> > Unfortunately he doesn't give a reason for this change in behavior.
>
> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and
> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK
and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons
that the glibc author seemingly doesn't want to share with the outer world.
> > BTW, I didn't find any reference in the related RFCs that state that the
> > getaddrinfo results need to be unique (nor the opposite).
> > In my current builds I simply patched slapd to check the getaddrinfo()
> > results for uniqueness in the slap_get_listner_addresses() function. Has
> > anybody a better idea how to fix this?
>
> I'm sure there's nothing that states that the returned info is required to
> be unique. The returned data must accurately reflect the host databases
> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts,
> then it's reasonable to get it returned twice. But if it's only in there
> once, then returning it twice is a bug.
--
Ralf
15 years, 6 months
Re: (ITS#5251) getaddrinfo might return duplicate results
by hyc＠symas.com
rhafer(a)suse.de wrote:
> Full_Name: Ralf Haferkamp
> Version: All
> OS: Linux, glibc 2.7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (89.166.161.148)
>
>
> Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs
> in the results under certain circumstances. According to the friendly glibc
> maintainer ;) this is not a bug:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
> Unfortunately he doesn't give a reason for this change in behavior.
Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and ::1
once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
> BTW, I didn't find any reference in the related RFCs that state that the
> getaddrinfo results need to be unique (nor the opposite).
> In my current builds I simply patched slapd to check the getaddrinfo() results
> for uniqueness in the slap_get_listner_addresses() function. Has anybody a
> better idea how to fix this?
I'm sure there's nothing that states that the returned info is required to be
unique. The returned data must accurately reflect the host databases being
queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, then
it's reasonable to get it returned twice. But if it's only in there once, then
returning it twice is a bug.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 6 months
Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no
Howard Chu writes:
> OK, you're right, it's trivial, and I see that the configure script
> already #defines sig_atomic_t to int if the system doesn't already
> define it. So your suggested changes are harmless, go ahead and make
> them. If you're going to that trouble, you should change gotintr to
> use an explicitly defined contiguous range of values.
OK, later.. that's why I filed an its first (in particular, need to look
at WAKE_LISTENER first.)
Which makes the rest of this reply irrelevant to the ITS, so skip it if
that helps your blood pressure:
> Backward compatibility only reinforces my point, since int has always
> been atomic in the past.
Where do you get that from? A brief search find nothing like that in
the draft and standard versions I've lying around. It would also mean
that sig_atomic_t would be a pointless type.
>> Otherwise the standard would not have needed to define sig_atomic_t.
>
> Note that sig_atomic_t is an *optional* part of the standard;
> implementations are not required to provide it.
Irrelevant. Freestanding implementations need not provide it (nor
most of the rest of the C library), but <signal.h> requires it.
> The standard says it is impossible for arithmetic operations on valid
> values to generate trap representations. Think about it - if it were
> *possible* for intermediate states to be invalid, (...)
A signal breaks the rest of the execution model. A variable need not be
in an "intermediate state" according to that model when a signal
arrives. Otherwise C could not use *any* inherently non-atomic types,
which would rather limit which CPUs could support C. That's why the
standard says signal handlers can do so aburdly few things in the first
place.
> Nobody is stupid enough to design a machine like that, and the
> standard guarantees that programmers never have to worry about such a
> stupidity ever existing.
> (...)
> Not on any machine ever built (for which a C translator exists).
On the countrary, the existence of such hosts is precicely why the
section about signal handlers explicitly contradicts you. And as Doug
Gwyn said, even the little part it does guarantee was hard to get
agreement for.
--
Regards,
Hallvard
15 years, 6 months
(ITS#5251) getaddrinfo might return duplicate results
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: All
OS: Linux, glibc 2.7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.161.148)
Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs
in the results under certain circumstances. According to the friendly glibc
maintainer ;) this is not a bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
Unfortunately he doesn't give a reason for this change in behavior.
BTW, I didn't find any reference in the related RFCs that state that the
getaddrinfo results need to be unique (nor the opposite).
In my current builds I simply patched slapd to check the getaddrinfo() results
for uniqueness in the slap_get_listner_addresses() function. Has anybody a
better idea how to fix this?
15 years, 6 months
Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com
Hallvard B Furuseth wrote:
> [rearranging]
> Howard Chu writes:
>
>> The C standard defines "int" to be the most efficient machine word,
>> and that is always atomic.
>
> It does neither, that I can see. Among other things because "most
> efficient" is not well-defined. E.g. by space or time? Efficient with
> which operations? It's the recommended intent somewhere (the
> Rationale?), but that must be subject to whatever other restrictions an
> implementor faces. (16+ bits, backwards compatibility, etc.)
Backward compatibility only reinforces my point, since int has always been
atomic in the past. Likewise when migrating old code to new hardware, machine
word sizes only grow if they change at all, so any word small enough to be
atomic on old hardware is also atomic on new.
> And the compiler can choose between an atomic and non-atomic operation,
> even with volatile. Volatile guarantees a change is complete at a
> sequence point. Signals need not arrive at sequence points. (C99
> 5.1.2.3p2,4. You can download the standard with amendments free at
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.)
Hm, seems I have a much older draft, this language in 6.2.5 Types has changed.
> Otherwise the standard would not have needed to define sig_atomic_t.
Note that sig_atomic_t is an *optional* part of the standard; implementations
are not required to provide it.
>> sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero
>> immediately, one entry, or two entries after the signal occurs isn't
>> going to make any difference.
>
> Well, I don't see any reason not to use it when the standard says so and
> the change is trivial, even if we don't know of a real-life failure.
> (E.g. if the compiler detects that the variable will not legally change
> and optimizes it away, or if it is being read during a signal which
> changes it so the result of the non-atomic read is a trap
> representation.)
The standard says it is impossible for arithmetic operations on valid values
to generate trap representations. Think about it - if it were *possible* for
intermediate states to be invalid, then it would be *inevitable* that they
occur in normal code and you'd be producing traps practically all the time, at
which point the only way to get useful work out of the hardware would be to
disable the trap mechanism completely (e.g. mask off parity error exception
generation). Nobody is stupid enough to design a machine like that, and the
standard guarantees that programmers never have to worry about such a
stupidity ever existing.
>> Likewise, there's no issue with gotintr/abcan. The signal handler
>> isn't armed until the writes are complete. Therefore whether it can be
>> read atomically or not inside the handler is irrelevant, the value is
>> constant.
> So reading abcan is safe, but reading gotintr is not. Read first half
> before signal as 0, last half as -1. Then the switch on it fails.
Not on any machine ever built (for which a C translator exists).
OK, you're right, it's trivial, and I see that the configure script already
#defines sig_atomic_t to int if the system doesn't already define it. So your
suggested changes are harmless, go ahead and make them. If you're going to
that trouble, you should change gotintr to use an explicitly defined
contiguous range of values.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 6 months
Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no
[rearranging]
Howard Chu writes:
> The C standard defines "int" to be the most efficient machine word,
> and that is always atomic.
It does neither, that I can see. Among other things because "most
efficient" is not well-defined. E.g. by space or time? Efficient with
which operations? It's the recommended intent somewhere (the
Rationale?), but that must be subject to whatever other restrictions an
implementor faces. (16+ bits, backwards compatibility, etc.)
And the compiler can choose between an atomic and non-atomic operation,
even with volatile. Volatile guarantees a change is complete at a
sequence point. Signals need not arrive at sequence points. (C99
5.1.2.3p2,4. You can download the standard with amendments free at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.)
Otherwise the standard would not have needed to define sig_atomic_t.
> sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero
> immediately, one entry, or two entries after the signal occurs isn't
> going to make any difference.
Well, I don't see any reason not to use it when the standard says so and
the change is trivial, even if we don't know of a real-life failure.
(E.g. if the compiler detects that the variable will not legally change
and optimizes it away, or if it is being read during a signal which
changes it so the result of the non-atomic read is a trap
representation.)
> Likewise, there's no issue with gotintr/abcan. The signal handler
> isn't armed until the writes are complete. Therefore whether it can be
> read atomically or not inside the handler is irrelevant, the value is
> constant.
So reading abcan is safe, but reading gotintr is not. Read first half
before signal as 0, last half as -1. Then the switch on it fails.
--
Hallvard
15 years, 6 months
Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> Some non-atomic variables are used both outside and inside signal handlers:
>
> clients/tools/common.c:
> static int gotintr;
> static int abcan;
> servers/slapd/daemon.c:
> static volatile int waking;
> (used via WAKE_LISTENER in signal handler)
> slapd/slapcat.c:
> static int gotsig;
>
> They need to be volatile sig_atomic_t.
> That can be signed or unsigned char, so abcan must be set to some
> #define in range 0..127 instead of -1.
>
> Two more problems:
>
> WAKE_LISTENER will not be correct anyway since it does '++waking' (not
> atomic) and is called both inside and outside a signal handler.
> The !NO_THREADS version is OK.
>
> For that matter, behavior is only defined when the signal handler
> _writes_ a volatile sig_atomic_t, not when it _reads_ it:
> http://groups.google.no/group/comp.std.c/msg/d01196111ce93615
> Dunno what the problem is, or if it is worse than variables
> accessed by threads. I don't see anything to do about it either.
No. volatile is used in daemon.c, yes. It is not needed in clients/tools or
slapcat.
sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero
immediately, one entry, or two entries after the signal occurs isn't going to
make any difference.
Likewise, there's no issue with gotintr/abcan. The signal handler isn't armed
until the writes are complete. Therefore whether it can be read atomically or
not inside the handler is irrelevant, the value is constant.
And of course...
http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html#Atomi...
The C standard defines "int" to be the most efficient machine word, and that
is always atomic.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 6 months