Thread: libpq++ on Windows

libpq++ on Windows

From
Christian Ullrich
Date:
Hello!

I've read a lot about major changes in libpq++ in 7.2 or later.
As I just got it to compile and work (at least as far as
connecting and executing a single query, at which point I stopped
testing) with VC++ 6, I would like to know if the future code will
still build and run with Microsoft's compilers.

BTW, why isn't libpq++ built from win32.mak, along with libpq?

-- 
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"


Re: libpq++ on Windows

From
jtv
Date:
On Sat, Jun 30, 2001 at 07:37:30PM +0200, Christian Ullrich wrote:
> 
> I've read a lot about major changes in libpq++ in 7.2 or later.

I'm planning a completely new front-end that comes a lot closer to the way
libraries want to be in C++ (eg. intense use of templates, and conformance
to the STL).  The main obstacle ATM is getting Debian up to speed on my
Powerbook, esp. its modem.


> As I just got it to compile and work (at least as far as
> connecting and executing a single query, at which point I stopped
> testing) with VC++ 6, I would like to know if the future code will
> still build and run with Microsoft's compilers.
Hopefully.  But as always, your feedback will be essential to make that
possible!

Of course it would depend on exactly which version of the compiler you're
interested in.  IIRC version 5 has some bugs that might be so difficult to
work around as to effectively require a separate code base and interface.
That would be a good reason to still maintain the existing library as well,
I think.


Jeroen



Re: libpq++ on Windows

From
Christian Ullrich
Date:
* Peter Eisentraut wrote on Sunday, 01.07.2001:

> Christian Ullrich writes:
> 
> > BTW, why isn't libpq++ built from win32.mak, along with libpq?
> 
> Because no one has invested the effort to make that happen, yet.  If you
> know how to write these .mak files then feel free to share your findings.

I will look into it. It should be enough to get it to work via the
GUI and export a Makefile (I wonder how they dare to call these
things Makefiles). I'll report back later today, European time.

-- 
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"


Re: libpq++ on Windows

From
Christian Ullrich
Date:
* Christian Ullrich wrote on Sunday, 2001-07-01:

> I will look into it. It should be enough to get it to work via the
> GUI and export a Makefile (I wonder how they dare to call these

Well, I found it was easier to adapt the win32.mak for libpq.
So here is the patch.

Notes:

- The additions to config.h.in and config.h.win32 are not very elegant,
  especially config.h.in. But I need to export the classes, and that's
  the only way to go.

- The static library doesn't work. It asserts while connecting.
  I've tried to find the bug, but failed miserably.
  WSAStartup() returned success, so that shouldn't be the reason.

- The filenames are constructed like libpq's:
  - libpq++.dll: The working DLL.
  - libpq++.lib. The broken static library.
  - libpq++dll.lib: The DLL's import library.

Goodbye.

--
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"

Attachment

Re: libpq++ on Windows

From
Peter Eisentraut
Date:
Christian Ullrich writes:

> - The additions to config.h.in and config.h.win32 are not very elegant,
>   especially config.h.in. But I need to export the classes, and that's
>   the only way to go.

Why not put the addition to config.h.in into config.h.win32?  When doing a
native Win32 build config.h.in isn't used anyway.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: libpq++ on Windows

From
Christian Ullrich
Date:
* Peter Eisentraut wrote on Sunday, 2001-07-01:

> Christian Ullrich writes:
> 
> > - The additions to config.h.in and config.h.win32 are not very elegant,
> >   especially config.h.in. But I need to export the classes, and that's
> >   the only way to go.
> 
> Why not put the addition to config.h.in into config.h.win32?  When doing a
> native Win32 build config.h.in isn't used anyway.

Because the '#define DLLAPI' in config.h.in -- from which the 
config.h for Unix and Cygwin/Win32 builds is generated -- is 
necessary to make the compiler happy about the modifications
to the class declarations.

When building the DLL with MSVC I need to export the classes,
and I don't think I can do that with .DEF files, so I must
put __declspec(dllexport) into the class declarations. But
because gcc will choke on them, I define them empty for gcc builds.

-- 
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"


Re: libpq++ on Windows

From
Tom Lane
Date:
Christian Ullrich <chris@chrullrich.de> writes:
> * Peter Eisentraut wrote on Sunday, 2001-07-01:
>> Why not put the addition to config.h.in into config.h.win32?  When doing a
>> native Win32 build config.h.in isn't used anyway.

> Because the '#define DLLAPI' in config.h.in -- from which the 
> config.h for Unix and Cygwin/Win32 builds is generated -- is 
> necessary to make the compiler happy about the modifications
> to the class declarations.

config.h.in is absolutely NOT the right place for platform-specific
defines.

I'd put this in the same category as DLLIMPORT, which is in c.h
(and just as ugly an example of Microsoft cultural imperialism,
but I suppose there's no point in arguing about it).
        regards, tom lane


Re: libpq++ on Windows

From
Christian Ullrich
Date:
* Tom Lane wrote on Monday, 2001-07-02:

> config.h.in is absolutely NOT the right place for platform-specific
> defines.
>
> I'd put this in the same category as DLLIMPORT, which is in c.h
> (and just as ugly an example of Microsoft cultural imperialism,
> but I suppose there's no point in arguing about it).

Thanks for the help. You know, if I had looked into c.h in the first
place, I might just have found that out myself.
Here's another patch. It extends the DLLIMPORT declaration
block and allows me to use that same macro in the class headers.
I think it is correctly used there.

--
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"

Attachment

Re: libpq++ on Windows

From
Peter Eisentraut
Date:
Christian Ullrich writes:

> Because the '#define DLLAPI' in config.h.in -- from which the
> config.h for Unix and Cygwin/Win32 builds is generated -- is
> necessary to make the compiler happy about the modifications
> to the class declarations.

Any given build will use exactly one of config.h.in or config.h.win32, so
you should decide which one you want to use.  Since so far native Win32
builds have used config.h.win32 (by manually copying it to config.h, and
not running configure at all), this is what you should do.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: libpq++ on Windows

From
Christian Ullrich
Date:
* Peter Eisentraut wrote on Monday, 2001-07-02:

> Any given build will use exactly one of config.h.in or config.h.win32, so
> you should decide which one you want to use.  Since so far native Win32
> builds have used config.h.win32 (by manually copying it to config.h, and
> not running configure at all), this is what you should do.

The new symbol "DLLAPI" I introduced is seen by any compiler, 
Win32 or not. So I had to make that symbol known to any compiler, 
Win32 or not (more precisely, to have the preprocessor remove it on
platforms other than Win32).

But because Tom Lane told me a better way of doing it, I have already
removed the changes to both config.h.in and (partly) config.h.win32.

-- 
Christian Ullrich             Registrierter Linux-User #125183

"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"


Re: libpq++ on Windows

From
Peter Eisentraut
Date:
Christian Ullrich writes:

> BTW, why isn't libpq++ built from win32.mak, along with libpq?

Because no one has invested the effort to make that happen, yet.  If you
know how to write these .mak files then feel free to share your findings.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: libpq++ on Windows

From
Bruce Momjian
Date:
Thanks.  Patch applied.


> * Tom Lane wrote on Monday, 2001-07-02:
> 
> > config.h.in is absolutely NOT the right place for platform-specific
> > defines.
> > 
> > I'd put this in the same category as DLLIMPORT, which is in c.h
> > (and just as ugly an example of Microsoft cultural imperialism,
> > but I suppose there's no point in arguing about it).
> 
> Thanks for the help. You know, if I had looked into c.h in the first
> place, I might just have found that out myself.
> Here's another patch. It extends the DLLIMPORT declaration
> block and allows me to use that same macro in the class headers.
> I think it is correctly used there.
> 
> -- 
> Christian Ullrich             Registrierter Linux-User #125183
> 
> "Sie k?nnen nach R'ed'mond fliegen -- aber Sie werden sterben"

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026