Hi Roberto,

> I found another approach for the compilation of resources.
> Instead of generating a C file containing files as hex dumps, I generate an 
> assembly file with a .incbin directive.
> As a result, the compilation of the fonts doesn't need this huge amount of 
> resources anymore.
> 
> I only have i386 to play with, so I don't know if generated assembly is 
> portable. At least it works under OpenBSD and mingw on i386.

sorry, it's not portable; builds on amd64 and sparc64, but fails
on arm. I don't fancy powering my hppa right now but I have a feeling
it won't be happy there either..

on arm, this is how it looks:

as  -Ifonts -Ifitz -Imupdf -Iapps -o 
/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.o 
/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.s

/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.s: Assembler messages:
/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.s:2: Error: alignment too 
large: 15 assumed
/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.s:13: Error: alignment 
too large: 15 assumed
/usr/obj/ports/mupdf-0.0.20090616/build-arm/font_misc.s:24: Error: alignment 
too large: 15 assumed
...skipped libfonts.a for lack of libfonts.a(font_misc.o)...

(continues to skip others for lack of libfonts.a, etc).

> > builds on sparc64 and arm, but mine are headless and mupdf
> > tries to do SHM so I can't test them.
> 
> couldn't you use a remote display ?

it fails with mupdf, with either SSH-forwarding or direct remote X.

ximage: mode 24/32 00ff0000 0000ff00 000000ff (16,8,0) lsb <swap>
ximage: ARGB8888 to BGRA8888
X Error of failed request:  BadAccess (attempt to access private resource 
denied)
  Major opcode of failed request:  144 (MIT-SHM)
  Minor opcode of failed request:  1 (X_ShmAttach)
  Serial number of failed request:  11
  Current serial number in output stream:  12

I also managed to find a file which triggers an assertion if you're
interested..(including with current code)

assertion "dec->numcomps == 3" failed: file "jpc_dec.c", line 1077, function 
"jpc_dec_tiledecode"

I'm not entirely sure if the file is meant to be public or not but can
send it offlist to interested parties.

> also, concerning this port, I suggest to delete the _darcs/ folder
> from the rolled tarball ( 15.2M !!! ), and to remove fontdump and
> cmapdump from PLIST as they only are needed during the build process.

excellent idea, thanks!

Reply via email to