On 2004-11-16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> The ldopts value contains compiler-specific shared library linking flags
>> plus information about additional library to link in. The ccdlflags
>> value contains only the compiler-specific shared library linking flags.
>> If we subtract the second from the first, we get the information about
>> additional library to link in, which is what we wanted to get out of
>> it.
Why? The ldopts value is intended to be the flags needed for linking a
program that embeds the perl interpreter, which is what you are doing.
What is the point in trying to second-guess what the flags mean?
> [ thinks ... ] OK, so the problem case is where perl was built with a
> different compiler than we're building PG with,
Which is a non-starter in any event - you can't reliably embed perl into a
program that's compiled with a different compiler than perl was, and I doubt
that you could successfully build libplperl with a different compiler to the
rest of PG and still get it to work.
> Where would he get it from, then? We did talk about providing macros
> for more flexible specification of rpath, so we can fix the problem if
> we can get the Perl library path, but I'm unsure where to learn that.
Oddly enough, that's what ccdlflags is for. So you'd end up removing that
info from ldopts only to add it back... which seems somewhat pointless to
me.
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
