Обсуждение: Port Bug Report: buf_init.c does not compile (spin lock problem?)

============================================================================
                        POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name               : St�phane Bortzmeyer
Your email address      : bortzmeyer@pasteur.fr

Category                : install: compile
Severity                : critical

Summary: buf_init.c does not compile (spin lock problem?)

System Configuration
--------------------
  Operating System   : Digital Unix 4.0E  (Rev. 1091)

  PostgreSQL version : 6.5

  Compiler used      : egcs 1.1.2 (2.91.66)


Hardware:
---------
Alpha

Versions of other tools:
------------------------
GNU Make version 3.77
flex version 2.5.4

--------------------------------------------------------------------------

Problem Description:
--------------------
gcc -I../../../include -I../../../backend   -DNOFIXADE -Wall -Wmissing-prototypes -I../..   -c buf_init.c -o buf_init.o
In file included from /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0e/egcs-2.91.66/include/stdarg.h:36,
                 from ../../../include/c.h:52,
                 from ../../../include/postgres.h:42,
                 from buf_init.c:20:
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0e/egcs-2.91.66/include/va-alpha.h:36: warning: redefinition of `va_list'
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0e/egcs-2.91.66/include/va_list.h:7: warning: `va_list' previously declared
here
../../../include/storage/s_lock.h: In function `tas':
In file included from buf_init.c:29:
../../../include/storage/s_lock.h:104: aggregate value used where an integer was expected
buf_init.c: In function `InitBufferPool':
buf_init.c:219: incompatible types in assignment
buf_init.c:220: incompatible types in assignment
make[3]: *** [buf_init.o] Error 1

Line 219 and 220 are :

#ifdef HAS_TEST_AND_SET
            S_INIT_LOCK(&(buf->io_in_progress_lock));
            S_INIT_LOCK(&(buf->cntx_lock));
#endif


--------------------------------------------------------------------------

Test Case:
----------
make


--------------------------------------------------------------------------

Solution:
---------


--------------------------------------------------------------------------

On Thu, 17 Jun 1999, Unprivileged user wrote:

>
>============================================================================
>                        POSTGRESQL BUG REPORT TEMPLATE
>============================================================================
>
>
>Your name               : Stéphane Bortzmeyer
>Your email address      : bortzmeyer@pasteur.fr
>
>Category                : install: compile
>Severity                : critical
>
>Summary: buf_init.c does not compile (spin lock problem?)
>
>System Configuration
>--------------------
>  Operating System   : Digital Unix 4.0E  (Rev. 1091)
>
>  PostgreSQL version : 6.5
>
>  Compiler used      : egcs 1.1.2 (2.91.66)
                        ^^^^^^^^^^

I have tested it with DEC C and works right out of the box. I have tried
gcc 2.7.2 in the past, and have never been able to build postgres with it.
gcc 2.8 doesn't work either, and now it seems that egcs behaves the same.

Probably there is something wrong with the spinlock implementation for
gcc/alpha, but I don't have the time to investigate it.

Cheers,

    Pedro.

--
-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
E.U.I.T. Telecomunicación               e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7                E-28031 Madrid - España / Spain

On Thursday 17 June 1999, at 18 h 38, the keyboard of "Pedro J. Lobo"
<pjlobo@euitt.upm.es> wrote:

> I have tested it with DEC C and works right out of the box. I have tried
> gcc 2.7.2 in the past, and have never been able to build postgres with it.
> gcc 2.8 doesn't work either, and now it seems that egcs behaves the same.

Thanks, but after 'make distclean' and a new configure, it doesn't work better
with Digital/Compaq's cc:

make -C port all
make[2]: Entering directory `/home/bortz/tmp/postgresql-6.5/src/backend/port'
...
cc -I../../include -I../../backend   -DNOFIXADE -I..   -c isinf.c -o isinf.o
cc -I../../include -I../../backend   -DNOFIXADE -I..   -c snprintf.c -o
snprintf.o
cc: Warning: ../../include/regex/cdefs.h, line 122: The redefinition of the
macro "inline" conflicts with a current definition because the replacement
lists differ.  The redefinition is now in effect. (macroredef)
#define inline
--------------^
cc: Error: snprintf.c, line 89: In this declaration, parameter 3 has a
different type than specified in an earlier declaration of this function.
(mismatparam)
int                     snprintf(char *str, size_t count, const char *fmt,...);
------------------------^
cc: Error: snprintf.c, line 89: In this declaration, the type of "snprintf" is
not compatible with the type of a previous declaration of "snprintf" at line
number 789 in file ../../include/c.h. (notcompat)
int                     snprintf(char *str, size_t count, const char *fmt,...);
------------------------^
cc: Error: snprintf.c, line 90: In this declaration, parameter 3 has a
different type than specified in an earlier declaration of this function.
(mismatparam)
...

On Thu, 17 Jun 1999, Stephane Bortzmeyer wrote:

>On Thursday 17 June 1999, at 18 h 38, the keyboard of "Pedro J. Lobo"
><pjlobo@euitt.upm.es> wrote:
>
>> I have tested it with DEC C and works right out of the box. I have tried
>> gcc 2.7.2 in the past, and have never been able to build postgres with it.
>> gcc 2.8 doesn't work either, and now it seems that egcs behaves the same.
>
>Thanks, but after 'make distclean' and a new configure, it doesn't work better
>with Digital/Compaq's cc:
>
>make -C port all
>make[2]: Entering directory `/home/bortz/tmp/postgresql-6.5/src/backend/port'
>...
>cc -I../../include -I../../backend   -DNOFIXADE -I..   -c isinf.c -o isinf.o
>cc -I../../include -I../../backend   -DNOFIXADE -I..   -c snprintf.c -o
                                    ^^^^^^^^^^^^^

These flags correspond to the template 'alpha_gcc', not to 'alpha_cc',
which is the one that should be used with DEC C. The problem you are
seeing comes from a missing flag (-std). Make sure that you give the
option "--with-CC=cc' to configure, and if you don't see this line:

checking setting template to... alpha_cc

(that is, if it says 'alpha_gcc' instead) then re-run configure with the
option "--with-template=alpha_cc". I didn't have to specify that, but...
Also, it wouldn't hurt if you remove the whole source tree and extract it
again from the tarball, just in case. The 'make distclean' should have the
same effect, but it seems it didn't.

Cheers,

    Pedro.

--
-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
E.U.I.T. Telecomunicación               e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7                E-28031 Madrid - España / Spain

[Pedro, feel free to forward to pgsql-ports, I have apparently no right to
write on it.]

On Friday 18 June 1999, at 10 h 45, the keyboard of "Pedro J. Lobo"
<pjlobo@euitt.upm.es> wrote:

> These flags correspond to the template 'alpha_gcc', not to 'alpha_cc',

This was it. I forgot the old template. Thanks.

There are still problems:

Bison seems mandatory (Digital/Compaq's yacc makes errors)

C++ code cannot be compiled with Digital's cxx compiler (because Postgres uses CFLAGS for the C++ compiler and the
command-lineoptions are not exactly the same, such as -std which does not exist on cxx). 

ODBC does not compile.

The following configure seems OK and compile until the end:

./configure --with-CC=cc --without-CXX -enable-cassert -with-perl --with-tcl --enable-locale --with-template=alpha_cc

On Fri, 18 Jun 1999, Stephane Bortzmeyer wrote:

>
>[Pedro, feel free to forward to pgsql-ports, I have apparently no right to
>write on it.]
>
>On Friday 18 June 1999, at 10 h 45, the keyboard of "Pedro J. Lobo"
><pjlobo@euitt.upm.es> wrote:
>
>> These flags correspond to the template 'alpha_gcc', not to 'alpha_cc',
>
>This was it. I forgot the old template. Thanks.

Good.

>There are still problems:
>
>Bison seems mandatory (Digital/Compaq's yacc makes errors)

I believe that you can use Compaq's yacc using the '-N' parameter to
increase the space available to build the LALR tables. I haven't checked
it, thouth.

>C++ code cannot be compiled with Digital's cxx compiler (because
>Postgres uses CFLAGS for the C++ compiler and the command-line options
>are not exactly the same, such as -std which does not exist on cxx).

Yes, this is a known issue. I don't use C++ myself, and I don't know
if/when I will have the time to look at it.

>ODBC does not compile.

I haven't checked it, either.

>The following configure seems OK and compile until the end:
>
>./configure --with-CC=cc --without-CXX -enable-cassert -with-perl
>--with-tcl --enable-locale --with-template=alpha_cc

Yes, it is very similar to the one I use, except that I don't specify any
template and I don't enable assertion checking.

Cheers,

    Pedro.

--
-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
E.U.I.T. Telecomunicación               e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7                E-28031 Madrid - España / Spain

[I see on http://www.postgresql.org/docs/admin/install760.htm an invitation to
send info to pgsql-ports@postgreSQL.org but this list is closed for foreign
posters.]

On Friday 18 June 1999, at 14 h 57, the keyboard of "Pedro J. Lobo"
<pjlobo@euitt.upm.es> wrote:

> >Bison seems mandatory (Digital/Compaq's yacc makes errors)
>
> I believe that you can use Compaq's yacc using the '-N' parameter to
> increase the space available to build the LALR tables. I haven't checked
> it, thouth.

Neither did I. I installed bison and everything went fine. This could be
documented.

> Yes, it is very similar to the one I use, except that I don't specify any
> template and I don't enable assertion checking.

Here are y regression tests. I'll study them next week.


=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is now set to PST8PDT explicitly by this regression test
 client frontend. Please report any apparent problems to
   ports@postgresql.org
See regress/README for more information.

=============== destroying old regression database... =================
ERROR:  destroydb: database 'regression' does not exist
destroydb: database destroy failed on regression.
=============== creating new regression database...   =================
=============== installing PL/pgSQL...                =================
=============== running regression queries...         =================
boolean ..  ok
char ..  ok
name ..  ok
varchar ..  ok
text ..  ok
strings ..  ok
int2 ..  failed
int4 ..  failed
int8 ..  ok
oid ..  ok
float4 ..  ok
float8 ..  failed
numerology ..  ok
point ..  ok
lseg ..  ok
box ..  ok
path ..  ok
polygon ..  ok
circle ..  ok
geometry ..  failed
timespan ..  ok
datetime ..  ok
reltime ..  ok
abstime ..  failed
tinterval ..  failed
horology ..  failed
inet ..  ok
comments ..  ok
oidjoins ..  ok
type_sanity ..  ok
opr_sanity ..  ok
create_function_1 ..  ok
create_type ..  ok
create_table ..  ok
create_function_2 ..  ok
constraints ..  ok
triggers ..  ok
copy ..  failed
create_misc ..  ok
create_aggregate ..  ok
create_operator ..  ok
create_view ..  ok
create_index ..  ok
sanity_check ..  ok
errors ..  ok
select ..  failed
select_into ..  ok
select_distinct ..  failed
select_distinct_on ..  failed
select_implicit ..  ok
select_having ..  ok
subselect ..  ok
union ..  ok
case ..  ok
join ..  ok
aggregates ..  failed
transactions ..  ok
random ..  failed
portals ..  ok
misc ..  failed
arrays ..  ok
btree_index ..  ok
hash_index ..  ok
select_views ..  ok
alter_table ..  ok
portals_p2 ..  failed
rules ..  failed
limit ..  failed
plpgsql ..  ok
temp ..  ok
numeric ..  ok

> >
> >Bison seems mandatory (Digital/Compaq's yacc makes errors)
>
> I believe that you can use Compaq's yacc using the '-N' parameter to
> increase the space available to build the LALR tables. I haven't checked
> it, thouth.
>

No, yacc ends up with some undefined symbols. So you really seem to need
Bison. But as Bison compiles out of the box, that is no big deal.

I've hit another problem when loading (largish) pl functions: at times
the backend processes seem to run out of stack, anyway I did get one
'ran out of stack' error message, and the default stack size is not
terrible big by default. I have no idea how to increase the stack size
for the backend processes. I know about ulimit, but I don't know how to
set it for the backend processes. I guess I could recompile the kernel,
but there must be an easier way.

I've had problems when reloading functions a few times (i.e. dropping
and creating), that the pg_proc table got corrupted. I think some of
them may have been too large and have breached the 8k tuple limit. I
split them into smaller functions and it seems to have happened less
often. At times shutting down the system, starting it up again and
vacuuming pg_proc would solve it, but mostly I had to drop the database
and start all over again. Anybody else had these problems?

Adriaan