Date: Thu, 28 Nov 2019 15:27:17 +0100 From: Peter Blok <pblok@bsd4all.org> To: Konstantin Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: dynamic loadable library multiple degined symbols Message-ID: <B346A68D-59B9-42E0-8553-01224F584E5F@bsd4all.org> In-Reply-To: <58EC7517-CFE7-442F-9A9B-00849E32BCA4@bsd4all.org> References: <BEA0011D-0981-4FF7-8035-3D26C94FDD36@bsd4all.org> <20191128131211.GQ10580@kib.kiev.ua> <58EC7517-CFE7-442F-9A9B-00849E32BCA4@bsd4all.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_C171FF62-931F-469B-9146-B31C901F3B65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your pointers helped me find a solution. The samba build environment generates a runner script to build the = module. I have added this symbol in the script amongst other = =E2=80=9Chidden=E2=80=9D ones and it now works. Now I have to find out where and how the script is generated and have a = patch ready for upstream. > On 28 Nov 2019, at 14:48, Peter Blok <pblok@bsd4all.org> wrote: >=20 > I=E2=80=99m trying to change this because named dies with an assert. = named checks the arguments of dns_name_equal which is completely = different from the one intended out of the shared module. >=20 >=20 >> On 28 Nov 2019, at 14:12, Konstantin Belousov <kostikbel@gmail.com> = wrote: >>=20 >> On Thu, Nov 28, 2019 at 01:50:15PM +0100, Peter Blok wrote: >>> Hi, >>>=20 >>> named (bind9.14) has a function called dns_name_equal. = (0000000000443ac0 T dns_name_equal) >>>=20 >>> named dynamically loads dlz_bind9_14.so is build from dlz_bind9.c = and calls this function, but dns_name_equal was undefined so it got = resolved to the version of named. >>>=20 >>> The function is defined in dns_utils.c, so I changed the building to = include that file. >>>=20 >>> Now dlz_bind9_14.so is using dlz_bind9.c and dns_utils.c also has = the right dns_name_equal (000000000000bee0 T dns_name_equal) defined >>>=20 >>> Unfortunately the code inside dlz_bind9_14.so still calls the = function out of named. >>>=20 >>> Is this something that should have been resolved at compile/link = time of dlz_bind9_14.so? If so, how? >> No, default ELF name resolution rules would give the behaviour you = described, >> assuming the main binary was linked with -Wl,-E (and it must be to = export >> symbols to loadable modules). The shared libraries and loadable = modules >> are interposable by default, unless linked with -B symbolic, and the = symbol >> resolution order starts from the main binary object. >>=20 >> Why do you try to change this ? >>=20 >>>=20 >>> Note that the samba build uses waf and wscript files. >>>=20 >>> Peter >>>=20 >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_C171FF62-931F-469B-9146-B31C901F3B65 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBSAw ggUcMIIEBKADAgECAhEAq2wFIs+rCK6H6/2jbblXhDANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNDE0MDAwMDAwWhcNMjEwNDEzMjM1 OTU5WjBEMQswCQYDVQQGEwJOTDETMBEGA1UEAxMKUGV0ZXIgQmxvazEgMB4GCSqGSIb3DQEJARYR cGJsb2tAYnNkNGFsbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPT/3evs2a zLSIVepGa9qFVcSISd5HzoJt9xAyQ4od7NM6Qzwm446OyhzWsIN/a6+nDNB4AxzSg00QXKx4afEa FrdLzmREEfv24f88j2UZYqHAls0j26jyED5FZ068xs4gWZBG2U7EVTUNNJuUrrmqBNZkGxTIrFrD Cgr1EpRULpN+HrEelHHh7uR0twAjvwcyXkG9DbDJXnw8HzKGR80ik4+13HDxx4mDxOY4NOvWSSiM kEFS2Z2AKtxXSMBQZHazAUvbka27c1m93/QsjnDF+P6Aef9NEvUDL9mU9Jbf/+5V+anT2KdPGP4p rQ9gA/Nup61qxDkwc+RupiXD5NSbAgMBAAGjggGzMIIBrzAfBgNVHSMEGDAWgBSCr2yM+MX+lmF8 6B89K3FIXsSLwDAdBgNVHQ4EFgQUjwe7n1zvxFkTeCUYWrsaJpOGP14wDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBV BggrBgEFBQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t b2RvY2EuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQC85hVlqTVwt218IJR/WjMiMnDtZ7hY860XKjzO uB3sUUQwHxHj+ZYuMbAfVLZGGqh1EekbwDMVgkK9cezIHM+ZzxrNGX2SJyl1YW+3FLn52P0uIlmA VPFjUowf5qBhOHl2NJo+WXYZhQY7rT/xSygE81o3oLE/A4zO6WtO3PeZpFpZNrBvizAsjTDfPeXW iQzXz6NLrgwert0Wml95ov2rG5oCzHYPijabubSNm2NdUjPRtcVylcqAThXOvp6X4UvW8/L0uhkp 9WsKP2JEJ3Zukv7Ib+vMBsdE4tf4rmv89pQC+lLpD08ze/QDCIeFBCRIihcC2PycDQrnNIp1RAIh MYIDyjCCA8YCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0 ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA q2wFIs+rCK6H6/2jbblXhDANBglghkgBZQMEAgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTI4MTQyNzE4WjAvBgkqhkiG9w0BCQQxIgQgBw5Q8d9r CVwl4qLJN7Esem/xZ5c+N/cIY9kbNeV7/w8wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCrbAUiz6sIrofr/aNtuVeEMIHABgsqhkiG 9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMT NENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCr bAUiz6sIrofr/aNtuVeEMA0GCSqGSIb3DQEBAQUABIIBAAY945hgvIrb6d+lhct8wspXye5PBgQW IjzDB9JpX2ra9GB4/I8faYnRKt9XuRpcXwQcR7wPu+57GgyDsA0/5/R5uy9IauSLdz4C+3iQZ35Q qB9YP8XjP32eu+aUyQiEzZ9DO9RHm1SgXON8BNbCQkZ6qPD2V4dsspKDw5Zo/FOBTntxHCvLxKJF P0Thx0qWiyJMGAUThPHMaD+sMTOM6XG+1uhHNeZhUSf3SvNxjYBkdRKM4sbSI7pNQh6N6iyma0bz +WPPvP/W97QlQXBqfQ4so2czpd6SCKILlaEqp12E7+yegKWhdEojZ943HXJWBCKvNHfPeTEkI46H xBrXtoEAAAAAAAA= --Apple-Mail=_C171FF62-931F-469B-9146-B31C901F3B65--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B346A68D-59B9-42E0-8553-01224F584E5F>