Hi all, I''ve tried to port the latest unstable release (v2.3.93) to OS/2, with 99% success. However, I see that it''s not a very recent release, so I''d like to offer patches after a next release, for that one. So, my first question is if I can expect a new unstable (or maybe stable) release in the near future, anytime soon? Then some general stuffs I met while I was porting: The code uses fopen() at some places, and uses open() at some other. Shouldn''t this be unified? Anyway, the open flag O_BINARY is missing from the open() of the cache file handling routines, which caused problems with the font-cache on OS/2 GCC (where the default is text file). There are memory mapped files used. It''s not yet supported in the OS/2 version of libc, so I''ve made a kind of emulation of them in a separate file. Right now I include its header file conditionally with #ifdef __OS2__. Should it be left this way, or is it better to have a config.h define for this, like for example #define FC_USE_MMAP_EMU ? I think that''s all for now. Thanks in advance! Doodle
Doodle wrote:> > Hi all, > > I''ve tried to port the latest unstable release (v2.3.93) to OS/2, with > 99% success. However, I see that it''s not a very recent release, so I''d > like to offer patches after a next release, for that one. So, my first > question is if I can expect a new unstable (or maybe stable) release in > the near future, anytime soon?Unfortunately, fontconfig isn''t quite stable enough for a stable release yet. However, once things settle down a bit I''m hoping to make another unstable release. In the meantime, there are significant changes between 2.3.93 and current CVS; you might want to use the CVS version.> Then some general stuffs I met while I was porting: > > The code uses fopen() at some places, and uses open() at some other. > Shouldn''t this be unified? Anyway, the open flag O_BINARY is missing > from the open() of the cache file handling routines, which caused > problems with the font-cache on OS/2 GCC (where the default is text file).Current CVS doesn''t use fopen in the core library, only open. fopen is used in some of the utilities (e.g. doc/edit-sgml.c, fc-case/fc-case.c, fc-glyphname/fc-glyphname.c, fc-lang/fc-lang.c). That should be harmless. I''ll add O_BINARY flags shortly.> There are memory mapped files used. It''s not yet supported in the OS/2 > version of libc, so I''ve made a kind of emulation of them in a separate > file. Right now I include its header file conditionally with #ifdef > __OS2__. Should it be left this way, or is it better to have a config.h > define for this, like for example #define FC_USE_MMAP_EMU ?There''s also a problem with Windows, which has a slightly different mmap semantics. It might be better to have general mmap emulation (which is, I guess, no worse than 2.3) for platforms where mmap doesn''t work yet. pat
Doodle wrote:> The code uses fopen() at some places, and uses open() at some other. > Shouldn''t this be unified? Anyway, the open flag O_BINARY is missing > from the open() of the cache file handling routines, which caused > problems with the font-cache on OS/2 GCC (where the default is text file).Um, O_BINARY doesn''t exist for me under Linux. I better not commit that. Someone (not me) is going to have to be a bit more clever than that. rsync defines its own O_BINARY to 0 if the platform doesn''t provide it. You might want to start with the binary.patch I''ve attached. pat -------------- next part -------------- A non-text attachment was scrubbed... Name: binary.patch Type: text/x-patch Size: 3368 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20060209/f35a87b3/binary.bin
On Thu, 2006-02-09 at 10:53 -0500, Patrick Lam wrote:> Doodle wrote: > > The code uses fopen() at some places, and uses open() at some other. > > Shouldn''t this be unified? Anyway, the open flag O_BINARY is missing > > from the open() of the cache file handling routines, which caused > > problems with the font-cache on OS/2 GCC (where the default is text file). > > Um, O_BINARY doesn''t exist for me under Linux. I better not commit > that. Someone (not me) is going to have to be a bit more clever than > that. rsync defines its own O_BINARY to 0 if the platform doesn''t > provide it. You might want to start with the binary.patch I''ve attached.The GLib mmap wrapper just does #ifndef _O_BINARY #define _O_BINARY 0 #endif Matthias
Matthias Clasen wrote:> On Thu, 2006-02-09 at 10:53 -0500, Patrick Lam wrote: > >>Doodle wrote: >> >>>The code uses fopen() at some places, and uses open() at some other. >>>Shouldn''t this be unified? Anyway, the open flag O_BINARY is missing >>>from the open() of the cache file handling routines, which caused >>>problems with the font-cache on OS/2 GCC (where the default is text file). >> >>Um, O_BINARY doesn''t exist for me under Linux. I better not commit >>that. Someone (not me) is going to have to be a bit more clever than >>that. rsync defines its own O_BINARY to 0 if the platform doesn''t >>provide it. You might want to start with the binary.patch I''ve attached. > > > The GLib mmap wrapper just does > > > #ifndef _O_BINARY > #define _O_BINARY 0 > #endifThis doesn''t quite get us any further ahead; I''d imagine that some config-fu would be involved in doing the right thing on a variety of platforms. pat
Patrick Lam wrote:>>The GLib mmap wrapper just does >> >> >>#ifndef _O_BINARY >>#define _O_BINARY 0 >>#endif > > > This doesn''t quite get us any further ahead; I''d imagine that some > config-fu would be involved in doing the right thing on a variety of > platforms. >Ops, I thought that O_BINARY is a common, standard thing, but now I see that it''s only for CRLF''d platforms. After a quick research, it seems to me that the value of O_BINARY is platform specific (and even compiler specific), and in my case (InnoTek GCC on OS/2) it''s defined to be 0x00020000. However it should be simply skipped for platforms where there is no such thing as text and binary file, so why not define it to be 0 in cases where it''s not defined? Doodle
Doodle wrote:> Patrick Lam wrote: > >>> The GLib mmap wrapper just does >>> >>> #ifndef _O_BINARY >>> #define _O_BINARY 0 >>> #endif >> >> This doesn''t quite get us any further ahead; I''d imagine that some >> config-fu would be involved in doing the right thing on a variety of >> platforms. > > Ops, I thought that O_BINARY is a common, standard thing, but now I see > that it''s only for CRLF''d platforms. > > After a quick research, it seems to me that the value of O_BINARY is > platform specific (and even compiler specific), and in my case (InnoTek > GCC on OS/2) it''s defined to be 0x00020000. However it should be simply > skipped for platforms where there is no such thing as text and binary > file, so why not define it to be 0 in cases where it''s not defined?I thought so too, and then I tried to compile with O_BINARY. Nope! I missed ''ifndef'' in the above; I guess it works. pat
Doodle wrote:> After a quick research, it seems to me that the value of O_BINARY is > platform specific (and even compiler specific), and in my case (InnoTek > GCC on OS/2) it''s defined to be 0x00020000. However it should be simply > skipped for platforms where there is no such thing as text and binary > file, so why not define it to be 0 in cases where it''s not defined?Ok, I''ve committed O_BINARY and the #ifndef. pat