Hi All,
I'm working on a build of csync2 2.0 for openSUSE, and have run into an
entertaining problem. Rather than linking against the relevant database
client libraries, it uses dlopen() at runtime. But it's dlopen()ing the
unversioned library, i.e.:
db_mysql.c: dl_handle = dlopen("libmysqlclient.so", RTLD_LAZY);
db_postgres.c: dl_handle = dlopen("libpq.so", RTLD_LAZY);
db_sqlite.c: dl_handle = dlopen("libsqlite3.so", RTLD_LAZY);
db_sqlite2.c: dl_handle = dlopen("libsqlite.so", RTLD_LAZY);
This is a problem for two reasons, one being that it means the -devel
packages need to be installed at runtime or those .so symlinks don't
exist. The other problem is that IMO it's just a bad idea to dlopen()
an unversioned library (potential runtime ABI breakage).
Now, in the sqlite2 case, there's actually some fallback code, where if
it can't dlopen("libsqlite.so") it tries to dlopen("libsqlite.so.0").
Personally I'd be in favour of ditching this fallback code and just
changing all the above to:
db_mysql.c: dl_handle = dlopen("libmysqlclient.so.18", RTLD_LAZY);
db_postgres.c: dl_handle = dlopen("libpq.so.5", RTLD_LAZY);
db_sqlite.c: dl_handle = dlopen("libsqlite3.so.0", RTLD_LAZY);
db_sqlite2.c: dl_handle = dlopen("libsqlite.so.0", RTLD_LAZY);
But... Does anyone know how stable are the 18 and the 5 are on
libmysqlcient and libpq? They're fine for current releases of openSUSE,
but I don't want to be submitting patches upstream that are going to
break builds on other distros/versions.
Does anyone know some autofoo to pull the correct versioned soname in at
build time?
Thanks,
Tim
--
Tim Serong
Senior Clustering Engineer
SUSE
tser...@suse.com
_______________________________________________
Csync2 mailing list
Csync2@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/csync2
