Re: 7.0.2 on Solaris

From: pgsql-hackers(at)thewrittenword(dot)com
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.0.2 on Solaris
Date: 2000-06-28 19:25:41
Message-ID: 200006281926.OAA28848@postal.thewrittenword.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 28, 2000 at 08:38:08PM +0200, Peter Eisentraut wrote:
> pgsql-hackers(at)thewrittenword(dot)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(at)thewrittenword(dot)com)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karel Zak 2000-06-28 19:40:35 Re: Misc. consequences of backend memory management changes
Previous Message Stephan Szabo 2000-06-28 19:06:33 Re: AW: Proposal: More flexible backup/restore via pg_dump