https://bugs.openldap.org/show_bug.cgi?id=10500

Issue ID: 10500 Summary: back-ldif/ldif.c crc32() should be static — collides with zlib's crc32 at link time Product: OpenLDAP Version: 2.6.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs@openldap.org Reporter: ionutn@gmail.com Target Milestone: ---

In servers/slapd/back-ldif/ldif.c, the helper crc32() (defined at line 393 in 2.6.13) is declared with external linkage:

unsigned int crc32(const void *vbuf, int len) { ... }

It is only used inside that file (lines 470 and 511). It has the same name as zlib's public crc32() but a completely different signature and semantics — it's an internal helper for hashing LDIF entry filenames, unrelated to zlib's CRC-32-IEEE-802.3.

This is a latent symbol collision that has been present for many years. Until recently, ld silently resolved zlib's crc32 references (from inflate.c.o / deflate.c.o, transitively pulled in by libcrypto) against back-ldif's crc32 — because back-ldif is linked first — and libz.a's crc32.c.o was never pulled in.

NEWLY EXPOSED BY zlib 1.3.2: zlib 1.3.2's deflate.c added an internal call to crc32_z, a symbol defined only in libz.a(crc32.c.o). When slapd is linked against libssl/libcrypto + libz.a, ld now has to pull in crc32.c.o to satisfy crc32_z, which brings the public crc32 along — colliding with back-ldif's:

libz.a(crc32.c.o): In function `crc32': zlib-1.3.2/crc32.c:950: multiple definition of `crc32' libbackends.a(ldifldif.o):.../back-ldif/ldif.c:399: first defined here collect2: error: ld returned 1 exit status

Reproduction: any build that links slapd (or anything pulling in libbackends.a) together with libssl + libcrypto + zlib 1.3.2's libz.a. Hit on Linux/aarch64 and Linux/x86_64 with GCC 8.5 + ld from binutils.

Suggested fix (one keyword) ---------------------------

Mark the function static:

-unsigned int +static unsigned int crc32(const void *vbuf, int len)

Tested locally on 2.6.13: slapd builds cleanly against zlib 1.3.2 with this change. No behaviour change since the function is only ever called from within ldif.c.

Versions --------

- Confirmed: 2.6.13 (latest) and 2.6.10. The code path appears identical going back many releases. - ld behaviour change is triggered specifically by zlib 1.3.2 (released Feb 2026).