Thread: Re: PostgreSQL CVS does not compile under Cygwin (was Re: Cygwin test ...)
Jason Tishler <jason@tishler.net> writes:
> - static PGSTD string IntToString(int);
> + PGSTD string IntToString(int);
This one is news to me. Please file a bug report about it. I have no
idea if that's the correct patch, though.
regards, tom lane
Tom, On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote: > Jason Tishler <jason@tishler.net> writes: > > - static PGSTD string IntToString(int); > > + PGSTD string IntToString(int); > > This one is news to me. Please file a bug report about it. I just converted an old Windows NT 4.0 machine to Linux. I will do a build there before submitting a bug report (if necessary). If it is a Cygwin thing, then... > I have no idea if that's the correct patch, though. Agreed, I was just trying to get the build to finish so I could run the regression test. ..I will try to come up with the correct patch. Jason
Tom, On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote: > Jason Tishler <jason@tishler.net> writes: > > - static PGSTD string IntToString(int); > > + PGSTD string IntToString(int); > > This one is news to me. Please file a bug report about it. I have no > idea if that's the correct patch, though. The first attachment is the root cause of this problem. If I revert pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++) builds cleanly again. I tried to build the Win32 stuff to see if the native libpq++ would build cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to be broken too... See second attachment. Note that I can build 7.1.2 under MSVC++. Has the procedure for 7.2 changed? Thanks, Jason
Attachment
Jason Tishler <jason@tishler.net> writes:
> The first attachment is the root cause of this problem. If I revert
> pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++)
> builds cleanly again.
Hmm. What does it mean to attach a DLLIMPORT label to a class, anyway?
Is it meaningful to do so on Cygwin (as opposed to bare WIN32)?
> I tried to build the Win32 stuff to see if the native libpq++ would build
> cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to
> be broken too... See second attachment. Note that I can build 7.1.2
> under MSVC++. Has the procedure for 7.2 changed?
No, but libpq's CVS tip is busted on WIN32. See ongoing discussions
about fixing errno and strerror() handling on WIN32. One way or another
we'll have it fixed soon.
BTW, I have no idea whether libpq++ (as opposed to libpq) has ever built
on WIN32 in the past. The changes you are mentioning seem to be a
recent attempt to make it do so, which evidently needs further thought.
regards, tom lane
I have already applied this fix:
revision 1.12
date: 2001/07/11 22:12:43; author: momjian; state: Exp; lines: +2 -2
Libpq++ fixes for Win32 compile.
Christian Ullrich
> Tom,
>
> On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> > Jason Tishler <jason@tishler.net> writes:
> > > - static PGSTD string IntToString(int);
> > > + PGSTD string IntToString(int);
> >
> > This one is news to me. Please file a bug report about it. I have no
> > idea if that's the correct patch, though.
>
> The first attachment is the root cause of this problem. If I revert
> pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++)
> builds cleanly again.
>
> I tried to build the Win32 stuff to see if the native libpq++ would build
> cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to
> be broken too... See second attachment. Note that I can build 7.1.2
> under MSVC++. Has the procedure for 7.2 changed?
>
> Thanks,
> Jason
>
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
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, Pennsylvania 19026
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Tom,
>
> On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> > Jason Tishler <jason@tishler.net> writes:
> > > - static PGSTD string IntToString(int);
> > > + PGSTD string IntToString(int);
> >
> > This one is news to me. Please file a bug report about it. I have no
> > idea if that's the correct patch, though.
>
> The first attachment is the root cause of this problem. If I revert
> pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++)
> builds cleanly again.
>
> I tried to build the Win32 stuff to see if the native libpq++ would build
> cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to
> be broken too... See second attachment. Note that I can build 7.1.2
> under MSVC++. Has the procedure for 7.2 changed?
>
> Thanks,
> Jason
>
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
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, Pennsylvania 19026
> The first attachment is the root cause of this problem. If I revert > pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++) > builds cleanly again. > > I tried to build the Win32 stuff to see if the native libpq++ would build > cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to > be broken too... See second attachment. Note that I can build 7.1.2 > under MSVC++. Has the procedure for 7.2 changed? OK, have we resolved what should be in pgconnection.h? -- 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, Pennsylvania 19026
Bruce, On Fri, Aug 24, 2001 at 12:52:54PM -0400, Bruce Momjian wrote: > > The first attachment is the root cause of this problem. If I revert > > pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++) > > builds cleanly again. > > > > I tried to build the Win32 stuff to see if the native libpq++ would build > > cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to > > be broken too... See second attachment. Note that I can build 7.1.2 > > under MSVC++. Has the procedure for 7.2 changed? > > OK, have we resolved what should be in pgconnection.h? I just did a cvs update to try again to verify whether or not the Win32 libpq++ will build without the DLLIMPORT in pgconnection.h. Unfortunately, I still cannot build even the Win32 libpq. See the first attachment for my nmake output. Does the latest CVS really build under MSVC++? Seems like md5.c is missing from win32.mak... BTW, jdbc does not seem to build anymore either. See the second attachment. Thanks, Jason
Attachment
> Bruce, > > On Fri, Aug 24, 2001 at 12:52:54PM -0400, Bruce Momjian wrote: > > > The first attachment is the root cause of this problem. If I revert > > > pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++) > > > builds cleanly again. > > > > > > I tried to build the Win32 stuff to see if the native libpq++ would build > > > cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to > > > be broken too... See second attachment. Note that I can build 7.1.2 > > > under MSVC++. Has the procedure for 7.2 changed? > > > > OK, have we resolved what should be in pgconnection.h? > > I just did a cvs update to try again to verify whether or not the > Win32 libpq++ will build without the DLLIMPORT in pgconnection.h. > > Unfortunately, I still cannot build even the Win32 libpq. See the > first attachment for my nmake output. Does the latest CVS really build > under MSVC++? Seems like md5.c is missing from win32.mak... OK, I just added md5.c to Win32.mak. This brings up another question. dllist.c and md5.c are 'ln -s' from their homes to libpq directory, while of course for win32.make we access them in their original locations. Is there any reason to symlink them rather than just refering to them in their original locations? > > BTW, jdbc does not seem to build anymore either. See the second > attachment. Yep, I threw out an email to the jdbc list an hour ago. -- 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, Pennsylvania 19026
Can someone research this and figure out what the proper solution for this is? Seems we are going around in circles if we keep adding/removing DLLIMPORT. > > On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote: > > Jason Tishler <jason@tishler.net> writes: > > > - static PGSTD string IntToString(int); > > > + PGSTD string IntToString(int); > > > > This one is news to me. Please file a bug report about it. I have no > > idea if that's the correct patch, though. > > The first attachment is the root cause of this problem. If I revert > pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++) > builds cleanly again. [ Removal of DLLIMPORT ] > > I tried to build the Win32 stuff to see if the native libpq++ would build > cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to > be broken too... See second attachment. Note that I can build 7.1.2 > under MSVC++. Has the procedure for 7.2 changed? > > Thanks, > Jason > [ Attachment, skipping... ] [ Attachment, skipping... ] -- 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, Pennsylvania 19026
Bruce,
On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote:
> Can someone research this and figure out what the proper solution for
> this is? Seems we are going around in circles if we keep
> adding/removing DLLIMPORT.
I believe that the attached patch is the correct solution -- I apologize
for the gyrations. With the attached patch, Cygwin libpq++ builds
cleanly again. The root cause was that DLLIMPORT was defaulting to
__declspec(dllimport) since BUILDING_DLL was *not* defined when building
the libpq++ DLL.
Unfortunately, to test my patch requires changing the following makefile:
src/interfaces/libpq++/examples/Makefile
and the #includes in all of the *.cc to build against the source tree
instead of the following hardcoded installation directory structure:
/usr/local/pgsql
I was able to manually build
src/interfaces/libpq++/examples/testlibpq0.exe
against my Cygwin libpq++ without errors. However, I have not tried to
actually test testlibpq0.exe.
Is this sufficient? Or, do you want me to clean up libpq++/examples too?
(Or, is it silly to even ask? :,)) Let me know how you want to proceed and
I will submit a patch to pgsql-patches.
Thanks,
Jason
Attachment
Frankly, I have no idea what this stuff needs to get it to work. I will
put this in the patch queue and please send over whatever else you think
will help.
The girations are fine. This is the nature of porting.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> Bruce,
>
> On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote:
> > Can someone research this and figure out what the proper solution for
> > this is? Seems we are going around in circles if we keep
> > adding/removing DLLIMPORT.
>
> I believe that the attached patch is the correct solution -- I apologize
> for the gyrations. With the attached patch, Cygwin libpq++ builds
> cleanly again. The root cause was that DLLIMPORT was defaulting to
> __declspec(dllimport) since BUILDING_DLL was *not* defined when building
> the libpq++ DLL.
>
> Unfortunately, to test my patch requires changing the following makefile:
>
> src/interfaces/libpq++/examples/Makefile
>
> and the #includes in all of the *.cc to build against the source tree
> instead of the following hardcoded installation directory structure:
>
> /usr/local/pgsql
>
> I was able to manually build
>
> src/interfaces/libpq++/examples/testlibpq0.exe
>
> against my Cygwin libpq++ without errors. However, I have not tried to
> actually test testlibpq0.exe.
>
> Is this sufficient? Or, do you want me to clean up libpq++/examples too?
> (Or, is it silly to even ask? :,)) Let me know how you want to proceed and
> I will submit a patch to pgsql-patches.
>
> Thanks,
> Jason
[ Attachment, skipping... ]
--
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, Pennsylvania 19026
Bruce, On Fri, Aug 24, 2001 at 11:01:09PM -0400, Bruce Momjian wrote: > This brings up another question. > dllist.c and md5.c are 'ln -s' from their homes to libpq directory, > while of course for win32.make we access them in their original > locations. Is there any reason to symlink them rather than just > refering to them in their original locations? Sorry, I don't feel qualified to answer the above. How about Peter E? Jason
Bruce, On Sat, Aug 25, 2001 at 11:09:58PM -0400, Bruce Momjian wrote: > Frankly, I have no idea what this stuff needs to get it to work. I will > put this in the patch queue and please send over whatever else you think > will help. > > [snip] > > > Unfortunately, to test my patch requires changing the following makefile: > > > > src/interfaces/libpq++/examples/Makefile > > > > and the #includes in all of the *.cc to build against the source tree > > instead of the following hardcoded installation directory structure: > > > > /usr/local/pgsql > > > > I was able to manually build > > > > src/interfaces/libpq++/examples/testlibpq0.exe > > > > against my Cygwin libpq++ without errors. However, I have not tried to > > actually test testlibpq0.exe. > > > > Is this sufficient? I just tested testlibpq0.exe and it functioned as expected, so I am very confident of my latest patch. Additionally, it should not affect any platform (including Win32) except for Cygwin. > > Or, do you want me to clean up libpq++/examples too? > > (Or, is it silly to even ask? :,)) Let me know how you want to proceed and > > I will submit a patch to pgsql-patches. Sorry, but I'm going to punt on the above. libpq++/examples really, really wants to build against an installation tree instead of a source tree. Jason
Patch applied. Thanks. Let me know if you have more patches to be applied. > Bruce, > > On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote: > > Can someone research this and figure out what the proper solution for > > this is? Seems we are going around in circles if we keep > > adding/removing DLLIMPORT. > > I believe that the attached patch is the correct solution -- I apologize > for the gyrations. With the attached patch, Cygwin libpq++ builds > cleanly again. The root cause was that DLLIMPORT was defaulting to > __declspec(dllimport) since BUILDING_DLL was *not* defined when building > the libpq++ DLL. > > Unfortunately, to test my patch requires changing the following makefile: > > src/interfaces/libpq++/examples/Makefile > > and the #includes in all of the *.cc to build against the source tree > instead of the following hardcoded installation directory structure: > > /usr/local/pgsql > > I was able to manually build > > src/interfaces/libpq++/examples/testlibpq0.exe > > against my Cygwin libpq++ without errors. However, I have not tried to > actually test testlibpq0.exe. > > Is this sufficient? Or, do you want me to clean up libpq++/examples too? > (Or, is it silly to even ask? :,)) Let me know how you want to proceed and > I will submit a patch to pgsql-patches. > > Thanks, > Jason [ Attachment, skipping... ] -- 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, Pennsylvania 19026
Bruce, On Wed, Sep 05, 2001 at 10:59:55PM -0400, Bruce Momjian wrote: > Patch applied. Thanks. You are welcome. > Let me know if you have more patches to be applied. I currently have no Cygwin specific code patches queued up. However, I still owe you a FAQ_MSWIN documentation patch. Thanks, Jason