Re: 7.0.2 on Solaris

On Wed, Jun 28, 2000 at 01:56:49AM -0400, Tom Lane wrote:
> pgsql-hackers(at)thewrittenword(dot)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?

We're runnig 5.0 with the latest set of patches. 6.0 just came out but
we don't have our copy yet.

> > 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.

Understood. We took the easy way out. Considering noone else has
reported a problem and that 5.0 has been out for awhile (though I
imagine some people might still be using 4.2), it should be safe to
remove.

> > 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.

Note that Solaris/SPARC doesn't have this #ifndef NAN stuff. Why be
specific to Solaris/Intel? Solaris CC does not have __const so if left
in it doesn't compile.

The reason the compile succeeds when the #else section is removed is
because of the following in src/include/utils/timestamp.h:
#ifdef NAN
#define DT_INVALID (NAN)
#else
#define DT_INVALID (DBL_MIN+DBL_MIN)
#endif

So, DBL_MIN+DBL_MIN is used rather than NAN. Dunno if this is a "good
thing". There are other places, like src/backend/utils/adt/numeric.c,
that:
#ifndef NAN
#define NAN (0.0/0.0)
#endif

Again, I don't know if this is a "good thing" (and if NAN is defined
to be this here, why not similarly for src/include/utils/timestamp.h
above?).

> > 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.)

Ok. I now understand why it was in the Makefile in libpq++. I've
attached a patch to add my Makefile.shlib changes to
src/interfaces/libpq++/Makefile.in.

>
> > 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.

I think so. Makes it easier when running ./configure to figure out
what extra 3rd-party modules are being used. It also means every
submodule does not necessary have to -L everything in --with-libs
and -I everything in --with-includes. Can you guarantee that this
will always be safe?

> regards, tom lane

--
albert chin (china(at)thewrittenword(dot)com)

-- snip snip
--- src/interfaces/libpq++/Makefile.in.orig Tue Jun 20 17:55:36 2000
+++ src/interfaces/libpq++/Makefile.in Wed Jun 28 08:55:30 2000
@@ -39,22 +39,38 @@
SHLIB_LINK= $(LIBPQ)
endif

-# For CC on IRIX, must use CC as linker/archiver of C++ libraries
ifeq ($(PORTNAME), irix5)
+ # if archiving or linking C++ objects, must use CC (according to CC(1))
ifeq ($(CXX), CC)
- AR = CC
- AROPT = -ar -o
- LD = CC
+ AR := CC
+ AROPT := -ar -o
+ LD := CC
+ endif
+endif
+
+ifeq ($(PORTNAME), solaris_i386)
+ # if archiving or linking C++ objects, must use CC (according to CC(1))
+ ifeq ($(CXX), CC)
+ AR := CC
+ AROPT := -xar -o
+ LD := CC
+ endif
+enfi
+
+ifeq ($(PORTNAME), solaris_sparc)
+ # if linking C++ objects, must use CC (according to CC(1))
+ ifeq ($(CXX), CC)
+ AR := CC
+ AROPT := -xar -o
+ LD := CC
endif
endif

# Shared library stuff, also default 'all' target
include $(SRCDIR)/Makefile.shlib

-
-# Pull shared-lib CFLAGS into CXXFLAGS
+# Pull shared-lib CFLAGS into CXXFLAGS
CXXFLAGS+= $(CFLAGS_SL)
-

.PHONY: examples
examples: