Tom Lane writes:
> Yes, we deliberately build the Tcl and Perl interfaces and PL modules
> with those systems' preferred compilers and switches, and have done so
> since PG 7.0 (at least, maybe earlier). IIRC, this was forced by the
> observation that the other way didn't work.
The problem as I recall it was that we were using some PostgreSQL-provided
CFLAGS with the language's preferred compiler, which may cause a mixup.
However, the right fix would have been to not use the language's preferred
compiler. For instance, that compiler might not even exist.
Unfortunately, this isn't very easy to do.
However, the current situation is IMHO completely inadequate for a number
of reasons besides this one and I am plotting to kill off MakeMaker and
friends. (Perhaps you could still use Makefile.PL by hand if you want,
but we wouldn't use it by default.) Ideally, this would be combined with
a move to GNU Libtool, but that won't happen for 7.2 at least, AFAI'm
concerned. (Libtool would give us some nice options. For example, on
certain platforms it is possible to link a static, non-pic library into a
shared library, so we could handle libperl much better.)
> Curious that so many people are complaining of pl/tcl failures now,
> when there were almost no such reports for 7.0. AFAIK, 7.0 should have
> been equally vulnerable. Perhaps someone has just recently started
> distributing Tcl packages containing bogus tclConfig information?
AFAICT, the tclConfig's in various BSD "ports" have contained non-standard
information for a while (e.g. a TCL_INCDIR). OTOH, the problem with the
tcl include directory has been known for a while. Perhaps it's just that
now is the time that many people compile PostgreSQL.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
