|
Home > Archive > Debian Developers > May 2005 > [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[HELP] libldap2 2.1.30 breakage?, guru for ld.so needed
|
|
| Torsten Landschoff 2005-05-30, 2:48 am |
| Hi *,
People following the OpenLDAP packages might remember this change:
openldap2 (2.1.30-7) unstable; urgency=high
* Stephen Frost <sfrost@debian.org>
+ debian/move_files: make libldap a symlink to libldap_r, as carrying
two versions of this library around is more trouble than it's worth,
and can cause glorious segfaults down the line
(closes: #306258, #302296, #306546)
At first sight this looked (for me) like making sense and having no
negative implications. Of course reality was different - ldconfig had
problems setting the right symbolic links.
Today I found out the reason. It was not that it just removes symbolic
links it can't make sense of. Rather the problem is that the SONAME of
that library now does not match the name anymore.
libldap.so.2 used to have the SONAME libldap.so.2 as you would expect 
Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
libldap_r.so.2.
I wonder which implications that could have when applications are
linking to libldap.so.2 (as the SONAME is no longer found).
Therefore I thought it might be a good idea to relink libldap_r.so.2
using libtool and create libldap.so.2 with matching soname. Now I wonder
what will happen if some program decides he wants to link both
libldap.so.2 and libldap_r.so.2.
Suggestions how to fix that for real before getting sarge out of the
door with this risk that I don't feel I can estimate?
Thanks!
Torsten
| |
| Simon Richter 2005-05-30, 2:48 am |
| Hi,
Torsten Landschoff schrieb:
> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?
Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED
entry for libldap_r.so.2 only.
Simon
| |
| Nigel Jones 2005-05-30, 7:53 am |
| Unless there is a related RC bug there, I don't think it's gonna
matter when the change is to get it in sarge (i personally have not
seen any RC bugs though...)
On 30/05/05, Torsten Landschoff <torsten@debian.org> wrote:
> Hi *,
>=20
> People following the OpenLDAP packages might remember this change:
>=20
> openldap2 (2.1.30-7) unstable; urgency=3Dhigh
>=20
> * Stephen Frost <sfrost@debian.org>
> + debian/move_files: make libldap a symlink to libldap_r, as carryi=
ng
> two versions of this library around is more trouble than it's wor=
th,
> and can cause glorious segfaults down the line
> (closes: #306258, #302296, #306546)
>=20
> At first sight this looked (for me) like making sense and having no
> negative implications. Of course reality was different - ldconfig had
> problems setting the right symbolic links.
>=20
> Today I found out the reason. It was not that it just removes symbolic
> links it can't make sense of. Rather the problem is that the SONAME of
> that library now does not match the name anymore.
>=20
> libldap.so.2 used to have the SONAME libldap.so.2 as you would expect
> Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
> libldap_r.so.2.
>=20
> I wonder which implications that could have when applications are
> linking to libldap.so.2 (as the SONAME is no longer found).
>=20
> Therefore I thought it might be a good idea to relink libldap_r.so.2
> using libtool and create libldap.so.2 with matching soname. Now I wonder
> what will happen if some program decides he wants to link both
> libldap.so.2 and libldap_r.so.2.
>=20
> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?
>=20
> Thanks!
>=20
> Torsten
>=20
>=20
> BodyID:25699729.2.n.logpart (stored separately)
>=20
>=20
--=20
N Jones
| |
| Stephen Frost 2005-05-30, 5:52 pm |
| * Nigel Jones (nigelj@gmail.com) wrote:
> Unless there is a related RC bug there, I don't think it's gonna
> matter when the change is to get it in sarge (i personally have not
> seen any RC bugs though...)
There's RC bugs all over this.
Stephen
| |
| Stephen Frost 2005-05-30, 5:52 pm |
| * Simon Richter (sjr@debian.org) wrote:
> Torsten Landschoff schrieb:
>
>
> Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED
> entry for libldap_r.so.2 only.
Completely breaks dlopen()'ings of libldap2. Don't know if there are
any in sarge but don't see any reason to break them if there are.
Stephen
| |
| Stephen Frost 2005-05-30, 5:52 pm |
| * Torsten Landschoff (torsten@debian.org) wrote:
> At first sight this looked (for me) like making sense and having no
> negative implications. Of course reality was different - ldconfig had
> problems setting the right symbolic links.
setting the right symbolic links? It's not being used to set the
symbolic links any different than it was before, it's just at the end we
twiddle them a bit because having both libraries was a serious problem.
> Today I found out the reason. It was not that it just removes symbolic
> links it can't make sense of. Rather the problem is that the SONAME of
> that library now does not match the name anymore.
Well, no, but the linker can handle that.
> libldap.so.2 used to have the SONAME libldap.so.2 as you would expect
> Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
> libldap_r.so.2.
>
> I wonder which implications that could have when applications are
> linking to libldap.so.2 (as the SONAME is no longer found).
Nothing should care except for the runtime linker, which should handle
the situation correctly.
> Therefore I thought it might be a good idea to relink libldap_r.so.2
> using libtool and create libldap.so.2 with matching soname. Now I wonder
> what will happen if some program decides he wants to link both
> libldap.so.2 and libldap_r.so.2.
All hell breaks loose, that's what caused the various RC bugs I closed
with the message above. You end up randomly getting one set of symbols
that expects to do threading and locking and another set that doesn't.
> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?
Have you actually got a specific problem with the changes I did, or
really, the results of them? There were a couple problems where people
had old libldap2's hanging around (which is a rather serious mistake
anyway...) but I havn't seen any other problems with that change yet...
Thanks,
Stephen
| |
| Stephen Frost 2005-05-30, 5:52 pm |
| * Simon Richter (sjr@debian.org) wrote:
> Stephen Frost schrieb:
>
> dlopen() should handle dependency libs just fine, I think. If dlsym()
> fails because the symbol is actually in another lib, maybe DT_FILTER
> might help.
More ugliness, and it sounds like it's not even clear it'd actually work
in the dlopen()/dlsym() case.. Perhaps if there was actually a problem
with the symlinks, but I havn't heard of one really with them yet..
Stephen
| |
| Simon Richter 2005-05-30, 5:52 pm |
| Hi,
Stephen Frost schrieb:
> Completely breaks dlopen()'ings of libldap2. Don't know if there are
> any in sarge but don't see any reason to break them if there are.
dlopen() should handle dependency libs just fine, I think. If dlsym()
fails because the symbol is actually in another lib, maybe DT_FILTER
might help.
Simon
| |
| Torsten Landschoff 2005-05-30, 5:52 pm |
| Hi Stephen,
On Mon, May 30, 2005 at 09:16:15AM -0400, Stephen Frost wrote:
> Have you actually got a specific problem with the changes I did, or
> really, the results of them? There were a couple problems where people
> had old libldap2's hanging around (which is a rather serious mistake
> anyway...) but I havn't seen any other problems with that change yet...
I had a bad feeling in how the linker or ldconfig would react given that
the soname does not match the file name of the library anymore. After
some discussion on irc I am convinced that the symlink way is the best
thing we can do.
I improved the libldap2.postinst a bit so that it should be able to
handle any libldap.so.2.0.xx leftover files.
Greetings
Torsten
|
|
|
|
|