On Sun, 2005-07-24 at 08:26 +0200, Werner LEMBERG wrote: > > So, are there any plans for next major release in near future? > > Yes, in autumn. > > > Will the ABI change other than hiding these internal functions? > > It will get a new major .so version (at least this was the concensus > on this list, IIRC), but there won't be any major changes in the code > itself, I think.
I probably brought this up last time as well, but just wanted to
reemphasize something here:
Changing the soname of a base library like FreeType does *not* give
parallel install.
What one might think is "OK, we can just rebuild a few things Pango
and fontconfig and not worry about big packages like OpenOffice
and Mozilla - they can keep on using libfreetype.so.6, which we
can keep around as a compatibility library.
This doesn't work because OpenOffice links to GTK+, and fontconfig,
etc, so if OpenOffice isn't rebuilt, then it will link to *both*
libfreetype.so.6 and libfreetype.so.7. This will produce all sorts
of badness.
So, as long as people are willing to fix the few known things that
break (and this can be enforced at a packaging level with statements
like Conflicts: pango <= 1.8.2) keeping the same soname is actually
the *safer* option.
It's certainly workable to deal with a soname change as well -
the way we'd do it is by simply replacing the library and rebuilding
everything that breaks: Mozilla, and OpenOffice, and X, etc... 30-40
packages in Fedora Core 4. A little painful, but soon over.
(Assuming that people don't have 3rd party binaries that depend on
the system libfreetype. We don't guarantee binary compatibility
between successive versions of RHEL and definitely not of Fedora
so it isn't a theoretical problem, but it definitely makes people
grumpy when their binaries stop working.)
> We probably should use libtool's `-export-symbols' option to really
> hide the internal functions; any further advice on this topic is
> highly welcome.
-export-symbols is pretty straightforward to use - we use it (or
actually, -export-symbols-regex for Pango). You probably could build
the symbol file pretty easily by scanning the for FT_EXPORT ...
well, if you didn't use that for internal symbols.
With recent GCC you have a couple of other options that can improve
the efficiency by avoiding dynamic symbol lookup for internal symbols -
you can tag internal symbols with __attribute__((visibility("hidden"))).
Or with very recent GCC, you can build the whole library with
-fvisibility=HIDDEN and tag just the exported functions with
__attribute__((visibility("default"))) which is nicely compatible
with the Windows way of doing things.
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
