FW: Notes about building OpenLDAP with MSVC

["Jon Leichter" <jon@symas.com>]

Hi all.

Howard Chu has recently submitted a lot of Mingw-related patches to OpenLDAP
on my behalf. Since Mingw affects Windows, I have also made sure that
building with MSVC still work. I came up with a set of notes that I sent to
Kurt. He has advised that I post the notes in this mailing list....

> -----Original Message-----
> From: Jon Leichter [mailto:jon@symas.com]
> Sent: Tuesday, December 18, 2001 1:42 PM
> To: Kurt D. Zeilenga
> Cc: Howard Chu
> Subject: Notes about building OpenLDAP with MSVC
>
> Hi Kurt.
>
> There are a bunch of things I'd like to relay to you about
> building with MSVC. I use MSVC 6. Thus, the first thing that
> happens to my project files is that they get converted from MSVC
> 5 to MSVC 6.
>
> In addition to the conversion, there are various changes that
> I've made to my own project files for various reasons. Now that I
> can build OpenLDAP in MSVC, I have done a diff between my project
> files and the ones in the OpenLDAP source tree to see what kinds
> of changes have occurred. This has turned up a lot of useful
> information that I will share with you.
>
> NOTE: My observations are based on differences in the various
> .dsp files. Because I haven't invested the time, I don't claim to
> fully understand how Microsoft internally uses these files, i.e.
> the meanings of various directives: ADD BASE CPP, ADD CPP,
> SUBTRACT, etc. My point is that I can't tell you necessarily how
> to change the various .dsp files. I strongly suggest that any
> changes be made in MSVC 5 and saved to the .dsp files.
>
> My notes follow:
>
> LBER_LIBRARY and LDAP_LIBRARY marcos
> ====================================
> The LBER_LIBRARY macro should be added to all configurations of
> the liblber project, and the LDAP_LIBRARY macro should be added
> to all configurations of the libldap and libldap_r projects.
>
> In MSVC 6, this can be done by going to the Project -> Settings
> property page, choosing the "C/C++" tab, choosing the
> "Preprocessor" item from the "Category" drop-down menu, and
> adding the macro to the "Preprocessor definitions" edit control.
> I suspect that this is done in a similar manner in MSVC 5. In the
> .dsp files, it involves adding a /D switch to the "correct" set
> of "ADD CPP" lines, whichever those may be.
>
> The need for these macros arises from the recent set of changes
> that I've made to ./include/ldap_cdefs.h. These macros have
> important implications if OpenLDAP is built with dynamic lber and
> ldap libraries. At this time, there is no .dsp file that does
> this. Thus, there is not an immediate need to get these macros
> added. However, they should be added for correctness.
>
> Note that if one wanted to build dyanmic lber and ldap libraries,
> he would not only have to configure a project to do so, but he
> would also have to set the (new) LDAP_LIBS_DYNAMIC macro in portable.h.
>
>
> Problems with Win32 DLL (Debug | Release) configurations
> ========================================================
> The Win32 DLL (Debug | Release) configurations are completely
> bogus. It looks like someone started to try and build a set of
> configurations that links with the dynamic MS C run-time
> libraries (i.e. MSVCRT.DLL and MSVCRTD.DLL). The problem is that
> the configurations are half-baked. The configurations have been
> applied only to the following projects: build, setup, dtest,
> liblber, and passwd. Without applying these configurations to the
> other projects, these configurations are useless. They should
> either be removed completely or properly finished.
>
> I believe that these projects should be removed completely and
> that their intended purpose be added to all projects as a
> default, i.e. all binaries should link with the dynamic C
> run-time libraries.
>
> As it stands now, binaries link with the static C run-time
> libraries. This is a problem for so many reasons: the MSVC 5
> static C run-time libraries are not the same as the MSVC 6 static
> libraries, and when one considers the multiple service packs that
> have been released for both versions of MSVC, one realizes that
> there is a potentially large set of different static C run-time
> libraries out there. The advantage to linking binaries with the
> dynamic C run-time libraries is that in the event somebody has
> old C run-time libraries, he needs to only update the dynamic
> library files instead of relinking OpenLDAP.
>
> In MSVC, the indicator for which C run-time library to link with
> is (brillantly) dictated by a switch to the compiler rather than
> the linker. This switch generates a #pragma directive during
> preprocessing, which the linker somehow notices and then uses to
> determine which C run-time library to link with.
>
> In MSVC 6, one can update the C run-time link option by going to
> the Project -> Settings property page, choosing the "C/C++" tab,
> choosing the "Code Generation" item from the "Categroy" drop-down
> menu, and choosing the appropriate option from the "Use run-time
> library" drop-down menu. The appropriate option will be
> "Multithreaded DLL" for Release configurations and "Debug
> Multithreaded DLL" for Debug configurations. I suspect that this
> is done in a similar manner in MSVC 5. In the .dsp files, this
> change involves changing instances of the /ML or /MT switches to
> /MD and the /MLd or /MTd switches to /MDd in the "correct" set of
> "ADD CPP" lines, whichever those may be.
>
> Microsoft only supplies multihtreaded dynamic C run-time
> libraries. There are no single-threaded dynamic libraries.
> However, I will claim that the single-threaded OpenLDAP binary
> can be built with the multithreaded C runtime library. I make
> this claim because the single-threaded version of OpenLDAP won't
> spawn any threads, and that is the real place that mutexes would
> need protection.
>
> As a by-the-way, the Win32 DLL configuration names could be
> construed as confusing. By looking at the project in depth, one
> realizes that it implies a link with the dynamic C run-time
> libraries. However, without research, one might have thought it
> was for dynamic lber and ldap libraries.
>
>
> Miscellaneous Project Inconsistencies
> ======================================
> The output location for the ldapmodify project is not set
> correctly. All binaries from other projects are built into
> <OL-root>/<config-name> directory, e.g. /usr/src/ldap/Debug.
> However, the ldapmodify project is set to build into
> <OL-root>/client/tools/<config-name>. In MSVC 6, this can be
> fixed by going to the Project -> Settings property page, choosing
> the "Link" tab, choosing the "General" item from the "Category"
> drop-down menu, and deleting the text in the "Output file name"
> edit control. By deleting this text and allowing MSVC to
> regenerate it based on other project settings, this issue will be
> fixed. I suspect that this is done in a similar manner in MSVC 5.
> I have no idea how to fix this in the .dsp file.
>
> There is a project called "ucgendat" whose .dsp file is called
> "ucgetdat.dsp". MSVC 6 did some interesting things with this, e.g
> the binary builds as "ucgetdat.exe". In UNIX, the name of the
> binary is "ucgendat". Thus, it seems that file name must be fixed.
>
> ====
>
> I hope these notes help.
>
> Jon
>