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