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
[-- Attachment #1 --] 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 “hidden” 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: > > I’m 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. > > >> On 28 Nov 2019, at 14:12, Konstantin Belousov <kostikbel@gmail.com> wrote: >> >> On Thu, Nov 28, 2019 at 01:50:15PM +0100, Peter Blok wrote: >>> Hi, >>> >>> named (bind9.14) has a function called dns_name_equal. (0000000000443ac0 T dns_name_equal) >>> >>> 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. >>> >>> The function is defined in dns_utils.c, so I changed the building to include that file. >>> >>> 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 >>> >>> Unfortunately the code inside dlz_bind9_14.so still calls the function out of named. >>> >>> 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. >> >> Why do you try to change this ? >> >>> >>> Note that the samba build uses waf and wscript files. >>> >>> Peter >>> >>> >> >> > [-- Attachment #2 --] 0 *H 010 `He 0 *H 0 0 l"ϫmW0 *H 01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA0 180414000000Z 210413235959Z0D1 0 UNL10U Peter Blok1 0 *H pblok@bsd4all.org0"0 *H 0 O̴͚UFkڅUĈIGm2C :C<&㎎ ְk x ҃M\xiKdD<eb#ۨ>EgN YFNU5 4dȬZ T.~ qt #2^A ^|< 2G"plj84I(ARٝ*WHPdvKۑsY,pyM/ٔUاO)`nj90sn%ԛ 00 U #0la| =+qH^ċ0 U \Yx%Z&?^0U 0 U 0 0 U %0++0FU ?0=0; +10+0)+ https://secure.comodo.net/CPS0ZU S0Q0OMKIhttp://crl.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crl0+0}0U+0Ihttp://crt.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0 *H e5pm| Z3"2pgX*<θ QD0 .1 TFu3Bq ϙ}')uao."YTcR a8yv4>Yv;?K(Z7?kNZY6o0,0=։ ϣK _yv6c]R3ѵrʀNξK)k ?bD'vnoDkRO3{$H 4uD!10001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA l"ϫmW0 `He 0 *H 1 *H 0 *H 1 191128142718Z0/ *H 1" Pk \%7,zog>7c5{0 +71001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA l"ϫmW0 *H 101 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA l"ϫmW0 *H =`ߥ|WO"<i_j`x i*W\_ G{ ?y/Hjw>xg~P X??}͟C;GT\|BFzWlÖhSN{q +ĢE?DJ"Lh?13qG5aQ'Jqdu#MB ,kFcϼ%Apj},g3ޒ *]잀tJ#g7 rV"4wy1$#
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B346A68D-59B9-42E0-8553-01224F584E5F>