Thread

buildfarm breakage

Andrew Dunstan <andrew@dunslane.net> — 2010-02-09T01:07:00Z

It looks like some recent patches have broken a couple of things on the 
buildfarm.

Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a 
recent RADIUS support fix. Looks like we might need to include win32.h 
in there.

MSVC builds are broken from a missing _isnan function on the ECPG tests. 
Do we need to link in a math lib or something there?

Our Solaris *moth members seem to have stopped building. Have we lost them?

cheers

andrew

Re: buildfarm breakage

Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-09T01:20:04Z

Andrew Dunstan <andrew@dunslane.net> writes:
> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a 
> recent RADIUS support fix. Looks like we might need to include win32.h 
> in there.

That was discussed already.  I assume Magnus is going to address it
as soon as he gets back from FOSDEM.

> MSVC builds are broken from a missing _isnan function on the ECPG tests. 
> Do we need to link in a math lib or something there?

It looks to me like the problem is that that test is being compiled
without benefit of any platform-dependent code whatsoever.  In the rest
of the system, isnan and isinf work on WIN32 because the compiles can
see the macro definitions in port/win32.h.  nan_test is apparently not
including that.  I'm not sure of Michael's plan for portability of
these test cases --- if he doesn't want to include c.h or something
close to that, I think the nan test has to go away.

> Our Solaris *moth members seem to have stopped building. Have we lost them?

They're not *all* dead, but it sure looks like Oracle scaled that lab
way back the moment they owned it.  I'm surprised any of them are still
alive :-(

			regards, tom lane

Re: buildfarm breakage

Mark Wong <markwkm@gmail.com> — 2010-02-09T01:32:17Z

On Mon, Feb 8, 2010 at 5:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Our Solaris *moth members seem to have stopped building. Have we lost them?
>
> They're not *all* dead, but it sure looks like Oracle scaled that lab
> way back the moment they owned it.  I'm surprised any of them are still
> alive :-(

We still have a T2000 system with solaris on it.  It was not in the
buildfarm because it was felt this configuration was already covered.
Let me know if we want to set it up for the buildfarm.

Regards,
Mark

Re: buildfarm breakage

Michael Meskes <meskes@postgresql.org> — 2010-02-09T08:39:50Z

On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
> > MSVC builds are broken from a missing _isnan function on the ECPG tests. 
> > Do we need to link in a math lib or something there?
> 
> It looks to me like the problem is that that test is being compiled
> without benefit of any platform-dependent code whatsoever.  In the rest
> of the system, isnan and isinf work on WIN32 because the compiles can
> see the macro definitions in port/win32.h.  nan_test is apparently not
> including that.  I'm not sure of Michael's plan for portability of
> these test cases --- if he doesn't want to include c.h or something
> close to that, I think the nan test has to go away.

Actually I was hoping someone with some Windows experience would take a look at
it or Zoltan would come up with a fix, after all it was his addition. :-)

Looking at the portability header file it appears that isnan/isinf are only one
line defines, so it doesn't look like a major problem adding these. I will try
fixing this, but bear with me as I have to use the buildfarm for testing. I
don't have a Windows build environment. 

If someone is willing to run a test on Windows for me, please tell me.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: buildfarm breakage

Dave Page <dpage@pgadmin.org> — 2010-02-09T08:54:15Z

On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes <meskes@postgresql.org> wrote:
> Actually I was hoping someone with some Windows experience would take a look at
> it or Zoltan would come up with a fix, after all it was his addition. :-)
>
> Looking at the portability header file it appears that isnan/isinf are only one
> line defines, so it doesn't look like a major problem adding these. I will try
> fixing this, but bear with me as I have to use the buildfarm for testing. I
> don't have a Windows build environment.

If you feel inclined, you can always use Amazon EC2 for Win32 testing:

http://blog.hagander.net/archives/151-Testing-PostgreSQL-patches-on-Windows-using-Amazon-EC2.html



-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Re: buildfarm breakage

Magnus Hagander <magnus@hagander.net> — 2010-02-09T09:00:51Z

On Tuesday, February 9, 2010, Dave Page <dpage@pgadmin.org> wrote:
> On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes <meskes@postgresql.org> wrote:
>> Actually I was hoping someone with some Windows experience would take a look at
>> it or Zoltan would come up with a fix, after all it was his addition. :-)
>>
>> Looking at the portability header file it appears that isnan/isinf are only one
>> line defines, so it doesn't look like a major problem adding these. I will try
>> fixing this, but bear with me as I have to use the buildfarm for testing. I
>> don't have a Windows build environment.
>
> If you feel inclined, you can always use Amazon EC2 for Win32 testing:
>
> http://blog.hagander.net/archives/151-Testing-PostgreSQL-patches-on-Windows-using-Amazon-EC2.html
>

I actually brok the image that post talks about. But contact me on IM
if you want info about the new one I use andbhavent gotten around to
post abou yet.

/Magnus


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: buildfarm breakage

Boszormenyi Zoltan <zb@cybertec.at> — 2010-02-09T09:21:06Z

Michael Meskes írta:
> On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
>   
>>> MSVC builds are broken from a missing _isnan function on the ECPG tests. 
>>> Do we need to link in a math lib or something there?
>>>       
>> It looks to me like the problem is that that test is being compiled
>> without benefit of any platform-dependent code whatsoever.  In the rest
>> of the system, isnan and isinf work on WIN32 because the compiles can
>> see the macro definitions in port/win32.h.  nan_test is apparently not
>> including that.  I'm not sure of Michael's plan for portability of
>> these test cases --- if he doesn't want to include c.h or something
>> close to that, I think the nan test has to go away.
>>     
>
> Actually I was hoping someone with some Windows experience would take a look at
> it or Zoltan would come up with a fix, after all it was his addition. :-)
>   

Yes, it was. :-)

For the regression test, I am inclined to just do

#ifdef WIN32
#define isnan(x)   _isnan(x)
#define isinf(x)   _isinf(x)
#endif

or something like that in the regression test only.
MSVC seems to define the these functions with
an underscore prefix. :-(

Can we try that? Without adding port/* to libpq, this is
the smallest change that may fix the Windows regression tests.

> Looking at the portability header file it appears that isnan/isinf are only one
> line defines, so it doesn't look like a major problem adding these. I will try
> fixing this, but bear with me as I have to use the buildfarm for testing. I
> don't have a Windows build environment. 
>
> If someone is willing to run a test on Windows for me, please tell me.
>
> Michael
>   


-- 
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/

Re: buildfarm breakage

Michael Meskes <meskes@postgresql.org> — 2010-02-09T12:21:25Z

> For the regression test, I am inclined to just do
> 
> #ifdef WIN32
> #define isnan(x)   _isnan(x)
> #define isinf(x)   _isinf(x)
> #endif

Well the isinf() macro is different in win32.h. I did make a change and
apparently red_bat is now green again. Hopefully that was it.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: buildfarm breakage

Magnus Hagander <magnus@hagander.net> — 2010-02-09T12:52:56Z

On Tue, Feb 9, 2010 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
>> recent RADIUS support fix. Looks like we might need to include win32.h
>> in there.
>
> That was discussed already.  I assume Magnus is going to address it
> as soon as he gets back from FOSDEM.

Yes.

It's not quite that simple, though. It *is* in the win32 header for
mingw. As an extern. But it's not present in the libraries on mingw
(it *is* present on msvc). So we need to define the actual contents of
it. I'll look at getting a mingw box up to fix that as soon as
possible, hopefully today.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: buildfarm breakage

Magnus Hagander <magnus@hagander.net> — 2010-02-09T14:33:53Z

On Tue, Feb 9, 2010 at 13:52, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Feb 9, 2010 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
>>> recent RADIUS support fix. Looks like we might need to include win32.h
>>> in there.
>>
>> That was discussed already.  I assume Magnus is going to address it
>> as soon as he gets back from FOSDEM.
>
> Yes.
>
> It's not quite that simple, though. It *is* in the win32 header for
> mingw. As an extern. But it's not present in the libraries on mingw
> (it *is* present on msvc). So we need to define the actual contents of
> it. I'll look at getting a mingw box up to fix that as soon as
> possible, hopefully today.

Here's a patch that "fixes" this. I put it locally for the radius
authentication for now, since we don't use this anywhere else. Should
we put this in /port/ somewhere, or is this good for now?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: buildfarm breakage

Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-09T16:11:41Z

Magnus Hagander <magnus@hagander.net> writes:
> Here's a patch that "fixes" this. I put it locally for the radius
> authentication for now, since we don't use this anywhere else. Should
> we put this in /port/ somewhere, or is this good for now?

How about dropping it in src/backend/port/win32/mingwcompat.c ?

The advantage of putting it in src/port/ is that it would possibly
help client-side code sometime in future.  But what seems more likely
to happen is that the mingw people will fix their oversight, and
then we'd be risking link conflicts, which will be harder to fix on
the client side.  So I'm inclined to not go there as long as we
don't actually need it on client side.  But putting mingw hacks
in a mingw-specific place seems a good idea.

			regards, tom lane

Re: buildfarm breakage

Magnus Hagander <magnus@hagander.net> — 2010-02-09T16:14:57Z

On Tue, Feb 9, 2010 at 17:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Here's a patch that "fixes" this. I put it locally for the radius
>> authentication for now, since we don't use this anywhere else. Should
>> we put this in /port/ somewhere, or is this good for now?
>
> How about dropping it in src/backend/port/win32/mingwcompat.c ?

Oh, meh. I had forgotten we had that file :-)

Thanks for the reminder, will verify tonight that it still works after
I do that.


> The advantage of putting it in src/port/ is that it would possibly
> help client-side code sometime in future.  But what seems more likely
> to happen is that the mingw people will fix their oversight, and
> then we'd be risking link conflicts, which will be harder to fix on
> the client side.  So I'm inclined to not go there as long as we
> don't actually need it on client side.  But putting mingw hacks
> in a mingw-specific place seems a good idea.

yeah, agreed.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: buildfarm breakage

Magnus Hagander <magnus@hagander.net> — 2010-02-10T15:27:59Z

2010/2/9 Magnus Hagander <magnus@hagander.net>:
> On Tue, Feb 9, 2010 at 17:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> Here's a patch that "fixes" this. I put it locally for the radius
>>> authentication for now, since we don't use this anywhere else. Should
>>> we put this in /port/ somewhere, or is this good for now?
>>
>> How about dropping it in src/backend/port/win32/mingwcompat.c ?
>
> Oh, meh. I had forgotten we had that file :-)
>
> Thanks for the reminder, will verify tonight that it still works after
> I do that.

If someone didn't notice, I have applied that fix and it appears to
have solved it.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: buildfarm breakage

Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-10T15:58:52Z

Magnus Hagander <magnus@hagander.net> writes:
> If someone didn't notice, I have applied that fix and it appears to
> have solved it.

... and there was much rejoicing.

			regards, tom lane

Re: buildfarm breakage

Zdenek Kotala <zdenek.kotala@sun.com> — 2010-02-15T11:36:10Z

Andrew Dunstan píše v po 08. 02. 2010 v 20:07 -0500:

> 
> Our Solaris *moth members seem to have stopped building. Have we lost them?

Hi Andrew,

The answer is not simple. Yes, we lost Solaris 8 and 9 machines which
was reinstalled and now they are used for different purpose. It was
planned before the April and I announced it long time ago. It
unfortunately happed and timing looks strange. And I did not find
replacement.

I have replacement for nevada/x86 machine already, but I need to setup
it which is one item in my very long TODO list :(. Solaris 10 Sparc/x86
and nevada sparc are covered at this moment.

	Zdenek

Re: buildfarm breakage

Bruce Momjian <bruce@momjian.us> — 2010-02-16T17:05:42Z

Zdenek Kotala wrote:
> Andrew Dunstan p??e v po 08. 02. 2010 v 20:07 -0500:
> 
> > 
> > Our Solaris *moth members seem to have stopped building. Have we lost them?
> 
> Hi Andrew,
> 
> The answer is not simple. Yes, we lost Solaris 8 and 9 machines which
> was reinstalled and now they are used for different purpose. It was
> planned before the April and I announced it long time ago. It
> unfortunately happed and timing looks strange. And I did not find
> replacement.
> 
> I have replacement for nevada/x86 machine already, but I need to setup
> it which is one item in my very long TODO list :(. Solaris 10 Sparc/x86
> and nevada sparc are covered at this moment.

I think we have to accept the inevitable result that Postgres support on
Solaris is going to diminish over time.  We certainly are going to get
less support from Sun/Oracle, and one day the use of Postgres might even
be obstructed on Solaris or void software support contracts.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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