Description of problem: Bumping the SO_NAME to 7.0.0 breaks compatibility for dependent applications linked against earlier versions of libgfapi. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: http://review.gluster.org/9036 (api: versioned symbols in libgfapi.so for compatibility) posted (#17) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9036 (api: versioned symbols in libgfapi.so for compatibility) posted (#18) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9036 (api: versioned symbols in libgfapi.so for compatibility) posted (#19) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9036 (api: versioned symbols in libgfapi.so for compatibility) posted (#20) for review on master by Kaleb KEITHLEY (kkeithle)
COMMIT: http://review.gluster.org/9036 committed in master by Vijay Bellur (vbellur) ------ commit 7e497871d11a3a527e2ce192e4274322631f27d0 Author: Kaleb S. KEITHLEY <kkeithle> Date: Mon Nov 3 16:07:30 2014 -0500 api: versioned symbols in libgfapi.so for compatibility Use versioned symbols to keep libgfapi at libgfapi.so.0.0.0 Some nits uncovered: + there are a couple functions declared that do not have an associated definition, e.g. glfs_truncate(), glfs_caller_specific_init() + there are seven private/internal functions used by heal/src/glfsheal and the gfapi master xlator (glfs-master.c): glfs_loc_touchup(), glfs_active_subvol(), and glfs_subvol_done(), glfs_init_done(), glfs_resolve_at(), glfs_free_from_ctx(), and glfs_new_from_ctx(); which are not declared in glfs.h; + for this initial pass at versioned symbols, we use the earliest version of all public symbols, i.e. those for which there are declarations in glfs.h or glfs-handles.h. Further investigation as we do backports to 3.6, 3.4, and 3.4 will be required to determine if older implementations need to be preserved (forward ported) and their associated alias(es) and symbol version(s) defined. FWIW, we should consider linking all of our libraries with a map, it'll result in a cleaner ABI. Perhaps something for an intern to do or a Google Summer of Code project. Change-Id: I499456807a5cd26acb39843216ece4276f8e9b84 BUG: 1160709 Signed-off-by: Kaleb S. KEITHLEY <kkeithle> Reviewed-on: http://review.gluster.org/9036 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Niels de Vos <ndevos> Tested-by: Niels de Vos <ndevos> Reviewed-by: Vijay Bellur <vbellur>
Breaks build on Mac OS X
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#1) for review on master by Kaleb KEITHLEY (kkeithle)
Here's an example of aliases based on the __DARWIN_ALIAS family of macros defined in <sys/cdefs.h> on OS X. ================ foo.h ================ extern int foo (const char *) __asm("_foo$GFAPI_340"); ========================================= ================ foo.c ================ #include <stdio.h> #include "foo.h" int foo (const char *str) { printf ("%\n", str); } ================ foo.c ================ ============== driver.c =============== #include "foo.h" int main (int argc, char **argv) { return foo ("hello"); } ============== driver.c =============== and then % nm driver.o ... U _foo$GFAPI_340 ... % nm foo.o ... T _foo$GFAPI_340 ... N.B. OS X still has the old pre-ELF compiler semantics of prefixing symbols with '_'. E.g. open(), close(), read(), write(), etc., in a nm dump of libc you'll see the symbols _open, _close, _read, _write, etc.
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#2) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#3) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#4) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#5) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#6) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#7) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#8) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#9) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#10) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9143 (api: versioned symbols in libgfapi.so for compatibility) posted (#11) for review on master by Kaleb KEITHLEY (kkeithle)
REVIEW: http://review.gluster.org/9433 (api: OSX build support provided) posted (#1) for review on master by Harshavardhana (harsha)
COMMIT: http://review.gluster.org/9143 committed in master by Shyamsundar Ranganathan (srangana) ------ commit c49a77001bd80affa70d22ba974d8de9e3f0f0cd Author: Kaleb S. KEITHLEY <kkeithle> Date: Tue Nov 18 11:08:16 2014 -0500 api: versioned symbols in libgfapi.so for compatibility Use versioned symbols to keep libgfapi at libgfapi.so.0.0.0 Revisited to address broken build on Mac OS X See http://review.gluster.org/9036 Rebased to include http://review.gluster.org/#/c/9376/ (glfs_resolve()) but note that gerrit's "Rebase Change" couldn't do it. N.B. noticed that glfs_get_volumeid() decl in glfs.h was missing the __THROW, added it. On systems using ELF and the GNU toolchain, symbol versions are created with a .symver asm operand in the .c source file. Clang is claimed to be compatible with gcc, so we'll pretend for now that this also works with clang. On Mac OS X, aliases are created with __asm "magic" in the .h header file. In the normal case, when both the decl and defn match, that's all that's needed. In our case though the decl and defn don't match --- we have, e.g. a defn such as 'int glfs_foo(...)' and the corresponding decl is 'int pub_glfs_foo(...)'. To make this work we create the necessary aliases in the library at link time with the -alias_list link option. Note that this results in there being pairs of symbols in the .dylib, e.g. _pub_glfs_foo and _glfs_foo$GFAPI_3.4.0. We could use another link option, -unexported_symbols_list to elide the _pub_glfs_* symbols. (And we probably should.) Linux symbol versioning was essentially copied from Solaris; in general I would expect this to "just work" on Solaris, but until someone tries we don't really know. Change-Id: Icb96a3c2d80be7b6d7a6849bb9168f03a947f47c BUG: 1160709 Signed-off-by: Kaleb S. KEITHLEY <kkeithle> Reviewed-on: http://review.gluster.org/9143 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Niels de Vos <ndevos> Reviewed-by: Shyamsundar Ranganathan <srangana>
REVIEW: http://review.gluster.org/9439 (api: versioned symbols for glfs_resolve()) posted (#1) for review on master by Ravishankar N (ravishankar)
COMMIT: http://review.gluster.org/9439 committed in master by Niels de Vos (ndevos) ------ commit 6da85222e5e49bcb15c4c8998f26c8dffb6a5b34 Author: Ravishankar N <ravishankar> Date: Fri Jan 9 15:36:42 2015 +0000 api: versioned symbols for glfs_resolve() A minor fix not addressed in http://review.gluster.org/#/c/9143/. Needed by http://review.gluster.org/#/c/9377/5/ to resolve a merge conflict and for a sucessful compile without warnings about implicit declarations. Change-Id: I4aeb3b53887687096b69516c42a0888c6e137bf6 BUG: 1160709 Signed-off-by: Ravishankar N <ravishankar> Reviewed-on: http://review.gluster.org/9439 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Shyamsundar Ranganathan <srangana> Reviewed-by: Niels de Vos <ndevos>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report. glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user