[gs-bugs] [Bug 692240] gs9.* gets "Error: /invalidfont in definefont", OK in gs 8.7*

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=692240

--- Comment #8 from William Bader <williambader at hotmail.com> 2011-05-30 19:42:03 UTC ---
>With the Intel compiler on the same system it took > 1.5 hours

I was curious if it was just me.

>using a gcc that is NOT C++ may help

On all of the systems, I used gcc-4.6.0 built from source, and I build only the
C language.  (Since the g++ ABI changes so frequently, even if I built the C++
language, it would be a pain to use because I would have to rebuild most of the
C++ development libraries that came with the Linux distribution.)

>We will take a look at changes from users to emit (as an option) romfs structures as ASM or OBJ on problematic systems

For gsromfs1.c, I was wondering about keeping it in C but breaking up each
section into a file, which should be portable and would not require asm or obj.

I think that the pcfb module used to have some in-line assembly, so there is a
precedent for assembly, but I agree that asm could be hard to maintain.

In any case, gcc did eventually complete and generated working gs.
The slow compile is just a build server in a back room, and I build gs only for
new releases, so as long as I know that will eventually finish, it good enough.

>It's not like we are violating common (modern) compiler rules or restrictions.

I think that the ISO standard recommends minimum values for some compiler
limits, but the values are small enough that conforming compilers can be hosted
on 16 bit systems.  gsromfs1.c ends up to be almost 1/4 million lines, which
might be the largest module that I have tried to compile.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.