Re: [PORTS] Re: port v7.0 to SGI-IRIX-6.5.7/64
От | Tom Lane |
---|---|
Тема | Re: [PORTS] Re: port v7.0 to SGI-IRIX-6.5.7/64 |
Дата | |
Msg-id | 21570.959043537@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PORTS] Re: port v7.0 to SGI-IRIX-6.5.7/64 (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-bugs |
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Good point, but that's no solution --- the reason that the makefile >> isn't keeping the main CFLAGS is that Tcl (and hence pltcl) may be >> built with a different compiler than Postgres is being built with. >> The Tcl compiler may not like the other compiler's switches. I guess >> we could arrange to insert just the -I switches from your >> --with-includes configuration command, however. > Tom, do you want his verion in Makefile, or the original? I'm working on it now --- need to fix configure to export a list of just the -I switches, so we can include those into the pltcl build. plperl may have the same problem, haven't looked yet. There is a potential problem in this area that I've actually seen happen, but don't know a way around: the two compilers may have different default search paths. For example, on my system gcc includes /usr/local/include in its default search path, but the system cc does not. So, if you've built Tcl with system cc, and installed it in /usr/local, and then try to build Postgres with gcc and --with-tcl, everything goes fine until you get to pltcl, whereupon it falls over because pltcl will be built with cc and cc doesn't find tcl.h. That will still happen with this fix. The only way to build that configuration successfully is to explicitly say "--with-includes=/usr/local/include --with-libs=/usr/local/lib". Arguably this is a bug in Tcl's tclConfig.sh, since it probably ought to put "-I/usr/local/include" into its own CFLAGS settings when it's been built that way ... but it doesn't ... I don't have an answer to solving that problem automatically, but I thought it'd be good to mention it for the archives. regards, tom lane
В списке pgsql-bugs по дате отправления: