Re: Private symbols in libpcap, libmagic, libexpat

"Greg A. Woods" <[email protected]> Tue, 17 Dec 2024 18:05:21 -0800
Newsgroups gmane.os.netbsd.devel.userlevel
Organization Planix, Inc.
Message-ID <[email protected]>
At Tue, 17 Dec 2024 23:52:11 +0000, Taylor R Campbell <[email protected]> wrote:
Subject: Private symbols in libpcap, libmagic, libexpat
>
> Currently we build libpcap, libmagic, and libexpat with various
> private symbols exported accidentally because our build system was
> missing -fvisibility=hidden and associated CPPFLAGS.
>
> The attached patch fixes this (and as a side effect should unbreak the
> MKINET6=no build).

Awesome!  Thanks!


But also libldap now fails because of, I think, MKKERBEROS=no (and thus
USE_KERBEROS=no):

--- /Volumes/work/woods/g-NetBSD-src/external/bsd/openldap/lib/libldap_r/ldap_r.expsym  2024-12-08 17:36:22
+++ libldap_r.so.6.0.actsym     2024-12-17 17:25:06
@@ -164,11 +164,6 @@
 ldap_int_error_init
 ldap_int_flush_request
 ldap_int_global_options
-ldap_int_gssapi_close
-ldap_int_gssapi_config
-ldap_int_gssapi_get_option
-ldap_int_gssapi_mutex
-ldap_int_gssapi_set_option
 ldap_int_hostname
 ldap_int_hostname_mutex
 ldap_int_inet4or6
libldap_r.so.6.0: error: actual symbols differ from expected symbols
--- libldap_r.so.6.0.diffsym ---

*** Failed target: libldap_r.so.6.0.diffsym
*** In directory: /Volumes/work/woods/g-NetBSD-src/external/bsd/openldap/lib/libldap_r


I'm guessing (with the help of ldap-int.h) that the "ldap_int_" prefix
on those symbols mean "internal to ldap" though I also see "ldap_pvt_"
prefixes in the code....


> So it might be worthwhile to pull up the change _without_ a major bump
> even though that technically violates the rules.

I think not doing version major bumps for this is the right choice,
probably all-around, but certainly for libpcap and libexpat.

It is arguably the more conservative choice as well since all it is
doing is to nails down what's really supposed to be in a library's ABI
to just what's in its API, and as you point out, at least for both
libpcap and libexpat, this is the way upstream was already building
anyway.


--
					Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>
signature.asc (application/pgp-signature, 195 B)
-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCZ2It2AAKCRBmfXG3eL/0
f1LSAKCWAIXY1Z1soIl7Pacy//gN+f3XyACgokQ/JV1JjP9ZcOim86ByI69z1SQ=
=kjV/
-----END PGP SIGNATURE-----