Re: Building Windows Server Extensions Using VC++ 2005

> > Um, is WIN32_CLIENT_ONLY really defined when you're
> building a backend
> > extension? That seems wrong.
>
> Well, it is defined:
>
> #if defined(_MSC_VER) || defined(__BORLANDC__)
> #define WIN32_CLIENT_ONLY
> #endif

Oops. I obviously forgot all about that :-)

> > The whole problem seems to be the using of the pg_config.h
> from mingw
> > when building with msvc. Why not just use the correct
> pg_config.h in
> > the first place? What happens then?
>
> We can't generate a pg_config.h for WIN32_CLIENT_ONLY because
> there is no shell build environment.

Right. But we have include/pg_config.h.win32 which is supposed to be
used in this case. The win32 native build of the backend will copy that
file into pg_config.h.

The problem here is that the backend is built with mingw but the
extension with msvc. If you'd start from fresh, there would be no
pg_config.h to include. The pg_config.h.win32 file is supposed to be
preset for the MSVC environment (which is the same as borland on win32,
but different from mingw).

> > IIRC, there were other problems building extensions with
> MSVC - such
> > as struct alignment and stuff. Not sure if that has been taken care
> > of? If not, there really isn't much point in fixing the
> headers alone
> > :-)
>
> Well, I figure alignment would be based on the CPU, not the
> compiler, but I might be wrong.

Um. struct packing? I don't remember exactly what it was, but IIRC it
was something.

> I added the capability, and why it was added, so if we decide
> the idea is a failure, we know what to remove.

Right. I've never tried using msvc for a server extension, and the
general answer has always been "don't do it". But it may well have
changed now.

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> The problem here is that the backend is built with mingw but the
> extension with msvc.

I don't think that it's very reasonable to expect that to work.
The two compilers very likely have different rules for struct
packing, to take just the first gotcha. Maybe they are compatible
enough that it will work, but if it does not we cannot fix it.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> > The problem here is that the backend is built with mingw but the
> > extension with msvc.
>
> I don't think that it's very reasonable to expect that to work.
> The two compilers very likely have different rules for struct
> packing, to take just the first gotcha. Maybe they are compatible
> enough that it will work, but if it does not we cannot fix it.

Well that sort of stuff is supposed to be covered by the ABI. Consider that if
it didn't then you wouldn't be able to use any of the standard libraries
without recompiling them for each compiler since a number of standard library
APIs depend on structs like timeval or stat.

I'm not saying there aren't risks, but in theory it's supposed to work.

--
greg

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Well that sort of stuff is supposed to be covered by the ABI. Consider that if
> it didn't then you wouldn't be able to use any of the standard libraries
> without recompiling them for each compiler since a number of standard library
> APIs depend on structs like timeval or stat.

Maybe. My experience with these sorts of problems is fairly old (hard
lessons from libjpeg development in the mid-90s), but what I learned at
the time is that all the standard Unix library interfaces are carefully
designed to be fairly impervious to struct padding rules (eg, all the
fields are "int", or at least all the same size), and so you can get
apparent interoperability between compilers that don't agree on these
rules. Meanwhile, Microsoft, who never met a feature they didn't like,
invented a foot-gun called #pragma pack, and then had to fix all their
headers to nail down the pack setting. That in turn masks compatibility
issues on that platform, but only if you're willing to #pragma-ify all
of your own headers too.

In short, I don't trust anybody on this issue. I have the scars to
remind me why not.

regards, tom lane

Hi everyone,

Thanks for the feedback. The reason for building extensions with MSVC
on windows is to get access to the Micrsoft debugging tools since as far
as I can see MingW/GDB cannot debug dynamically loaded dlls on the
Windows platform (or at least I haven't succeeded at doing it).

Anyway, with the few minor tweaks mentioned this seems to work fine. I
guess I would be surprised if it didn't since MinGW is commonly used for
both creating and using DLLs on the Windows platform that integrate with
programs and dlls built with VC++. Other examples that work fine are
building extensions for Python and Ruby using MingW, when both runtimes
are built with VC++ (so the opposite case). Of course, this
compatibility might just be limited to the MinGW / VC++ combination, but
that's all you need for this to work.

Charlie

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>
>> The problem here is that the backend is built with mingw but the
>> extension with msvc.
>>
>
> I don't think that it's very reasonable to expect that to work.
> The two compilers very likely have different rules for struct
> packing, to take just the first gotcha. Maybe they are compatible
> enough that it will work, but if it does not we cannot fix it.
>
> regards, tom lane
>
>
>

Charlie Savage wrote:
> Hi everyone,
>
> Thanks for the feedback. The reason for building extensions with MSVC
> on windows is to get access to the Micrsoft debugging tools since as far
> as I can see MingW/GDB cannot debug dynamically loaded dlls on the
> Windows platform (or at least I haven't succeeded at doing it).
>
> Anyway, with the few minor tweaks mentioned this seems to work fine. I
> guess I would be surprised if it didn't since MinGW is commonly used for
> both creating and using DLLs on the Windows platform that integrate with
> programs and dlls built with VC++. Other examples that work fine are
> building extensions for Python and Ruby using MingW, when both runtimes
> are built with VC++ (so the opposite case). Of course, this
> compatibility might just be limited to the MinGW / VC++ combination, but
> that's all you need for this to work.

OK, I improved the STRINGS_H macro check and added DLLIMPORT in case
Win32 users don't export everything. Added comments. This is all 8.2
stuff.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +