Thread: buildfarm breakage
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
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
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
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
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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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/
> 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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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/
Attachment
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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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
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
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. +