Re: 7.0.2 on Solaris - Mailing list pgsql-hackers

From pgsql-hackers@thewrittenword.com
Subject Re: 7.0.2 on Solaris
Date
Msg-id 200006281926.OAA28848@postal.thewrittenword.com
Whole thread Raw
In response to Re: 7.0.2 on Solaris  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: 7.0.2 on Solaris
List pgsql-hackers
On Wed, Jun 28, 2000 at 08:38:08PM +0200, Peter Eisentraut wrote:
> pgsql-hackers@thewrittenword.com writes:
> 
> > 3. Why is NAN defined in src/include/solaris_i386.h as:
> 
> We probably need a real configure test for this.

Probably.

> > 5. added '-' before pl/tcl/Makefile so make does not complain if it
> > cannot find pl/tcl/Makefile.tcldefs (which will be automatically
> > generated).
> 
> Yeah but if the automatic generation fails then it won't include it at
> all?

No. But, it will be silent so you won't know. However, you should get
an error if the automatic generation fails.

> > 7. Honor CXXFLAGS from configure command-line.
> 
> It already does that as far as I can tell. Defining the variable in
> Makefile.global instead of libpq++/Makefile doesn't make a difference.

Ok, thanks.

> > 8. In configure:
> >    a) It is evil to use a library if it exists:
> >       (AC_CHECK_LIB(util,main))
> >       It is far better to check for a function in the library.
> 
> Amen to that, but unfortunately most of the information about which
> function was required from which library is lost in history. Btw., the
> proper solution to this is AC_SEARCH_LIBS, not what you wrote.

Just found out about AC_SEARCH_LIBS. Thanks. How about getting rid of
all the AC_CHECK_LIB([library],main) code and adding things back in as
they break?

> In general, if you want to contribute changes in this area it might be a
> good idea to start from the current sources, because I'm all over that
> code at the moment.

Ok. So should I get CVS and reapply my patches?

-- 
albert chin (china@thewrittenword.com)



pgsql-hackers by date:

Previous
From: pgsql-hackers@thewrittenword.com
Date:
Subject: Re: 7.0.2 on Solaris
Next
From: Karel Zak
Date:
Subject: Re: Misc. consequences of backend memory management changes