Re: Problem linking libecpg.5.3.dylib on OS X

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Meskes <meskes(at)postgresql(dot)org>, Joachim Wieland <joe(at)mcknight(dot)de>
Subject: Re: Problem linking libecpg.5.3.dylib on OS X
Date: 2007-01-12 03:47:32
Message-ID: 204.1168573652@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> I'm seeing the following on cuckoo:
> -L/opt/local/lib -lpgtypes -lpq -lm -o libecpg.5.3.dylib
> ld: Undefined symbols:
> _ecpg_internal_regression_mode
> /usr/bin/libtool: internal link edit command failed

It looks like Joachim's last patch thinks it's OK for libecpg to try to
reference a variable declared by the calling program. This will
surely Not Work everywhere, and even if it did work it'd be a bad idea
because it would guarantee that existing calling programs would break at
the next libecpg update. The reference has to go the other way.

Actually I'd suggest that using an exported variable at all is probably
bad style. I'd suggest that libecpg export a set() function instead:

static int ecpg_regression_mode = 0;

void ecpg_set_regression_mode(int mode) {
ecpg_regression_mode = mode;
}

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-12 04:37:19 Re: Corrupt database? 8.1/FreeBSD6.0
Previous Message Tom Lane 2007-01-12 03:39:47 Re: [HACKERS] Checkpoint request failed on version 8.2.1.