On (25/02/14 20:02), Lukas Slebodnik wrote: >On (21/02/14 11:21), Lukas Slebodnik wrote: >>On (21/02/14 10:54), Lukas Slebodnik wrote: >>>On (16/01/14 10:17), Lukas Slebodnik wrote: >>>>On (13/01/14 19:42), Lukas Slebodnik wrote: >>>>>ehlo, >>>>> >>>>>attached patch addresses ticket #2193 >>>>> >>>>>I have just a question about refarray/libref_array.sym >>>>>There is extern function ref_array_debug, which is not defined >>>>>in public header file (not exposed in public API), but it is used in >>>>>ref_array >>>>>unit tests. It needs to be in global section because linker with fail to >>>>>find >>>>>symbol. Should I add any comment to the file libref_array.sym or does >>>>>anyone >>>>>better solution? >>>>> >>>>>LS >>>> >>>>I forgot to include files into lib..._SOURCES, they was not part of dist >>>>tarball. Updated patch is attached. >>>> >>>>I would like to know what we want to do with function ref_array_debug. >>>> >>>>LS >>> >>>The previous patch cannot be applied on ding-libs master due to conflict in >>>Makefile.am >>> >>>Rebased version is attached. >>> >>>LS >> >>and now with correctly resolved problems after rebase. >>Is should have tested patch before sending mail. >> >>LS > >Replying to the different thread. > >>> >>>You started this discussion about version dependency in ding-libs. >>>There is opportunity to be active and help us with testing and reviewing >>>patch. >>>https://lists.fedorahosted.org/pipermail/sssd-devel/2014-February/018553.html >>> >>>Any comments are appreciated. >> >>Certainly. >>[That mail has not hit the downloadable .gz archives yet and there is no git >>branch for it, so building the package on my side will be delayed./ >>The non-gz mailman archive has tabs replaced by spaces.] >>Comments without building thus: >> >>The .sym files should be listed in Makefile.am in a _DEPENDENCIES line >>instead of _SOURCES. When they are in _SOURCES, `touch *.sym && make` >>won't relink the library, when they are in _DEPENDENCIES, they will: >> >>libpath_utils_la_SOURCES = path_utils/path_utils.c >>libpath_utils_la_DEPENDENCIES = path_utils/libpath_utils.sym >> >Nice catch > >>The sym file will be part of `make dist` as before without having it >>to list in _SOURCES. >> >It did't work, but it is not a problem. > > >>>+LIBBASICOBJECTS_0.1.0 { >>>+global: >>>+ simplebuffer_free; >>>+ ... >>>+local: >>>+ *; >>>+}; >>>+ >>>+LIBBASICOBJECTS_0.1.1 { >>>+global: >>>+ simplebuffer_get_vbuf; >>>+} LIBBASICOBJECTS_0.1.0; >> >>Since this is the initial presence of symvers in the library, there is not >>specifically a need to have more than one symbol: there exists no program >>out there that already references the LIBBASICOBJECTS_0.1.0 symbol, >>so you can just put all symbols under _0.1.1. >>This also applies to all the other .sym files. >> >It was not necessary to write symvers in this way. I wanted to write reference >implementation of version symbol file. So, it would be easy to extend symvers >in the future even for beginners. > >> >>Referring to libini_config for this next example: >> >>The symbol name is connected to the library, so it does not need to try to >>be unique across the entire system AFAICS. If you like you can make it >>shorter, >>for example "ABI_4 { ... }" to point out that these functions were added >>in version 4 (cf. libtool number in -version-info). Or V_4. Whichever :) > >This is true. I checked installed libraries on my desktop and it seems to be >unwritten rule to use uppercased name of library for this purpose. >Some libraries contain also string LIB in this identifier > e.g libidn.so.11 (LIBIDN_1.0), libxml2.so.2(LIBXML2_2.4.30) > libvirt.so.0(LIBVIRT_0.0.3), > libsystemd-daemon.so.0(LIBSYSTEMD_DAEMON_31) >Other libraries ommit string LIB from identifier > e.g libsolv.so.0(SOLV_1.0), libtevent.so.0(TEVENT_0.9.9) > libgcrypt.so.11(GCRYPT_1.2), libnss3.so(NSS_3.2) > >Only two libraries from package setools-libs use identifier VERS_4.1 > e.g libseaudit.so.4, libapol.so.4 > >The biggest group uses upperace identifier without string LIB. >I decided to remove "prefix" LIB. > >Updated patch is attached > >Thank you very much for your comments. > >LS
Jan, Do you have any other comments to the patch from previous mail? LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
