On Tue, 14 Mar 2017 15:52:20 +0000 Emil Velikov <[email protected]> wrote:
> On 14 March 2017 at 11:31, Pekka Paalanen <[email protected]> wrote: > > On Tue, 21 Feb 2017 16:14:26 +0000 > > Emil Velikov <[email protected]> wrote: > > > >> From: Emil Velikov <[email protected]> > >> > >> Used only internally and explicitly marked as such with commit > >> cf04b0a18f2 ("Move private definitions and prototypes to new > >> zwayland-private.h") > >> > >> Signed-off-by: Emil Velikov <[email protected]> > >> --- > >> src/wayland-util.c | 18 +++++++++--------- > >> 1 file changed, 9 insertions(+), 9 deletions(-) > > > > Hi, > > > > R-b me and pushed: > > 9b78be6..654dee8 master -> master > > > > > > Let's see if anyone screams and forces us to revert. These have not > > been in public headers even in 1.0 release. > > > Thanks and let's hope we don't have to revert it. > > > I verified with 'nm -g --defined-only' that this patch indeed does stop > > exporting the symbols. > > > I think you want `nm -CD --defined-only' here, since -g produces "no > symbols" even for libraries such as libGL.so. > Strictly speaking D is not needed, since it demangles any C++ symbols. Hmm, yes... still the output was completely what I was expecting. $ nm -g --defined-only $WLD/lib/libwayland-*.so > newsyms.txt $ nm -CD --defined-only $WLD/lib/libwayland-*.so > newsyms2.txt The results are identical. Why is that, and why is it not that with libGL.so? I feel like I'm missing some shared object basics here. If I am to trust and understand http://stackoverflow.com/questions/15345543/when-to-use-dynamic-option-in-nm it seems that I would actually want -g --defined-only because I'm interested only in symbols usable from outside. In addition I would want -D to look at the dynamic table which will be used by the runtime linker. So actually I'd want all those options? Which means I was actually comparing the static linking tables of a... shared object file... which doesn't make any sense? That leaves a fun question of what kind of symbol would be defined, in the dynamic table, but not exported. Perhaps a weak function with an implementation but allowed to be overridden by another provider exporting the same? Just for fun: $ diff -u <(nm -DC --defined-only /usr/lib/libGL.so.1.2.0 ) <( nm -gDC --defined-only /usr/lib/libGL.so.1.2.0 ) --- /dev/fd/63 2017-03-15 12:19:45.931004715 +0200 +++ /dev/fd/62 2017-03-15 12:19:45.931004715 +0200 @@ -1,6 +1,3 @@ -0000000000272a88 b __bss_start -0000000000272a88 d _edata -00000000002735a8 b _end 0000000000059054 T _fini 0000000000017dd8 T _init 0000000000052da0 T glAccum I'll try to remember to use 'nm -gDC --defined-only' in the future, correct? > > I haven't looked at the other patches yet, this seemed like something > > to get in early in a release cycle. > > > > I still can't make my mind about the extra .so introduced in patch 3. > > > Anything I can do to sway you to the dark side ? > If Linux distribution is one of the core concerns I won't mind sending > them a patch or two. That's the thing, I can't seem to form even questions about it. I suppose I just really don't care as it is. Thanks, pq
pgpp5XtsZb2iz.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
