Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries
От | Ants Aasma |
---|---|
Тема | Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries |
Дата | |
Msg-id | CA+CSw_tPDYgnzCYW0S4oU0mTUoUhZ9pc7MRBPXVD-3Zbiwni9w@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Using RTLD_DEEPBIND to handle symbol conflicts in
loaded libraries
Re: Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries |
Список | pgsql-hackers |
I had to make oracle_fdw work with PostgreSQL compiled using --with-ldap. The issue there is that Oracle's client library has the delightful property of linking against a ldap library they bundle that has symbol conflicts with OpenLDAP. At PostgreSQL startup libldap is loaded, so when libclntsh.so (the Oracle client) is loaded it gets bound to OpenLDAP symbols, and unsurprisingly crashes with a segfault when those functions get used. glibc-2.3.4+ has a flag called RTLD_DEEPBIND for dlopen that prefers symbols loaded by the library to those provided by the caller. Using this flag fixes my issue, PostgreSQL gets the ldap functions from libldap, Oracle client gets them from whatever it links to. Both work fine. Attached is a patch that enables this flag on Linux when available. This specific case could also be fixed by rewriting oracle_fdw to use dlopen for libclntsh.so and pass this flag, but I think it would be better to enable it for all PostgreSQL loaded extension modules. I can't think of a sane use case where it would be correct to prefer PostgreSQL loaded symbols to those the library was actually linked against. Does anybody know of a case where this flag wouldn't be a good idea? Are there any similar options for other platforms? Alternatively, does anyone know of linker flags that would give a similar effect? Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
Вложения
В списке pgsql-hackers по дате отправления: