Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution
Hi David, Any comments ? I'm delighted to see such a mature attitude in the project, an attitude which levels the project with those of giants like Microsoft and Sun, who go through the same kind of hoops to maintain binary compatibility. BTW, I'm not a FreeType developer so I cannot address your specific comments and my feedback is just general thoughts. but there are still cases where a program obtains a FT_Face object through libfreetype7, then call an internal function in libfreetype6, You're talking about libraries which accept/offer FreeType structures in their public APIs, e.g. (just an example -- I never checked) Pango exposes a PangoFont's underlying FT_Face via public API function such as: FT_Face* pango_font_get_freetype_face(PangoFont* font) ? - first of all, install the next release as libfreetype6. RIGHT !! In case we aim for full compatibility and pose ourselves as an incremental release, right -- the name has to stay. Some libraries allow themselves the privilege of breaking binary compatibility. For example, Qt does it routinely (i.e. Qt2 vs. Qt3 vs. Qt4). I wonder what makes FreeType different. Distros also acknowledge this right of libraries to break BC by issuing massive recompilations and changes in the names of packages (e.g. when libstdc++.so changes yet again in some binary-incompatible manner). However, with FreeType being such a basic infrastructure library, we should try to ensure we've exhausted all options for keeping binary compatibility before we break it. An alternative is a Linux-style "no stable API" approach, which positions the software's dynamic nature (and developer's joy of being able to perform drastic revolutions without caring for consequences) above binary/API stability. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] web page for the forthcoming 2.2.0 release
Werner LEMBERG wrote: What kind of problems would the version bump cause? Indirect dependencies. That's exactly what's described in this section: http://plan99.net/autopackage/Linux_Problems#elf Are we not bumping versions simply to force all applications to fix their code rather than sticking to their old-and-working FreeType version? The very problem is that this won't happen within a short time frame. Let's assume that the new FreeType DLL version is version 7, and his desktop uses version 6. If a developer now links his application against FreeType, there are high chances that his application is linked against version 6 *and* version 7 at the same time because many other libraries of his desktop depend on the old FreeType DLL. I can't think of many programs which actively use FreeType functions on their own. Typically, it's just the low-level layer, such as Pango and fontconfig, which relies on FreeType, and low-level layers usually need to be built (by the distro) for the same set of libraries for more reasons, such as libpng.so.2 vs. libpng.so.3 incompatibilities. Perhaps we shall *rename* the library to, say, `libft2', instead of `libfreetype', together with a new API prefix `FT2_' instead of `FT_'. This would avoid the whole mess. Renaming the library is not required, as the version prefix makes the name different enough. As the above-linked document says, the only thing that makes any difference is the symbol name, since in ELF, all symbols are global. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] web page for the forthcoming 2.2.0 release
Werner LEMBERG wrote: [discussion continued on freetype-devel only] Sorry for that. I was to quick to press Send. A new version which makes such a radical change should bump up the shared object version (.so.N). Where's the `radical change'? Symbols which were previously exported are no longer exported. This is exactly the kind of compatibility changes .so version numbers are intended for. It's just like when you change a COM interface, no matter if the function you've changed was marked INTERNAL in screaming caps, you'd still change the interface UUID. That way we'll allow a transition period for applications to update. This has been discussed recently on the FreeType list, and the consensus seems to be that it is better to fix the applications than to increase the DLL version to avoid even more problems. Sorry, I didn't notice this discussion :/ Although I'm not a FreeType developer, I'd express my opinion on this since I feel strongly about having the best level of binary compatibility on the free desktop and to avoid the problems described in the famous Linux Problems document[1]. What kind of problems would the version bump cause? Are we not bumping versions simply to force all applications to fix their code rather than sticking to their old-and-working FreeType version? [1] http://plan99.net/autopackage/Linux_Problems ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64 andi386
On Thu, 2005-12-08 at 02:01 +0900, [EMAIL PROTECTED] wrote: Hi, On Wed, 7 Dec 2005 11:30:03 +0100 Antoine Leca [EMAIL PROTECTED] wrote: BTW, this is not really cross-compiling. Real cross-compiling IMHO usually involves having a cross-compiling target environment, different from the host environment (usually selected as higher priority flags overriding the normal ones). Yeah, as you pointed out, the standard cross-compiling... Okay, so it's not cross-compiling in the normal sense of the word. Still, x86_64-targeted gcc can emit i386 code very easily (by adding the -m32 argument) so any x86-64 installation can easily double as an i386 build machine. ... but I don't know if it's for developer environment compatibility. I'm afraid that there are many softwares that we cannot share header files between i386 and x86-64 architechtures. (Frederic Crozat pretty much said it all... And whatever they do in Mandriva, is also done in Red Hat and Fedora.) Having installed, on Fedora, many development packages in both x86_64 and i386 versions concurrently, there are hardly any packages that collide. Whenever headers are arch-specific, they're either: 1. Moved to lib (e.g. /usr/lib/glib-2.0/include/glibconfig.h) 2. Moved to a special directory (e.g. /usr/include/asm-x86_64/errno.h) I prefer option (1), since option (2) is only used by the Linux kernel. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] No support for side-by-side installation of x86-64 and i386
Hi, Currently, freetype i386 and x86-64 collide in the following files: /usr/bin/freetype-config /usr/include/freetype2/freetype/config/ftconfig.h This makes installation of two freetype development kits impossible. Installing two development kits is desirable when the developer does plenty of cross-compiling to x86-64/i386, which is often the case on x86-64 machines. It would be very much desired that: 1. freetype-config would be recoded to detect its environment and return the appropriate directories, thus creating a single copy of freetype-config on equal-prefix builds *or* freetype moved to pkgconfig (freetype-config may remain a frontend) 2. ftconfig.h would be moved to the lib(64)/config directory, just as it is for glib2 etc. How do you guys feel about it? (Please CC me, as I'm not subscribed to the mailing list.) ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
