Thread: Build fails for pl/tcl on OpenBSD
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Hentosh
Your email address : hentosh@io.com
System Configuration
---------------------
Architecture (example: Intel Pentium) : AMD Athlon
Operating System (example: Linux 2.0.26 ELF) : OpenBSD 2.8
PostgreSQL version (example: PostgreSQL-7.0): Todays CVS (pre 7.1.1)
Compiler used (example: gcc 2.8.0) : 2.95.3
Please enter a FULL description of your problem:
------------------------------------------------
building with
./configure --enable-syslog
works great. But when I use
./configure --enable-syslog --with-tcl --without-tk --enable-multibyte --enable-unicode-conversion
--with-tclconfig=/usr/local/lib/tcl8.3
It fails with the following error when it compiles src/pl/tcl/pltcl.c:
pltcl.c:38: tcl.h: No such file or directory
This works on my linux box since tcl.h is in /usr/include but on OpenBSD it is located in
/usr/local/include/tcl8.3/tcl.h
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
Install a base OpenBSD 2.8 system and add the following packages:
bison-1.27.tgz
gettext-0.10.35.tgz
gmake-3.79.1.tgz
tcl-8.3.2.tgz
In addition to the above my system had its kernel recompiled to up shared mem
and semephores.
run the config line from above and then gmake.
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
I think the Makefile doesn't take into account if the tcl stuff was placed in a non-standard location.
Change line 66 in src/pl/tcl/Makefile to:
override CFLAGS = $(TCL_CFLAGS_OPTIMIZE) $(TCL_SHLIB_CFLAGS) -I $(TCL_PREFIX)/include/tcl$(TCL_VERSION)
Robert Hentosh <hentosh@io.com> writes:
> It fails with the following error when it compiles src/pl/tcl/pltcl.c:
> pltcl.c:38: tcl.h: No such file or directory
> This works on my linux box since tcl.h is in /usr/include but on OpenBSD it is located in
/usr/local/include/tcl8.3/tcl.h
OpenBSD's tcl package is broken, then. It's their responsibility to put
the necessary compiler flags into tclConfig.sh, not the responsibility
of every Tcl-using software to second guess where the include files are.
regards, tom lane
I said:
> OpenBSD's tcl package is broken, then. It's their responsibility to put
> the necessary compiler flags into tclConfig.sh, not the responsibility
> of every Tcl-using software to second guess where the include files are.
After thinking about this a little more, I'm confused again. How did
you manage to get past src/interfaces/libpgtcl, which also includes
tcl.h without benefit of any hand-hacked -I switches?
I'm still of the opinion that adding
-I $(TCL_PREFIX)/include/tcl$(TCL_VERSION)
to src/pl/tcl/Makefile is an inappropriate thing to do. But it seems
that the correct way to deal with nonstandardly-located packages is to
say
--with-includes=/usr/local/include/tcl8.3
to configure (more than likely you'll also need
--with-libs=/usr/local/lib/tcl8.3), and I'm just wondering how come you
didn't seem to need that to build libpgtcl. It shouldn't have gotten as
far as pl/tcl ...
regards, tom lane
Robert Hentosh <hentosh@io.com> writes:
> I went to another OpenBSD box of mine that doesn't have tcl installed and
> then downloaded the tcl8.3.2.tar.gz from scriptics.com and did a ...
> It created the same tclConfig.sh (well very similar), but the install
> placed it in /usr/local/lib and the header in /usr/local/include.
Yes, that's the normal pair of locations for tclConfig.sh and tcl.h.
> I still get the error in libpgtcl.h.
Did you rerun PG's configure after installing the changed Tcl stuff?
One possibility is that your compiler may not be set to search
/usr/local/include by default. gcc is customarily configured to do that
(though I think on a very few platforms it doesn't); but vendors' cc
will usually NOT search /usr/local/include unless told to. So if you're
using cc you probably need configure --with-includes=/usr/local/include
or configure won't think Tcl is installed at all.
> It would be interesting to see if on another platform postgresql builds
> correctly if one were to install tcl8 with a non-standard prefix. I have a
> feeling it won't and I will try to verify this tomorrow.
I have in fact done this --- HPUX likes nonstandard prefixes ;-). IIRC,
you must set --with-includes and --with-libraries, and your PATH had
better find the appropriate version of tclsh first. It would appear
from looking at configure that the --with-tclconfig option is fairly
useless, since if you don't set it the correct value is extracted by
asking tclsh. You'd only need to specify it if your Tcl setup is not
internally consistent.
regards, tom lane
I wrote:
> ... if you're
> using cc you probably need configure --with-includes=/usr/local/include
> or configure won't think Tcl is installed at all.
I take that back: AFAICT, configure doesn't actually bother to verify
that tcl.h can be found, it just assumes it's out there. If it's not
in your include search path, then the build will fall over later on.
Perhaps we should add a configure test to ensure tcl.h is available if
you've said --with-tcl?
regards, tom lane
Tom Lane writes: > One possibility is that your compiler may not be set to search > /usr/local/include by default. Correct, OpenBSD's gcc does not do that. > I have in fact done this --- HPUX likes nonstandard prefixes ;-). IIRC, > you must set --with-includes and --with-libraries, and your PATH had > better find the appropriate version of tclsh first. It would appear > >from looking at configure that the --with-tclconfig option is fairly > useless, since if you don't set it the correct value is extracted by > asking tclsh. You'd only need to specify it if your Tcl setup is not > internally consistent. The idea might have been that you could select which one of several installed Tcl version to use. E.g., if you have a cutting edge experimental build somewhere you could use --with-tclconfig=$HOME/tcl-install/lib. Anyway, the problem here seems to be that the tclConfig.sh file does not provide a variable that gives a hint where to look for include files. There are a dozen variables for library things, but zero for cpp flags or includes. If someone finds one, let me know. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
>> better find the appropriate version of tclsh first. It would appear
>> from looking at configure that the --with-tclconfig option is fairly
>> useless, since if you don't set it the correct value is extracted by
>> asking tclsh. You'd only need to specify it if your Tcl setup is not
>> internally consistent.
> The idea might have been that you could select which one of several
> installed Tcl version to use. E.g., if you have a cutting edge
> experimental build somewhere you could use
> --with-tclconfig=$HOME/tcl-install/lib.
Right, but AFAICT it's sufficient (and perhaps also necessary) to make
sure that your cutting-edge Tcl is first in your PATH. If you do
PATH=$HOME/tcl-install/bin:$PATH configure ...
then the same result is achieved by asking tclsh where to search for
tclConfig.sh. I am not sure whether tclsh is used for anything else
during the build; if it isn't then setting PATH isn't essential.
(In the perl case it *is* essential to set PATH...)
> Anyway, the problem here seems to be that the tclConfig.sh file does not
> provide a variable that gives a hint where to look for include files.
'Twould be nicer if it did that, all right.
regards, tom lane
On Sat, May 05, 2001 at 08:48:51PM -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > > Anyway, the problem here seems to be that the tclConfig.sh file does not > > provide a variable that gives a hint where to look for include files. > > 'Twould be nicer if it did that, all right. > > regards, tom lane Yup. I think that is an oversight for tcl. I looked at 8.3.3 and it is the same as 8.3.2. The best you can do is the default place is $(TCL_PREFIX)/include. But even that can be overridden by tcl's configure --includedir=<nowheregood> directive. So anyone know where one submits issues for TCL at these days?
> > I have in fact done this --- HPUX likes nonstandard prefixes ;-). IIRC, > > you must set --with-includes and --with-libraries, and your PATH had > > better find the appropriate version of tclsh first. It would appear > > >from looking at configure that the --with-tclconfig option is fairly > > useless, since if you don't set it the correct value is extracted by > > asking tclsh. You'd only need to specify it if your Tcl setup is not > > internally consistent. > > The idea might have been that you could select which one of several > installed Tcl version to use. E.g., if you have a cutting edge > experimental build somewhere you could use > --with-tclconfig=$HOME/tcl-install/lib. I had a pltcl issue here yesterday. I fixed the problem, but I noted that pltcl is linked not using information from Makefile.shlib, but using commands from tclConfig.sh. Not sure this is wrong, but it certainly can cause problems if tclConfig.sh and Makefile.shlib don't match. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I had a pltcl issue here yesterday. I fixed the problem, but I noted
> that pltcl is linked not using information from Makefile.shlib, but
> using commands from tclConfig.sh. Not sure this is wrong, but it
> certainly can cause problems if tclConfig.sh and Makefile.shlib don't
> match.
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.
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?
regards, tom lane
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
> 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. > > 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? The cause for me was my misconfiguration during a reinstall of tcl 8.0.5. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026