Thread: libpq++ on Windows
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"
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
* 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"
* 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
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
* 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"
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
* 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
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
* 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"
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
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