Thread: Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.

On 01/21/2011 12:48 PM, Bruce Momjian wrote:
> Move test_fsync to /contrib.
>
>

This appears to have broken Solaris, Unixware and MSVC builds.

Here's the error on Solaris:

gmake[1]: Entering directory `/export/home/dpage/pgbuildfarm/moa/HEAD/pgsql.4167/contrib/pg_test_fsync'
cc -Xa -m64 -xarch=native -xdepend -xO3 -xprefetch=auto,explicit -g -I. -I. -I../../src/include   -c -o pg_test_fsync.o
pg_test_fsync.c
cc -Xa -m64 -xarch=native -xdepend -xO3 -xprefetch=auto,explicit -g pg_test_fsync.o  -L../../src/port
-Wl,-R'/export/home/dpage/pgbuildfarm/moa/HEAD/inst/lib' -lpgport -lpam -lgss -lz -lnsl -lsocket -lm  -o pg_test_fsync
 
Undefined            first referenced symbol                  in file
CurrentMemoryContext                pg_test_fsync.o
ld: fatal: Symbol referencing errors. No output written to pg_test_fsync


Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?


cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?

I had tried that, actually, but it fails because the other include files
test_fsync needs are backend-specific.  We may have to refactor those
include files so that the stuff test_fsync actually needs is includable
with less context required.   I thought I'd wait on that project till we
had a full cycle from the buildfarm and could see what other portability
issues surface.
        regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:
> This appears to have broken Solaris, Unixware and MSVC builds.

BTW, the MSVC problem appears to stem from failure to include libpgport
when linking pg_test_fsync.  I imagine this requires a fix in the MSVC
build scripts.
        regards, tom lane

On Sat, Jan 22, 2011 at 18:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> This appears to have broken Solaris, Unixware and MSVC builds.
>
> BTW, the MSVC problem appears to stem from failure to include libpgport
> when linking pg_test_fsync.  I imagine this requires a fix in the MSVC
> build scripts.

Yup, fixed and pushed.

I still get:
pg_test_fsync.c
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101: 'ops'
: unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'writes' : unreferenced local variable
1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
'tmpfile' : unreferenced local variable

ISTM that the declaration of variables should be moved inside the #ifdef, no?

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

Magnus Hagander <magnus@hagander.net> writes:
> I still get:
> pg_test_fsync.c
> 1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101: 'ops'
> : unreferenced local variable
> 1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
> 'writes' : unreferenced local variable
> 1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
> 'tmpfile' : unreferenced local variable

> ISTM that the declaration of variables should be moved inside the #ifdef, no?

Yeah, I independently came to the same conclusion ...
        regards, tom lane

I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?

> I had tried that, actually, but it fails because the other include files
> test_fsync needs are backend-specific.  We may have to refactor those
> include files so that the stuff test_fsync actually needs is includable
> with less context required.

On closer inspection, test_fsync doesn't even need the include files
that caused the problem.  I think my latest commit will fix everything.
        regards, tom lane