Summary: | Modules are built as versioned shared objects | ||
---|---|---|---|
Product: | cairo | Reporter: | Dominique Leuenberger <dominique-freedesktop.org> |
Component: | general | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | bjorn.lie, freedesktop |
Version: | 1.12.16 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Patch removing version information from modules
Updated patch... |
Description
Dominique Leuenberger
2010-07-30 05:55:02 UTC
Created attachment 60780 [details] [review] Updated patch... Moving to 1.12.2... after all this is still there. I'm not sure about this patch. In fact, none of these libraries ever get dlopen()'d, so why are they marked as -module? I can see the reason for -avoid-version for cairo-trace, because the cairo-trace utility doesn't use any version. Dunno about the other libraries (how/where are they used?) Cairo trace loads it's library in a 'rude' / non-version aware way like this (as you say yourself): if test "x$CAIRO_TRACE_SO" = "x"; then CAIRO_TRACE_SO="" for lib in /usr/lib64/cairo/libcairo-trace.so /usr/lib64/cairo/libcairo-trace.so* /usr/lib64/cairo/libcairo-trace.*.so ; do if test -h "$lib" -o -f "$lib"; then CAIRO_TRACE_SO="$lib" break fi done fi LD_PRELOAD="$CAIRO_TRACE_SO => so whatever versioning is being used, is ignored anyway and can as well not be used ==> -avoid-version makes sense (it is not shared library after all) For -sphinx I'm not sure if the .so ever get's used... this might actually be just a mistake in Makefile.am and the 'library' is not needed at all (It's also never referenced as a dependency) This can be applied without build issues: Index: cairo-1.12.2/util/cairo-sphinx/Makefile.am =================================================================== --- cairo-1.12.2.orig/util/cairo-sphinx/Makefile.am +++ cairo-1.12.2/util/cairo-sphinx/Makefile.am @@ -1,6 +1,5 @@ cairolibdir = $(libdir)/cairo -cairolib_LTLIBRARIES = cairo-sphinx.la bin_PROGRAMS = cairo-sphinx AM_CPPFLAGS = -I$(top_srcdir)/src \ @@ -8,12 +7,6 @@ AM_CPPFLAGS = -I$(top_srcdir)/src \ -I$(top_srcdir)/boilerplate \ -I$(top_srcdir)/util/cairo-script -cairo_sphinx_la_SOURCES = fdr.c -cairo_sphinx_la_CPPFLAGS = $(AM_CPPFLAGS) -cairo_sphinx_la_CFLAGS = $(CAIRO_CFLAGS) -cairo_sphinx_la_LDFLAGS = -module -no-undefined -cairo_sphinx_la_LIBADD = -ldl - cairo_sphinx_SOURCES = sphinx.c cairo_sphinx_CPPFLAGS = $(AM_CPPFLAGS) -DLIBDIR="\"$(cairolibdir)\"" cairo_sphinx_CFLAGS = $(CAIRO_CFLAGS) $(real_pthread_CFLAGS) $(glib_CFLAGS) => cairo-sphinx still runs too (well, it starts and exits.. just as before.. not sure how to test this binary) cairo-fdr: this is apparenty lever loaded / referenced? Might well be just an old reminder that was not cleaned up? ping? (openSUSE carries the patch from comment #0 since 2010 and no issues appeared ever since... ) Just updating the version number again... openSUSE still carries that patch... PING!! Patch still applies for ver 1.15.2. Pretty please with sugar on top, could we reach a conclusion on this? We have had this patch in openSUSE since 2010! This can definitely be committed. (In reply to Behdad Esfahbod from comment #7) > This can definitely be committed. Thanks for the reply Behdad. Somehow that email passed my by without me noticing. As far as I know neither Dominique nor me have commit rights for cairo, so if you could be so kind to do it for us it would be appreciated. Hi Upstream! Please commit the patch, as neither of us downstream people have commit rights. 6 years in the "making" should be enough... I'm sure you know, by now, that no maintainers are left. So, keeping snark down is more productive. In fact, that is the case even more when there are maintainers around. :) Anyway, pushed it out. First: Sorry Behdad! - I was frustrated and snapped. Apologies! Second: Thanks a lot for committing it. Third: Sad to hear that there is no maintainers left for cairo :-/ didn't know that. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.