Re: [ft-devel] web page for the forthcoming 2.2.0 release
Hi Werner and all, 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. Simply changing the library name is not going to change a lot of things due to the way dynamic linking works with ELF, it's simply equivalent to changing the so version number. Now, if we talk about a new API prefix, we're essentially asking that *all* clients that use FreeType be rewritten to use it, or they'll be stuck with 2.1.10 which we don't want to maintain anymore. However, the percentage of rogue clients (i.e. the one that are going to break due to the new install) is, much smaller, and easier to spot if you have access to their sources (since simple grepping is sufficient) Another option is to use a new API prefix internally, but provide backwards compatibility macros like: #define FT_New_Face FT2_New_Face so that clients can be recompiled without modifications. The macros *should* be disabled when building the library, to that the corresponding object files only contain FT2_ functions. This will avoid any bad ELF magic to happen (though it may make debugging fun :-) However, this will *not* prevent programs from being linked to both libfreetype.so.6 and, say, libft2.so.1 or wathever. Even though the probabilities of crashes will be reduced, it might produce unexpected results. And it will *still* break rogue clients that are compiled against the new version. Which is why I'm wondering if it will solve anything at all ? Sure, you can use your package manager to refuse to install libfreetype.so.6 and libfreetype.so.7 together, but you won't be able to install libfreetype.so.7 until all rogue clients are patched anyway. In other words, the big deal are the rogue clients, not all programs that use FreeType. We need to spot these, and provide patches before making a public release. Another option is to have ./configure refuse to install freetype 2.2.0 if a previous release of the library is detected on the system; that is, unless you use a super-duper parameter like --please-destroy-my-desktop that only the cautious will care to use. Any comments ? - David Turner - The FreeType Project (www.freetype.org) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel *** Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. *** ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Yeah, that and to keep binary compatibility a stub library could be written as a replacement for an old libfreetype.so, which would just dlopen the new .so and call appropriate functions. This is an ugly solution but *should* work until a better solution is found. What do you think? - -- Best regards, Victor Luchitsmailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD1BENdRaO3lCd98MRAnQ+AKDP9x2HlKQAsj3xZc9JZKltJSZ9VwCeKDCF seml/TMLEIKJFcbAPNP2yu0= =7q35 -END PGP SIGNATURE- ___ 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
On Mon, 2006-01-23 at 01:53, david turner wrote: Perhaps we shall *rename* the library to, say, `libft2', instead of `libfreetype', Um this will break everybody's builds and will mean we can't have something that builds with either 1.10 or 2.0 without fancy configure scripting. I'm not sure what it gains you that changing the so number doesn't... together with a new API prefix `FT2_' instead of `FT_'. This would avoid the whole mess. Please don't change the API. It makes some sense to change internal names, I suppose. I'd prefer you didn't (since fontforge is a rogue), but don't change the external ones. Another option is to have ./configure refuse to install freetype 2.2.0 if a previous release of the library is detected on the system; that is, unless you use a super-duper parameter like --please-destroy-my-desktop that only the cautious will care to use. That seems like a good starting point to me. ___ 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
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. Or even `libft3' and `FT3_' ... Werner ___ 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
Indirect dependencies. That's exactly what's described in this section: http://plan99.net/autopackage/Linux_Problems#elf Yes. Note that the world is still spinning inspite of the horror scenario painted there :-) I can't think of many programs which actively use FreeType functions on their own. Any program which needs more info than delivered by FontConfig needs it, especially applications which create PS or PDF output by itself. Examples are xpdf or lilypond (a music typesetter). 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. Mhmm, let's see what David says. Werner ___ 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
[discussion continued on freetype-devel only] A new version which makes such a radical change should bump up the shared object version (.so.N). Where's the `radical change'? 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. David, what about adding some words to freetype-2.2.0.html? Since you apparently still don't have access to freetype.freedesktop.org please send me a patch which I can apply. Werner ___ 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
