[Issue 10573] New: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps
https://bugs.openldap.org/show_bug.cgi?id=10573
Issue ID: 10573 Summary: OpenLDAP 2.7.0 fails to build with MSVC when preprocessing symbol version maps Product: OpenLDAP Version: 2.7.0 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs@openldap.org Reporter: openldap-msvc-673e3a64ee4f43@emalupe.com Target Milestone: ---
OpenLDAP 2.7.0 fails to build with MSVC while generating the liblber symbol version map. The regression appears to have been introduced by commit 8651f98a08c37bea6ee9be78acececd52bac66a0 (ITS#9739).
The new rules in libraries/liblber/Makefile.in and libraries/libldap/Makefile.in invoke:
$(CPP) -x c -o $@ $(LT_CPPFLAGS) $(srcdir)/$(SYMBOL_VERSION_SCRIPT).in
The -x c option is specific to GCC/Clang. When Autoconf's configured C preprocessor is MSVC (cl -E), cl ignores -x and treats the following c as an input filename:
cl : Command line warning D9002 : ignoring unknown option '-x' c1: fatal error C1083: Cannot open source file: 'c': No such file or directory make[2]: *** [Makefile:301: lber.map] Error 2
This was reproduced with OpenLDAP 2.7.0 and Visual Studio 2026/MSVC 14.51 on Windows. OpenLDAP 2.6.13 builds successfully with the same compiler setup because it does not preprocess these map files.
The same non-portable invocation is present in both the liblber and libldap map-generation rules and remains in the current OPENLDAP_REL_ENG_2_7 and master branches.
Could the hard-coded compiler language option be removed or replaced with a configure-detected, compiler-portable way to preprocess the .map.in files?
https://bugs.openldap.org/show_bug.cgi?id=10573
--- Comment #1 from Howard Chu hyc@openldap.org --- We don't support MSVC.
Patch welcome.
https://bugs.openldap.org/show_bug.cgi?id=10573
--- Comment #2 from OpenLDAP MSVC Reporter openldap-msvc-patch-0c5de43a5b6c@emalupe.com --- Created attachment 1193 --> https://bugs.openldap.org/attachment.cgi?id=1193&action=edit Make symbol map preprocessing portable
Attached a minimal patch that renames the two preprocessor templates to C-recognized filenames and writes preprocessor output through stdout, avoiding compiler-specific language and output options.
Tested with GCC 12.2 on Debian: both version maps were generated, both shared libraries linked, and OPENLDAP_2.200 was present in each library's version metadata.
Also tested with MSVC 14.51 on Windows for x86 and x64: both builds, installation checks, and generated artifacts completed successfully.
https://bugs.openldap.org/show_bug.cgi?id=10573
--- Comment #3 from Howard Chu hyc@openldap.org --- just to note, nothing on Windows uses these map files, so you could just omit them from the build rules entirely.
https://bugs.openldap.org/show_bug.cgi?id=10573
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.7.1
https://bugs.openldap.org/show_bug.cgi?id=10573
--- Comment #4 from Howard Chu hyc@openldap.org --- I looked at (In reply to OpenLDAP MSVC Reporter from comment #2)
Created attachment 1193 [details] Make symbol map preprocessing portable
Attached a minimal patch that renames the two preprocessor templates to C-recognized filenames and writes preprocessor output through stdout, avoiding compiler-specific language and output options.
Tested with GCC 12.2 on Debian: both version maps were generated, both shared libraries linked, and OPENLDAP_2.200 was present in each library's version metadata.
Also tested with MSVC 14.51 on Windows for x86 and x64: both builds, installation checks, and generated artifacts completed successfully.
I looked at an approach like this myself, previously.
Using `$(CPP) > $@` is problematic because it creates the output unconditionally, even if the $(CPP) hits an error. That's why we use `-o $@` which only produces the output file for a successful invocation.
This patch is not acceptable.
-
openldap-its＠openldap.org