On Wed, Aug 23, 2006 at 12:11:57PM +0200, Alexander Leidinger wrote: > If someone doesn't like the base system libldap, but wants the > nss_ldap stuff, this way will not work out. While building the base > system, no 3rd party libs are known to the build infrastructure. > > Conflicting libs aren't good and some people may want to have more > recent versions of a lib installed. To solve this issue phk didn't > importet "libxml", but renamed it to "libbsdxml" (we only need to > update the lib if we need a new feature, or if there's a security > problem). This way base system tools are able to use a XML lib while > ports can use a more recent version of it (ports aren't using our > version of the lib). > > So this is not like the openssl or kerberos cases from the > lib-handling point of view (I'm talking about the ports<->basesystem > interaction, not about updating the lib in the basesystem). > > 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. In fact, similar problem was fixed not so long time ago by Dag-Erling in the pam_ssh (duplicating existing symbols by the pam).
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC