Re: 7.0.2 on Solaris

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

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@thewrittenword.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++ librariesifeq ($(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  endifendif# Shared library stuff, also default 'all' targetinclude $(SRCDIR)/Makefile.shlib
-
-# Pull shared-lib CFLAGS into CXXFLAGS
+# Pull shared-lib CFLAGS into CXXFLAGS CXXFLAGS+= $(CFLAGS_SL)
-.PHONY: examplesexamples: