OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Build/4825
Full headers

From: markus.duft@salomon.at
Subject: Native Win32 build with WGCC/Interix
Compose comment
Download message
State:
1 replies: 1
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 31 Jan 2007 13:09:54 GMT
From: markus.duft@salomon.at
To: openldap-its@OpenLDAP.org
Subject: Native Win32 build with WGCC/Interix
Full_Name: Markus Duft
Version: 2.3.32
OS: Windows XP
URL: ftp://ftp.openldap.org/incoming/markus.duft-31.01.2007.patch
Submission from: (NULL) (193.186.16.254)


Hey there. i have a patch for v2.3.32 that allowes building openldap using wgcc
(interix-wgcc.sourceforge.net).

The result is a native win32 binary (without dependencies to any cygwin.dll or
anything like it)

benefits:

 * fast compiler (cl.exe)
 * native win32, no overheads for big wrappers
   (there is a small wrapper though ;o) but thats statically linked (pxwc))
 * debugable with Visual Studio (very cool)

thats it, i'll write a FAQ for this ;o)

P.S.: i know the patch is not perfect, but as a first thing it will do. there
will be a second version for sure that may be nicer, so it can be incorporated
with the official sources (if wanted...)

Cheers, Markus


Reply 1

Resend
From: Howard Chu <openldap-its@OpenLDAP.org>
To: markus.duft@salomon.at
Subject: Re: Native Win32 build with WGCC/Interix (ITS#4825)
Date: Fri Jun  8 12:01:12 2007
I have not tested this patch, but it does not appear to be correct.

In ldap_cdefs.h, you should not be testing the PIC macro since that controls
whether the current source file is being built as position-independent. The
macro you actually need to test is LDAP_LIBS_DYNAMIC, just as the regular WIN32
case tests. Note that the current macros work fine for both MSVC and MinGW/gcc;
I don't see why you've chosen to change the LBER_F definitions for your wgcc.

Likewise, your hack to portable.hin should not be necessary, as all of the
places that use sockets or timevals already include the appropriate header
files.

The patch to ure.h seems unnecessary, since the file exists at both locations
(the original, and via symlink).

Finally, unless you're using a flag to force all symbols to be exported, I think
omitting slapd.exp in the slapd/Makefile.in is a mistake.

Really, the comments in ldap_cdefs.h are pretty explicit about why each piece of
the current Windows support is as it is. Your patch seems to preclude some of
the combinations of DLL/static linking that we went to great pains to support.

For the include/Makefile.in it would probably have made more sense to define a
WINPATH macro to either "cygpath -w" or "unixpath2win" and use that, rather than
repeating all of the SED invocations.

These days I wonder whether it wouldn't be smarter to just remove all of the
special casing for braindead backslash directory separators. Since Windows now
supports forward slashes everywhere, it would make life easier to just use
forward slashes consistently throughout.


Followup 1

Download message
Subject: RE: Native Win32 build with WGCC/Interix (ITS#4825)
Date: Wed, 13 Jun 2007 08:47:55 +0200
From: "Duft Markus" <Markus.Duft@salomon.at>
To: "Howard Chu" <openldap-its@OpenLDAP.org>
Hi!

First thanks for reviewing the patch!

Howard Chu <mailto:openldap-its@OpenLDAP.org> wrote:
> I have not tested this patch, but it does not appear to be correct.
> 
> In ldap_cdefs.h, you should not be testing the PIC macro since that
> controls whether the current source file is being built as
> position-independent. The macro you actually need to test is
> LDAP_LIBS_DYNAMIC, just as the regular WIN32 case tests. Note that
> the current macros work fine for both MSVC and MinGW/gcc; I don't see
> why you've chosen to change the LBER_F definitions for your wgcc. 

Uh.. I'd have to look into that again ;o) Still this works fine since
some time now, and the libraries are under heavy usage at our company...

> 
> Likewise, your hack to portable.hin should not be necessary, as all
> of the places that use sockets or timevals already include the
> appropriate header files.

Again, i'd have to look at this again...

> 
> The patch to ure.h seems unnecessary, since the file exists at both
> locations (the original, and via symlink).

Smylinks are not supported when windows building on interix ;o// This
caused some troubles as far as i remember.

> 
> Finally, unless you're using a flag to force all symbols to be
> exported, I think omitting slapd.exp in the slapd/Makefile.in is a
> mistake. 

WGCC automatically exports/imports correctly.

> 
> Really, the comments in ldap_cdefs.h are pretty explicit about why
> each piece of the current Windows support is as it is. Your patch
> seems to preclude some of the combinations of DLL/static linking that
> we went to great pains to support. 

WGCC claims to support (with this patch) *all* possible static/shared
combinations (without pain ;o)). WGCC generates code to support static
libraries, even if it was compiled like a shared library (with
__declspec(dllimport)'s, etc.), so most of the painfull stuff is not
needed. On the other hand to support *all* configurations, one needs to
allway dllimport, so both shared and static work ...

> 
> For the include/Makefile.in it would probably have made more sense to
> define a WINPATH macro to either "cygpath -w" or "unixpath2win" and
> use that, rather than repeating all of the SED invocations.

Yes, it would have been better, but it's a long time since i wrote the
patch, and now i'd propably do more things differently ;o)

> 
> These days I wonder whether it wouldn't be smarter to just remove all
> of the special casing for braindead backslash directory separators.
> Since Windows now supports forward slashes everywhere, it would make
> life easier to just use forward slashes consistently throughout.

Would be cool, but still path handling functions from windows return
paths with backslashes, so those would need to be handled too..

Cheers, Markus

-- 
20. Juni 2007 
Salomon Automation am 2. Schweizerischen Supply Chain Management Forum der GS1
Schweiz in Baden. Tagungsort: Trafohalle Baden, Schweiz

20. Juni 2007
MoveRetail-Handelstag, Hamburg
Die MoveRetail Partner, Salomon Automation, maxess systemhaus, Superdata,
Remira, POS Systemhaus und Mosaic veranstalten den 1. MoveRetail-Handelstag.
Tagungsort: Steigenberger Hotel, Hamburg

28. Juni 2007
6. BVL Logistiktag Steiermark in der WAMAS City, Friesach bei Graz
"Trends in der Logistik ": hoch automatisierte Systeme, mobile Waren- und
Leergutverfolgung im Lebensmittelhandel und Generalunternehmerschaft versus
Einzelprojekte.
 
Termin: 28. Juni 2007, ab 15.00 Uhr
Ort: Salomon Automation, Friesachstra?e 15, 8114 Friesach bei Graz, Osterreich
 

Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz




Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org