Re: 7.0.2 on Solaris - Mailing list pgsql-hackers

pgsql-hackers@thewrittenword.com writes:
> 1. I'm curious why src/template/solaris_sparc_cc contains:
>   -DDISABLE_COMPLEX_MACRO

Presumably because the Solaris Sparc compiler was once broken.
Dunno how long ago that was, but I have no objection to removing
the -D switch if it seems to work on not-too-ancient copies.
How recent is your Solaris?

> The reason for this is because nocachegetattr becomes a function when
> DISABLE_COMPLEX_MACRO is defined (nocachegetattr is defined in
> src/backend/access/common/heaptuple.c).

> The first patch below removes this macro from
> src/templates/solaris_sparc_cc.

It's broken all right, but that's no fix --- it just masks the problem
on your platform.  The breakage is that somebody decided a static
function definition in an include file is a cool idea.  Not when the
include file is included by non-backend modules ... the non-macro
definition of fastgetattr() needs to be made a plain extern routine.

> 3. Why is NAN defined in src/include/solaris_i386.h as:
> #define                            NAN     (*(__const double *) __nan)
> #endif   /* GCC.  */
> if the compiler is not GCC? The Solaris C compiler does not like this.
> I removed it and the compilation succeeded.

Hmm, I think this needs more investigation.  Removing a definition of
NAN that's inside "#ifndef NAN" cannot cause things to work unless there
is an order dependency with another definition of NAN.  Perhaps we need
to be rearranging header includes or some such.  Again, it seems like
the true issue might affect more than just solaris.

> 4. I moved some of the information out of
> src/interfaces/libpq++/Makefile.in into src/Makefile.shlib where it
> belongs. Assuming that CXXFLAGS should take on the shared library
> flags for CFLAGS_SL is wrong though.

Nope, try again.  Your change breaks things for all non-C++ shared libs,
because it changes AR and LD to C++-suitable definitions for *all* shlib
modules not just C++ modules.  That might happen to work on your
installation but it's a recipe for trouble.  The reason that the C++
info is in src/interfaces/libpq++/Makefile.in is that that's where it
belongs, to avoid messing up non-C++ modules.  (If we had more than one
C++ shlib I'd be more excited about figuring out how to keep the info in
Makefile.shlib, but as things stand I think leaving it out is the path
of least resistance.)

>    b) Added --with-readline=DIR to check for readline in DIR.

What for?  We have --with-includes and --with-libs; shall we now
add a custom "--with-libfoo" option for every single library we
depend on?  This seems like useless clutter.

Some of the other changes look good but I'm not in a position to
separate them out from the less-good stuff...
        regards, tom lane