Quoting Kostik Belousov <kostikbel_at_gmail.com> (Wed, 23 Aug 2006 18:46:52 +0300): > On Wed, Aug 23, 2006 at 05:23:16PM +0200, Alexander Leidinger wrote: > > Quoting Kostik Belousov <kostikbel_at_gmail.com> (from Wed, 23 Aug 2006 > > 13:36:04 +0300): > > > > >On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: > > > > >>An idea which wasn't suggested yet is to install a renamed version (I > > >>would suggest libbaseldap instead of libbsdldap or libldap_i, but I > > >>don't really care about the name) and a link from the original name > > >>(only the .so and .a, but not the .so.X) to the new name. This link > > >>can be protected with a WITHOUT_LIBLDAP_LINK switch (or the other way > > >>around... depending on what we want to achieve). This way it is > > >>possible to link with the renamed lib in the base system, to use the > > >>base system version of the lib in ports, and to use the lib from ports > > >>if desired (a recompile of ports may be needed in the last case, yes). > > > > > >This will not work. bsdxml is used inside the system binaries. No binary > > >links again expat and bsdxml simultaneously. Would such binary exists, > > >it could experience problems. > > > > > >On the other hand, application using openldap from the ports has high > > >chance > > >loading nss_ldap (e.g., due to nsswitch.conf). If nss_ldap linked against > > >renamed library, this would cause the crash. > > > > And this can't be solved with symbol versioning? > > Probably not. Default openldap build produces unversioned libraries. > Application linked against such library would happily resolve symbols > from the versioned lib. Why? In which case does this make sense? Is this an implementation detail or the spec? Bye, Alexander. -- If you care, you just get disappointed all the time. If you don't care nothing matters so you are never upset. -- Calvin http://www.Leidinger.net Alexander _at_ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild _at_ FreeBSD.org : PGP ID = 72077137Received on Wed Aug 23 2006 - 15:14:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC