Re: [ft-devel] No support for side-by-side installation of x86-64 and i386
Hi On Tue, 06 Dec 2005 19:02:52 +0200 Ilya Konstantinov [EMAIL PROTECTED] wrote: Currently, freetype i386 and x86-64 collide in the following files: /usr/bin/freetype-config /usr/include/freetype2/freetype/config/ftconfig.h I see. 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. I see. Let me clarify the condition: the issue you reported is specific to GNU/Linux on x86-64, ppc64 and s390x. Grepping configuration files of X11R6.8.2, I found that only GNU/Linux on these processors use special separation of libraries by lib lib64 (no separation for binary executables, header files). Such co-existence of multiple binary formats might be useful on mips64, sparc64 and sh64 either, but I could not find such library separation for these processors. Oops, yet I've not checked the situation of MacOS using ppc32 and ppc64. Do you know Linux's policy to use, or not-to-use lib/lib64 library separation? It's important to determine the suitable directory to install. For the first step, configure script can be used to find the system uses lib/lib64 library separation, but it's insufficient to support cross-building completely. 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) Umm, moving to pkgconfig sounds easy solution. But I'm afraid about the systems using freetype-config without pkgconfig. How pkgconfig separates lib/lib64? 2. ftconfig.h would be moved to the lib(64)/config directory, just as it is for glib2 etc. Sounds reasonable, although I want to revise configure.ac and builds/unix/ftconfig.in to support both platforms (ah, I must learn more about Jam for multi binary formats). BTW, when the header files are different between i386 x86-64 (I call it as arch-dependent), GNU/Linux for x86-64 always separates arch- dependent files out of /usr/include? Such softwares are exceptional? Regards, mpsuzuki ___ 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 Tuesday, December 6th, 2005 17:02Z, Ilya Konstantinov wrote: 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. 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). In the case of freetype, it would mean having a dedicated directory for ftconfig.h et alii appropriate to each target, and of course different from /usr/include... BTW, this works great in general (and almost always did)! You are really seeking to have two separate freetype libraries (I assume in /usr/lib for x86-32 and /usr/lib64 for x86-64) available simultaneously _by default_, and perhaps select the correct ones according to flags such as -m32 and -m64 for gcc..., that is, _not_ really doing something as complex as setting up a complete cross-compiling environment. It would be very much desired that: 1. freetype-config would be recoded to detect its environment Can you please elaborate on what do you mean by your environment here? I am sorry if it seems ingenious. I am not currently running Linux, nor GLib; as such I am not sure what is the current official process of configuration of Freetype; if I am not a normal user of Freetype and as such my remarks are irrelevant, please say so, I won't be sad. Antoine ___ 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 and i386
Le mercredi 07 décembre 2005 à 18:42 +0900, [EMAIL PROTECTED] a écrit : Hi On Tue, 06 Dec 2005 19:02:52 +0200 Ilya Konstantinov [EMAIL PROTECTED] wrote: Currently, freetype i386 and x86-64 collide in the following files: /usr/bin/freetype-config /usr/include/freetype2/freetype/config/ftconfig.h I see. 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. I see. Let me clarify the condition: the issue you reported is specific to GNU/Linux on x86-64, ppc64 and s390x. Grepping configuration files of X11R6.8.2, I found that only GNU/Linux on these processors use special separation of libraries by lib lib64 (no separation for binary executables, header files). Such co-existence of multiple binary formats might be useful on mips64, sparc64 and sh64 either, but I could not find such library separation for these processors. Oops, yet I've not checked the situation of MacOS using ppc32 and ppc64. Do you know Linux's policy to use, or not-to-use lib/lib64 library separation? It's important to determine the suitable directory to install. For the first step, configure script can be used to find the system uses lib/lib64 library separation, but it's insufficient to support cross-building completely. There is currently no general policy, each distro are doing their own things : -Debian doesn't allow biarch (at least, yet) -RH and Mandriva supports biarch. For this specific problem, we (Mandriva) have some magic scripts which detect this issue when building packages and wraps those scripts and headers. When people want to build for x86 on x86-64, they just need to prepend linux32 script. More info available on : http://qa.mandriva.com/twiki/bin/view/Main/MultiArch 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) Umm, moving to pkgconfig sounds easy solution. But I'm afraid about the systems using freetype-config without pkgconfig. How pkgconfig separates lib/lib64? file go to /usr/lib/pkgconfig or /usr/lib64/pkgconfig. Arch independent files should go to /usr/share/pkgconfig (not really relevant for libraries). 2. ftconfig.h would be moved to the lib(64)/config directory, just as it is for glib2 etc. Sounds reasonable, although I want to revise configure.ac and builds/unix/ftconfig.in to support both platforms (ah, I must learn more about Jam for multi binary formats). BTW, when the header files are different between i386 x86-64 (I call it as arch-dependent), GNU/Linux for x86-64 always separates arch- dependent files out of /usr/include? Such softwares are exceptional? they are but they exists. Those headers should go to /usr/lib| lib64/program-major-version/includes (or something similar). For instance, glib arch dependent headers goes to : /usr/lib(64)/glib-2.0/include/ -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ 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
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 by GNU tools use completely separated directories: aslike /usr/i386-pc-linux-gnu and /usr/amd64-pc-linux-gnu, to avoid mixing files for target platform with files for host platform. GNU/Linux for x86-64 stores i386 libraries into /lib and x86-64 native libraries into /lib64. Without doubt, it's for runtime binary compatibilities with existing GNU/Linux for i386, 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. perhaps select the correct ones according to flags such as -m32 and -m64 for gcc..., that is, _not_ really doing something as complex as setting up a complete cross-compiling environment. I agree. It's a bit confusing to call such compiling as cross-compiling It would be very much desired that: 1. freetype-config would be recoded to detect its environment Can you please elaborate on what do you mean by your environment here? I am sorry if it seems ingenious. I am not currently running Linux, nor GLib; as such I am not sure what is the current official process of configuration of Freetype; if I am not a normal user of Freetype and as such my remarks are irrelevant, please say so, I won't be sad. I'm afraid there's no official process in this issue - there might be just how popular GNU/Linux distributors (wanna) do. Regards, mpsuzuki ___ 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 and i386
Hi, On Wed, 7 Dec 2005 14:15:52 +0100 (CET) On Wed, 7 Dec 2005, [EMAIL PROTECTED] wrote: I see. Let me clarify the condition: the issue you reported is specific to GNU/Linux on x86-64, ppc64 and s390x. Solaris 64-bit also has ABI-separated library directories: Great Thank you for helpful info. Let me ask more about the separations on Solaris: * Optional softwares use same separation rules? For example, there are something like /usr/X11R6/lib/64 ? * How about header files? The header files are separated completely? Or, the shareable headers are installed in /usr/include and other arch-dependent headers are separated in other directories? Or, system has only headers for most-suitable architechture? Regards, mpsuzuki P.S.: Hey, any guys on IRIX, AIX and HP-UX? ___ 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
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
How do you come to this conclusion? The original BDF specification (found in the X11 distribution) says that both FONT_ASCENT and FONT_DESCENT are *logical* values. They don't guarantee that all bitmap glyphs are within this range. Still, then we should set y_scale to 8 / (face-ascender + face-descender) in, for example, Set_Pixel_Sizes in ttdriver.c, shouldn't we? I'm not sure -- and too lazy to really think about it :-) Do you encounter problems with bitmap sizes? I found docs/CHANGES mentions this change and it says FT_Set_Pixel_Size is used to select actual font dimensions (the `strike'), not the nominal size. Maybe my question is what actual font dimensions mean? Well, if the font contains an 8x16 bitmap, the parameters are `8' and `16'. This is to get a unified interface to all bitmap formats, including Windows FNT. Note that the ppem values in WinFNT files are normally incorrect. BTW, your latest changes to the SFNT driver broke FNT files with multiple faces (this is, if they contain more than a single bitmap font). Reason is that the check for `face_index' in the SFNT driver is done before validation of the font format -- the driver incorrectly returns SFNT_Err_Bad_Argument instead of the correct SFNT_Err_Unknown_File_Format. I've fixed that now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
