Thread: OSF build broken
I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with: In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:64: parse error before `int64_t' ../../../../src/include/libpq/pqcomm.h:64: warning: no semicolon at end of struct or union ../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:71: parse error before `}' ../../../../src/include/libpq/pqcomm.h:81: field `addr' has incomplete type gmake[4]: *** [printtup.o] Error 1 gmake[4]: Leaving directory `/files1/home/philip/install/pgsql/src/backend/access/common' gmake[3]: *** [common-recursive] Error 2 gmake[3]: Leaving directory `/files1/home/philip/install/pgsql/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/files1/home/philip/install/pgsql/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/files1/home/philip/install/pgsql/src' gmake: *** [all] Error 2 Any ideas how I can resolve this? Regards, Philip Yarra.
Philip Yarra <philip@utiba.com> writes:
> I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
> "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
> In file included from ../../../../src/include/libpq/libpq-be.h:22,
> from ../../../../src/include/libpq/libpq.h:21,
> from printtup.c:20:
> ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not in a
> function)
Is type int64_t defined anywhere in your system headers? If so, where?
regards, tom lane
On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
> Is type int64_t defined anywhere in your system headers? If so, where?
Er... no... this:
int main()
{printf("sizeof is: %d\n", sizeof(int64_t));
}
fails with:
cc: Error: l.c, line 2: In this statement, "int64_t" is not declared.
(undeclared) printf("t is: %d\n", sizeof(int64_t));
------------------------------------^
But then, it doesn't work on Linux (intel 32-bit) either... What's this
int64_t supposed to be? We're not just talking about a long long are we?
Regards, Philip.
On Mon, 7 Jul 2003, Tom Lane wrote: > Philip Yarra <philip@utiba.com> writes: > > I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on > > "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with: > > > In file included from ../../../../src/include/libpq/libpq-be.h:22, > > from ../../../../src/include/libpq/libpq.h:21, > > from printtup.c:20: > > ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not in a > > function) > > Is type int64_t defined anywhere in your system headers? If so, where? Shouldn't we be checking for its existance (it doesn't appear that the file uses it conditionally)? It's only C99 AFAIR and even there it's optional. Also, are we guaranteed that stdint.h will have been included before pqcomm.h?
Philip Yarra <philip@utiba.com> writes:
> On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
>> Is type int64_t defined anywhere in your system headers? If so, where?
> Er... no... this:
> int main()
> {
> printf("sizeof is: %d\n", sizeof(int64_t));
> }
> fails with:
Without some #include's, I'd expect it to fail, because int64_t isn't
built into the C compiler. The question is exactly which #include
are we missing.
regards, tom lane
On Mon, 7 Jul 2003 02:53 pm, you wrote: > Without some #include's, I'd expect it to fail, because int64_t isn't > built into the C compiler. The question is exactly which #include > are we missing. Okay, got it: db.h
Philip Yarra wrote: > But then, it doesn't work on Linux (intel 32-bit) either... What's this > int64_t supposed to be? We're not just talking about a long long are we? > I found it on my Red Hat 9 box in sys/types.h: <snip> # if __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif </snip> Joe
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote: > I found it on my Red Hat 9 box in sys/types.h: > <snip> > # if __GLIBC_HAVE_LONG_LONG > __extension__ typedef long long int int64_t; > # endif And on RedHat 7.3 it's in stdint.h - they must move it around to keep the snipers guessing. If you haven't hit this problem trying to build, it sounds like the right things are getting included for your platform. What's the best (most portable) way to fix this? Would something like: #ifdef OSF #include <db.h> #endif work? I'm guessing this sort of issue comes up regularly.
Philip Yarra <philip@utiba.com> writes:
> And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
> snipers guessing.
Sometimes it seems that way :-(
> What's the best (most portable) way to fix this?
My vote is to rip out every last reference to int64_t and other
system-header-dependent datatypes. These were added in the recent
IPv6 changes, and I thought at the time that they'd not stand the
test of portability, but I kept quiet for lack of evidence. Now
there is some. I recommend sending in a patch that replaces int64_t
with int64, and likewise for anything you don't see defined or used
in src/include/c.h. The stuff in c.h has been through the wars
already, the IPv6 code has not.
regards, tom lane
On Mon, Jul 07, 2003 at 01:46:21AM -0400, Tom Lane wrote: > Philip Yarra <philip@utiba.com> writes: > > And on RedHat 7.3 it's in stdint.h - they must move it around to keep the > > snipers guessing. > > Sometimes it seems that way :-( > > > What's the best (most portable) way to fix this? > > My vote is to rip out every last reference to int64_t and other > system-header-dependent datatypes. These were added in the recent > IPv6 changes, and I thought at the time that they'd not stand the > test of portability, but I kept quiet for lack of evidence. Now > there is some. I recommend sending in a patch that replaces int64_t > with int64, and likewise for anything you don't see defined or used > in src/include/c.h. The stuff in c.h has been through the wars > already, the IPv6 code has not. I used int64_t because that's standard (C99). But int64 will do too. Kurt
On Mon, 7 Jul 2003 04:30 pm, Kurt Roeckx wrote: > I used int64_t because that's standard (C99). But int64 will do > too. Okay... looks like it's only in a couple of places. I'll fix for Tru64 when I get a chance. I don't have commit access, so Tom, shall I send a patch to you? Regards, Philip.
Patches: int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h tested on RedHat Linux 7.3 and OSF osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) If these are okay, can someone apply them? Can someone with access to different OSF versions test pthread-safety as well? Regards, Philip Yarra.
> get a chance. I don't have commit access, so Tom, shall I send a patch to
> you?
Send it to the patches list.
regards, tom lane
Philip Yarra <philip@utiba.com> writes:
> int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h
> tested on RedHat Linux 7.3 and OSF
Applied (along with some further hacking to make the struct padding
logic more robust).
> osf-template.patch: adds pthread support for OSF
> tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha)
Applied; it would be a good idea to get some more testing of it, but
that's what beta is for ...
regards, tom lane
On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: > Philip Yarra <philip@utiba.com> writes: > > int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h > > tested on RedHat Linux 7.3 and OSF > > Applied (along with some further hacking to make the struct padding > logic more robust). I'm not sure what you did exactly, or why you think it's better. But it seems you removed the "6 byte pad", between the ss_family and the __ss_align, and I have no idea why. I won't say that I fully understand allignment as is defined in the C standard(s), but I do know that it doesn't have to allign an int64 to a multiple of 8 byte address. Note that I didn't just make that structure up, other people did. It's for instance like that in the RFC and in SUS v3. Kurt
Kurt Roeckx <Q@ping.be> writes:
> On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote:
>> Applied (along with some further hacking to make the struct padding
>> logic more robust).
> I'm not sure what you did exactly, or why you think it's better.
> But it seems you removed the "6 byte pad", between the
> ss_family and the __ss_align, and I have no idea why.
If the pad is needed, it'll be there. Making it explicit doesn't
buy anything.
> Note that I didn't just make that structure up, other people did.
> It's for instance like that in the RFC and in SUS v3.
I wouldn't have touched it if the code actually worked, but it does not
work as intended once you stick in the #ifdef SALEN thingy. The padding
computation was not accounting for that. To make it work correctly
we'd have had to add an additional explicit pad field ... which, if
sa_family_t happened to be "char" and not "short", would be a
zero-element array, resulting in a compile failure.
As I see it, there are two things this struct declaration is trying to
do: make sure the struct is of total size 128 bytes, and make sure it
has alignment as good as the worst-case alignment requirement that the
platform has for integer datatypes. (We assume that sockaddr is
unlikely to contain any float fields ;-), so we need not worry about
the prospect that floats might have stronger alignment requirement than
int64.) The revised code accomplishes both those things.
regards, tom lane
On Tue, Jul 15, 2003 at 04:28:49PM -0400, Tom Lane wrote: > Kurt Roeckx <Q@ping.be> writes: > > On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: > >> Applied (along with some further hacking to make the struct padding > >> logic more robust). > > > I'm not sure what you did exactly, or why you think it's better. > > But it seems you removed the "6 byte pad", between the > > ss_family and the __ss_align, and I have no idea why. > > If the pad is needed, it'll be there. Making it explicit doesn't > buy anything. > > > Note that I didn't just make that structure up, other people did. > > It's for instance like that in the RFC and in SUS v3. > > I wouldn't have touched it if the code actually worked, but it does not > work as intended once you stick in the #ifdef SALEN thingy. The padding > computation was not accounting for that. To make it work correctly > we'd have had to add an additional explicit pad field ... which, if > sa_family_t happened to be "char" and not "short", would be a > zero-element array, resulting in a compile failure. BSD 4.3 didn't have an sa_len, while 4.4 did. in BSD 4.3 sa_family was a short, in 4.4 it was split up in 2 chars. Note that the RFC has 2 examples, one without sa_len, an other with sa_len. Kurt
Kurt Roeckx <Q@ping.be> writes:
> Note that the RFC has 2 examples, one without sa_len, an other
> with sa_len.
If you're talking about RFC 3493, the example with ss_len is flat wrong,
since it fails to allow for the (strong) possibility that there will be
a pad byte between ss_len and ss_family. This will typically result in
making the struct alignof(int64) bigger than intended, since __ss_pad1
will be one byte too big, forcing __ss_align up to the next allowable
alignment boundary. This is no doubt harmless, but there is little
point in having such a complicated declaration if it fails to achieve
its intended goal of exactly controlling the struct's size and
alignment.
BTW, where are we getting the "SALEN" macro from, and how are we sure
that it tells the truth about whether the platform expects an ss_len
field?
regards, tom lane
On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote: > > BTW, where are we getting the "SALEN" macro from, and how are we sure > that it tells the truth about whether the platform expects an ss_len > field? I'm not sure, it was used before. Kurt
Kurt Roeckx <Q@ping.be> writes:
> On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote:
>> BTW, where are we getting the "SALEN" macro from, and how are we sure
>> that it tells the truth about whether the platform expects an ss_len
>> field?
> I'm not sure, it was used before.
Before when? A quick grep finds it nowhere in either the 7.2 or 7.3
trees ... which means we have zero field experience with it. My guess
is that someone threw it in and punted on making configure set it up.
In 7.3 and before, we never bother to set sin_len or sun_len as far as
I can see. Is it really necessary to start setting them now?
If we could dispense with the tests in the .c files, we could make a
much more robust definition of sockaddr_storage along the lines of
struct sockaddr_storage { union { struct sockaddr sa; int64 __ss_align; /* ensure alignment */ char
__ss_pad[128]; /* ensure size */ } ss_stuff;};
#define ss_family ss_stuff.sa.sa_family
Actually I'm inclined to do this even if we do need to set the length field;
but we'll need to add an honest configure test to see if it's there or not.
regards, tom lane
On Tue, Jul 15, 2003 at 05:37:39PM -0400, Tom Lane wrote:
>
> > I'm not sure, it was used before.
>
> Before when? A quick grep finds it nowhere in either the 7.2 or 7.3
> trees ... which means we have zero field experience with it. My guess
> is that someone threw it in and punted on making configure set it up.
It was in CVS when I started working on my patch, so I assumed it
was checked somewhere.
> In 7.3 and before, we never bother to set sin_len or sun_len as far as
> I can see. Is it really necessary to start setting them now?
I don't know. It's probably set when you call getpeername() or
something. I doubt the kernel looks at it in other calls.
It's the other ipv6 patch that was applied that probably started
doing it, so I also did it.
> If we could dispense with the tests in the .c files, we could make a
> much more robust definition of sockaddr_storage along the lines of
>
> struct sockaddr_storage {
> union {
> struct sockaddr sa;
> int64 __ss_align; /* ensure alignment */
> char __ss_pad[128]; /* ensure size */
> } ss_stuff;
> };
>
> #define ss_family ss_stuff.sa.sa_family
I'm not sure about that __ss_align one, I think you need 2 of
them.
Kurt
On Wed, 16 Jul 2003 03:56 am, Tom Lane wrote: > > osf-template.patch: adds pthread support for OSF > > tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) > > Applied; it would be a good idea to get some more testing of it, but > that's what beta is for ... Yes, I only have access to one version of Tru64, so all I can assert is that "it works for me", and that is only for a fairly simple test case so far. I'd be much more comfortable if other OSF users could test too. I can supply the simple ECPG app I've been using. Regards, Philip. [back from holidays and catching up on a staggering volume of PostgreSQL mail]