Thread: Problems with linking against PostgreSQL 8.4
Hi, I tried to build the latest git version of postgresql odbc driver and (even if the build seems to be complete) there is a linkage problem: $ ldd -r ./.libs/psqlodbcw.so > /dev/null undefined symbol: PQconnectdbParams (./.libs/psqlodbcw.so) I see that the symbol was added to PostgreSQL project in ~2010 and it seems to be a problem. Should I expect that newer drivers are able to be run against older (still supported by PostgreSQL community) PostgreSQL server, namely 8.4.13? If that ^^ is a problem, could you please fix that? I could possibly look at some configure.ac/#ifdef solution and propose a patch if you are not against that.. Thanks, Pavel
2013-12-06 18:22 keltezéssel, Pavel Raiskup írta: > Hi, I tried to build the latest git version of postgresql odbc driver and > (even if the build seems to be complete) there is a linkage problem: > > $ ldd -r ./.libs/psqlodbcw.so > /dev/null > undefined symbol: PQconnectdbParams (./.libs/psqlodbcw.so) > > I see that the symbol was added to PostgreSQL project in ~2010 and it > seems to be a problem. Should I expect that newer drivers are able to be > run against older (still supported by PostgreSQL community) PostgreSQL > server, namely 8.4.13? You need to compile against a newer libpq but after that, you can connect to an older server. > > If that ^^ is a problem, could you please fix that? I could possibly look > at some configure.ac/#ifdef solution and propose a patch if you are not > against that.. > > Thanks, Pavel > > > -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
> > I see that the symbol was added to PostgreSQL project in ~2010 and it > > seems to be a problem. Should I expect that newer drivers are able to be > > run against older (still supported by PostgreSQL community) PostgreSQL > > server, namely 8.4.13? > > You need to compile against a newer libpq but after that, > you can connect to an older server. Ah yes, that would be possible, thanks! But still, if that is expected - we should at least check older libpq's via configure.ac and blacklist them, or? It is pretty usual to have installed server & libpq of the same version on the same machine... Pavel
On 12/06/2013 08:42 PM, Pavel Raiskup wrote: >>> I see that the symbol was added to PostgreSQL project in ~2010 and it >>> seems to be a problem. Should I expect that newer drivers are able to be >>> run against older (still supported by PostgreSQL community) PostgreSQL >>> server, namely 8.4.13? >> >> You need to compile against a newer libpq but after that, >> you can connect to an older server. > > Ah yes, that would be possible, thanks! But still, if that is expected - > we should at least check older libpq's via configure.ac and blacklist > them, or? Yeah, a configure test would be nice. Patches are welcome ;-) - Heikki
On Friday, December 06, 2013 23:11:40 Heikki Linnakangas wrote: > On 12/06/2013 08:42 PM, Pavel Raiskup wrote: > >>> I see that the symbol was added to PostgreSQL project in ~2010 and it > >>> seems to be a problem. Should I expect that newer drivers are able to be > >>> run against older (still supported by PostgreSQL community) PostgreSQL > >>> server, namely 8.4.13? > >> > >> You need to compile against a newer libpq but after that, > >> you can connect to an older server. > > > > Ah yes, that would be possible, thanks! But still, if that is expected - > > we should at least check older libpq's via configure.ac and blacklist > > them, or? > > Yeah, a configure test would be nice. Patches are welcome ;-) I'll be glad, just to make it clear :). Do you want remove support for libpq 8.4 completely or make configure check for PQconnectdbParams (to make the code work without PQconnectdbParams)? The later makes more sense to me as 8.4 is still not dead (and will probably exist in REL8_4_STABLE branch some time).
On 12/07/2013 11:40 AM, Pavel Raiskup wrote:
> On Friday, December 06, 2013 23:11:40 Heikki Linnakangas wrote:
>> On 12/06/2013 08:42 PM, Pavel Raiskup wrote:
>>>>> I see that the symbol was added to PostgreSQL project in ~2010 and it
>>>>> seems to be a problem. Should I expect that newer drivers are able to be
>>>>> run against older (still supported by PostgreSQL community) PostgreSQL
>>>>> server, namely 8.4.13?
>>>>
>>>> You need to compile against a newer libpq but after that,
>>>> you can connect to an older server.
>>>
>>> Ah yes, that would be possible, thanks! But still, if that is expected -
>>> we should at least check older libpq's via configure.ac and blacklist
>>> them, or?
>>
>> Yeah, a configure test would be nice. Patches are welcome ;-)
>
> I'll be glad, just to make it clear :). Do you want remove support for
> libpq 8.4 completely or make configure check for PQconnectdbParams (to
> make the code work without PQconnectdbParams)? The later makes more sense
> to me as 8.4 is still not dead (and will probably exist in REL8_4_STABLE
> branch some time)
Actually, now that I look closer into that, the situation is a bit
messy. There's a runtime check in loadlib.c, which tests if the version
of libpq being used has the PQconnectdbParams() function. But we still
link against libpq normally, so the library still won't load if that
function isn't present, even though we have the code in place to check
and refrain from actually calling it. So that's a bit broken.
But even more funnily, the only caller of PQconnectdbParams() is
actually dead code (connection.c):
> if (FALSE && connect_with_param_available())
> {
> const char *opts[PROTOCOL3_OPTS_MAX], *vals[PROTOCOL3_OPTS_MAX];
>
> protocol3_opts_array(self, opts, vals, TRUE, sizeof(opts) / sizeof(opts[0]));
> pqconn = CALL_PQconnectdbParams(opts, vals, &libpqLoaded);
> }
> else
> {
So we don't actually ever use PQconnectdbParams() for anything.
Want to take a stab at cleaning up that mess?
- Heikki
Heikki, > [...] > So we don't actually ever use PQconnectdbParams() for anything. Thanks for this analysis! > Want to take a stab at cleaning up that mess? Yes, I can look at it. Do you plan to public new release in near future? Pavel
> > I'll be glad, just to make it clear :). Do you want remove support for > > libpq 8.4 completely or make configure check for PQconnectdbParams (to > > make the code work without PQconnectdbParams)? The later makes more sense > > to me as 8.4 is still not dead (and will probably exist in REL8_4_STABLE > > branch some time) > > Actually, now that I look closer into that, the situation is a bit > messy. There's a runtime check in loadlib.c, which tests if the version > of libpq being used has the PQconnectdbParams() function. But we still > link against libpq normally, so the library still won't load if that > function isn't present, even though we have the code in place to check > and refrain from actually calling it. So that's a bit broken. Ok, we could theoretically remove the "static" call to PQconnectdbParams() and just have some function pointer which would be set by lt_dlsym(). But I'm not sure this is fundamentally correct approach. The libpq.so library is not IMO designed for such usecase. From my point of view is better approach to not link against PQconnectdbParams at all if that function is not present in the library you are linking against. So possible heads-up patch is attached. > But even more funnily, the only caller of PQconnectdbParams() is > actually dead code (connection.c): > [...] > So we don't actually ever use PQconnectdbParams() for anything. > > Want to take a stab at cleaning up that mess? Actually - there is a lot of non-linux stuff which I am afraid I am unable to test properly (it would take a lot of time). Looking at the code, I could remove a LOT of unused code which would be pity imo. That code seems to call for fix rather than removal.. I could be able to help you more; but I don't know now what is the safe way.. Pavel