Ghostscript-9.00

[ken@…]

New version. ​http://sourceforge.net/projects/ghostscript/files/GPL Ghostscript/9.00/ghostscript-9.00.tar.gz/download

[Randy McMurchy]

Updated milestone to 6.7

[Randy McMurchy]

Simply removing the zlib directory from the source tree will force the build to pick the local copy. Best I can tell, Jasper is the same way, not sure we need the patch. I don't have Jasper installed yet, I'm just going on examination of the configure script.

I'm going to figure out a way to use system installed versions of expat, ijs, lcms, and jbig2. More to follow.

[ken@…]

System jasper *does* need a patch - I installed jasper in /usr/local on my other box, and watched the gs build blow up in my face. I have a patch originally from fedora, not yet tested.

I'm interested in using system libs - debian apparently do that, but I haven't yet checked their details.

Debian *do* apply a one-liner to use vsnprintf instead of vsprintf in base/gsmisc.c [ claimed to be CVE-2009-4270 ]. Gentoo use a much larger patch, from fedora. I've now managed to get connected to fedora gitweb [ generally, that site is overloaded ] and it is described as "to harden the debugging output functions" which makes it sound good but not essential. I'll need to check mitre.

For jbig2, won't most of our users *not* have a system version ? Fedora have another patch to fix a null pointer dereference in the internal jbig2 code.

For ijs, I thought the only source was from a version of ghostscript ?

I'm also of the opinion it should now be called merely 'ghostscript' instead of 'GPL ghostscript' in the book.

[ken@…]

Replying to ken@…:

For ijs, I thought the only source was from a version of ghostscript ?

Never mind, I hadn't noticed it as an optional dep.

[Randy McMurchy]

Yes, I realized it quickly that jasper needs the patch. Jbig2 I'm working on. IJS can be made into a shared library that gutenprint uses. I've used ​http://www.openprinting.org/download/ijs/download/ in the past.

I'm not sure that the expat is even pulled in, even from the internal copy. I need to check more. I would really like to use the system freetype, but haven't tried anything there yet. LCMS I've not looked into yet either.

And actually, unless we do something, IJS should not be an optional dependency.

[Randy McMurchy]

As far as the name, we could use either. Go to ​http://ghostscript.com/ and reference the sourceforge link where the files are called GPL Ghostscript. I like just plain Ghostscript myself.

[Randy McMurchy]

To use system FreeType, delete the freetype directory and after configure is done, use a sed to change SHARE_FT in the top level Makefile from a 0 to a 1. I don't know why that is not done automatically as it is for all others.

To use system Zlib, change SHARE_ZLIB from 0 to 1 in the same Makefile, BUT DO NOT DELETE the zlib DIRECTORY. Files must be pulled from there, but the zlib library used will the system one.

More to follow.

[Randy McMurchy]

What might be even better for Zlib is to remove the zlib directory and replace it with a copy that was used in the LFS build. That way the pulled files will be from the same version of Zlib.

[ken@…]

FWIW, debian unpackage the internal expat, freetype, icclib, ijs, jasper, jbig2dec, lcms, libpng, tiff, zlib. i.e. they don't include those in their dfsg source.version. They then use the following, apparently passed to make on the command line

SHARE_FT=1 SHARE_JPEG=1 SHARE_LIBPNG=1 SHARE_LIBTIFF=1 SHARE_ZLIB=1 SHARE_JBIG2=1 SHARE_JPX=1 SHARE_LCMS=1 SHARE_EXPAT=1 LCMSSRCDIR=/usr

Clearly, with removing the directories the SHARE_JPEG and SHARE_PNG, and presumably SHARE_JPX, are redundant.

I've think I've got through lcms (LCMSSRCDIR seems to be needed to find the headers), but it's very much one step forward and then one back, at the moment my installed random version of freetype is causing the build to fail because one or more definitions have changed. Maybe I did something wrong there, it's definitely pulling in the freetype system headers.

I understand your thinking on zlib, but I'm not sure if all the readers will remember (or even know, if they are using another distro, as people used to - try BLFS before jumping in to LFS) which version of zlib they installed.

I'm going back to try to "build with one system lib at a time" (for lcms, expat, freetype), to confirm instructions for some or all of these.

After all of this, there will be the 'make cups' and 'sed to fix the build if gtk+2 is not installed' issues.

[ken@…]

The lcms part is sorted, and along the way I've learned that 'make cups' is a dependency of 'make so', therefore the distros that do it as a separate step are being unnecessary. More importantly, both 'make so' and 'make soinstall' (and probably 'make install') ALL need the overrides. So, once the correct magic words have been established, a sed after running configure looks a better way to go.

[Randy McMurchy]

So far I have the following packages being used from the system:

libpng libjpeg libtiff jasper freetype jbig2dec

And it results in a clean build. Going to work on LCMS next. Man, this is tedious.

[Randy McMurchy]

Replying to randy@…:

So far I have the following packages being used from the system:

libpng libjpeg libtiff jasper freetype jbig2dec

Also zlib, but that directory not removed from the tree. All the others I removed from the tree to ensure there is no pulling from those dirs.

[bdubbs@…]

Replying to randy@…:

Also zlib, but that directory not removed from the tree.

Is it using more than just zlib.h?

[Randy McMurchy]

Replying to bdubbs@…:

Is it using more than just zlib.h?

I'm not sure yet how many files from the zlib package. I know for sure it wants compress.c

I'll be testing that when I'm done with lcms.

[Randy McMurchy]

Looks to me as though we can just delete the lcms directory, then create a lcms/include directory and populate it with two header files (lcms.h, icc34.h). It would be a small patch. Worked great for me.

When there is an update to LCMS (which there already is, but is considered a *major update* and I don't want to use it until the next round of updates to BLFS) we just make a new patch for Ghostscript. A <!-- note --> in the lcms .xml would remind an editor to do it.

[Randy McMurchy]

So far this is being pulled in from the system (fontconfig and expat pulled in from one of the others).

        linux-gate.so.1 =>  (0xb788e000)
        libjasper.so.1 => /usr/lib/libjasper.so.1 (0xb7837000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb77d3000)
        libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xb779e000)
        liblcms.so.1 => /usr/lib/liblcms.so.1 (0xb776c000)
        libcupsimage.so.2 => /usr/lib/libcupsimage.so.2 (0xb7759000)
        libcups.so.2 => /usr/lib/libcups.so.2 (0xb771c000)
        libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb76cc000)
        libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb755a000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7540000)
        libm.so.6 => /lib/libm.so.6 (0xb751a000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb74e8000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb74c1000)
        libz.so.1 => /lib/libz.so.1 (0xb74ab000)
        libjbig2dec.so.0 => /usr/lib/libjbig2dec.so.0 (0xb7499000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7495000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0xb7464000)
        libpaper.so.1 => /usr/lib/libpaper.so.1 (0xb7461000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7432000)
        libc.so.6 => /lib/libc.so.6 (0xb72bd000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7247000)
        /lib/ld-linux.so.2 (0xb788f000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb721f000)

Going to work on Zlib next.

[ken@…]

Replying to randy@…:

Looks to me as though we can just delete the lcms directory, then create a lcms/include directory and populate it with two header files (lcms.h, icc34.h). It would be a small patch. Worked great for me.

When there is an update to LCMS (which there already is, but is considered a *major update* and I don't want to use it until the next round of updates to BLFS) we just make a new patch for Ghostscript. A <!-- note --> in the lcms .xml would remind an editor to do it.

lcms works for me as I already noted earlier - just delete it, then set the overrides.

[Randy McMurchy]

Replying to ken@…:

lcms works for me as I already noted earlier - just delete it, then set the overrides.

Then we have a conflict here. It bombed on me until I created a lcms/include dir and put the two .h files in there. This needs to be revisited. However, I'm fairly confident. It isn't very hard to see when a build fails, and why.

Are you sure you deleted the lcms source tree, Ken?

[ken@…]

Replying to randy@…:

When there is an update to LCMS (which there already is, but is considered a *major update* and I don't want to use it until the next round of updates to BLFS) we just make a new patch for Ghostscript. A <!-- note --> in the lcms .xml would remind an editor to do it.

Forgot to comment on this part just now - lcms2 is so different from lcms1 that it wasn't usable by anything that uses lcms1 when I tried to use it about two months ago. In any case, setting the overrides (by sedding the Makefile) is much more straightforward. At least until some packages want lcms1 and others want lcms2.

[Randy McMurchy]

Update: Not sure where you stand Ken, but I have this so far:

1) Remove the following directories: jasper jpeg tiff libpng freetype jbig2dec lcms zlib

2) Apply the Jasper patch

3) Run configure:

./configure --prefix=/usr \
            --without-omni \
            --with-system-libtiff \
            --enable-dynamic

4) Run this sed:

sed -i -e 's|SHARE_FT=0|SHARE_FT=1|'           \
       -e 's|SHARE_LCMS=0|SHARE_LCMS=1|'       \
       -e 's|ZSRCDIR=src|ZSRCDIR=zlib|'        \
       -e 's|LCMSSRCDIR=lcms|LCMSSRCDIR=/usr|' \
    Makefile

5) Copy these files from a zlib-1.2.5 source tree into a directory "zlib": adler32.c compress.c crc32.c crc32.h deflate.c deflate.h trees.c trees.h zutil.c zutil.h

I made a patch that does #5.

6) Run make

That leaves expat, ijs, icc (​http://www.argyllcms.com/index.html) that can be built into shared libs (expat already is). I wonder; however, how much modification the Ghostscript devs do to the Jasper library? See: ​http://svn.ghostscript.com/

[Randy McMurchy]

For expat, I removed the directory and put SHARE_EXPAT=1 in the Makefile and it built (including 'make so' to create the shared ghostscript library). No telling if all these modifications will create ghostscript executables and libraries that actually work.

[Randy McMurchy]

For icclib and ijs, it looks like too much work for me. It is clearly stated in the gs.mak makefile that "Currently there is no option for sharing icclib or ijs". I suppose we could see what other distros are doing to use those libraries as shared system libs.

[ken@…]

Replying to ken@…:

After all of this, there will be the 'make cups' and 'sed to fix the build if gtk+2 is not installed' issues.

Already disposed of 'make cups', and now I find that the sed is NOT required - on a system without X, gsx apparently got (DESTDIR) installed by 'make soinstall', but is only linked to libgs, libc, ld-linux, and the kernel vdso. This is enough to give a prompt, and running it on a ps file reports the fonts and some BoundingBox data but is clearly unable to display the output. So, it sort of works (not a lot better than executing 'gs') and I can't see any reason to prevent it getting installed.

[Randy McMurchy]

I ran into the same problem, no X11 driver installed. So I passed --with-drivers=all to configure and now it wants more files. Just a few zlib files, now I'm adding lcms files. This could get ugly. Without the X11 driver, gs might be worthless to some folks. More to follow.

[ken@…]

Hmm, I really hate trac for this, I'm almost ready to say "let's take this on list". But meanwhile, here's what I had ready to add when you updated the ticket under me:

Replying to randy@…:

Update: Not sure where you stand Ken, but I have this so far:

[snipped a bit]

./configure --prefix=/usr \
            --without-omni \
            --with-system-libtiff \
            --enable-dynamic

Without omni is now the default. Fedora have omni depending on libxml2, I see no reason to enable it.

4) Run this sed:

sed -i -e 's|SHARE_FT=0|SHARE_FT=1|'           \
       -e 's|SHARE_LCMS=0|SHARE_LCMS=1|'       \
       -e 's|ZSRCDIR=src|ZSRCDIR=zlib|'        \
       -e 's|LCMSSRCDIR=lcms|LCMSSRCDIR=/usr|' \
    Makefile

The seds are useful, but need to be separated. I also need to check how to add EXPAT to the seds. The reason for separating them is that only zlib is guaranteed to be in a current LFS build. Also, although a fresh BLFS build will (eventually) pick up current versions, we're still on freetype-2.3 and people often spend several weeks (and sometimes months) going through BLFS, so we can't guarantee that installed versions are new enough. We also need to document the included versions as the minimum system versions required (i.e. if your version is older, use the (patched - see below) version in here if you don't upgrade the system version.

5) Copy these files from a zlib-1.2.5 source tree into a directory "zlib": adler32.c compress.c crc32.c crc32.h deflate.c deflate.h trees.c trees.h zutil.c zutil.h

I made a patch that does #5.

That will be useful, but probably deserves a note for anyone using an older version of LFS. Or maybe 1.2.5 was itself a vulnerability fix ? Will need to check that.

[...]

That leaves expat, ijs, icc (​http://www.argyllcms.com/index.html) that can be built into shared libs (expat already is). I wonder; however, how much modification the Ghostscript devs do to the Jasper library? See: ​http://svn.ghostscript.com/

I haven't yet refreshed my memory about jasper (one of the things I advocated for the book which I've now dropped from my own builds as circumstances have changed). I think they're just updating their branch for known vulnerabilities, but I need to check.

If icc is from argyllcms, I think BLFS users are unlikely to build it at the moment, nor to have access to calibration hardware, so I'm not very fussed about it. I've seen developments in colour calibration, so that will no doubt change in the future.

As I noted yesterday, now that ghostscript is all reunited and developed at ghostscript.com, ijs is a part of it, it isn't separate. So, there is a lot more here than I expected (always the way in BLFS), and I've got a lot more to do before I'm certain. But for the moment my plan is: to fix any vulnerabilities or similar in both gs and the included libs, then build and use that version with system zlib. Probably not much more than a cups test page, a text page, and a photo, so by no means exhaustive. Then repeat with the system versions of (updated and fixed) freetype, expat, and lcms on one of my boxes. Don't hold your breathe!

I've also got at least one other thing within this to look at, and no doubt others will suggest themselves as I get further in. Except that gs-8.71 doesn't work for me, I would have relinquished this ticket, it's far too much pain ;-)

Since you're still working on this, I'll just add that the as-it-ships vulneable version is working fine for me - the issues are just fixing vulnerabilities, and not forcing our readers to have dependencies they don't need.

[Randy McMurchy]

It gets worse. Removing the Jasper directory works great if you don't pass --with-drivers=all. However, that doesn't build an X11 driver. When you pass that flag, Jasper blows up and I'm not sure what to do at this point. Probably going to take the rest of the night off (it's 5:15pm my time).

Thanks for working with me on this Ken.

[ken@…]

Our printing stacks are obviously very different, I don't need --with-drivers=all. My printer is an epson inkjet, connected to one or other of my desktop boxes, and the printer stack is cups, gtk, ghostscript, gs fonts, gutenprint [ for the driver ]. I build gs with the same options as the book, --with-system-libtiff and --enable-dynamic, and with make so and make soinstall.

I don't remember if the gs configure options have changed since I last used system jasper, all I remember is that I now build cups before gtk+ to get the queues working. I guess I can add a temporary rebuild using jasper (rebuilds are a pain, I have to delete all the cups files then rebuild cups, gs, and gutenprint, then redefine the printer in cups : if I don't do that but change e.g. gutenprint I can end up with gs failures because the versions change).

[Randy McMurchy]

Well, I'm done here Ken. My whole deal was why wasn't an x11 driver being built? Apparently it is not in the default ALL set of drivers any longer. It used to be. So I simply added it and then it built fine. You do whatever you feel is right; however, I'm going with this for my build (we will need to have individual explanations for each optional package, i.e., break out the sed and removal of directories):

1. Remove the zlib directory.

2. Remove any or all of the following directories (jasper jpeg tiff libpng freetype jbig2dec lcms expat)

3. Apply the Jasper patch if that directory was removed.

4. Run configure

   ./configure --prefix=/usr \
               --with-system-libtiff \
               --enable-dynamic \
               --with-drivers=ALL,x11
   

Note that --with-drivers=ALL is the default. I only use it to add the x11 driver. Also the --with-system-libtiff line is optional.

5. Apply ghostscript-9.00-system_zlib-1.patch (in the LFS repo)

6. Run any or all of the following seds (The zlib sed is mandatory, the rest broken out with individual explanations)

   sed -i -e 's|SHARE_FT=0|SHARE_FT=1|'                                  \
          -e 's|SHARE_LCMS=0|SHARE_LCMS=1|'                              \
          -e 's|ZSRCDIR=src|ZSRCDIR=zlib|'                               \
          -e 's|LCMSSRCDIR=lcms|LCMSSRCDIR=/usr|'                        \
          -e 's|=imdi|&\n\n# Use system expat library\n\nSHARE_EXPAT=1|' \
       Makefile
   

7. Run make and the rest of the instructions.

Works for me. I'm moving on. Thanks for working with me on this.

[Randy McMurchy]

Replying to randy@…:

It gets worse. Removing the Jasper directory works great if you don't pass --with-drivers=all. However, that doesn't build an X11 driver. When you pass that flag, Jasper blows up and I'm not sure what to do at this point. Probably going to take the rest of the night off (it's 5:15pm my time).

Totally disregard the comment above. I mistakenly had used --with-drivers=all, instead of --with-drivers=ALL (note caps). It all builds well now using all the system installed libs. Tested by displaying the tiger on an X window. Will now install gutenprint and check out printing.

[Randy McMurchy]

Replying to ken@…:

I'm also of the opinion it should now be called merely 'ghostscript' instead of 'GPL ghostscript' in the book.

Just FYI, but when you run the gs executable, here is what is sent to stdout:

GPL Ghostscript 9.00 (2010-09-14) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details.

[ken@…]

So, it stays as GPL Ghostscript. Thanks for that pointer.

Vulnerability updates re the4 included libs:

lcms - contains 1.18, for which CVE-2009-0793 was raised. The fix fedora (and maybe others) used for that is already in what gs ships.

[ken@…]

Oh wow, the freetype part of this is going *really* badly. I've managed to patch the included freetype-2.4.1 up to 2.4.3 plus fixes for the current vulnerabilities. Checked freetype itself builds (and spent a whole day discovering I needed the changes to configure and unix/configure to get the correct version for libfreetype.so (and in freetype-config), then slimmed that patch down (just source and headers, not docs nor windows files) to about 77k or 2000 lines. Then I tried to build gs with internal patched freetype - it dies in the linkage with undefined FT symbols (similarly, if I just drop the whole of freetype-2.4.3 in as 'freetype' instead), even though freetype itself seems to build. I'm starting to doubt my results.

Living dangerously, I haven't yet updated my system freetype (I had thought I could patch 2.3.x but it turns out that 2.4.2 fixed a load more vulnerabilities). I think I'll sleep on this and maybe retry the permutations of freetype-2.4.3 and the patch as standalone builds and building within gs9. I'm now wondering if the system freetype will actually work with gs9, but also hoping I did something wrong today.

[Randy McMurchy]

Apparently, I've just been wasting my time adding comments to this ticket trying to help. Oh well. Just some typed letters.

Keep banging your head against the wall. Enjoy the headache.

GS9 is working great for me using the system installed Freetype-2.4.3.

[Randy McMurchy]

Reviewing my last remark, I realize that it did not come out as intended. Ken, my apologies for sounding rude (if you take it that way, which you easily could). I should have said something along the lines of "Ken, system Freetype-2.4.3 is working great for me using the instructions I posted earlier. I think it is easier to just make system Freetype a required dependency run the sed and be done with it. But it is up to you."

Anyway, mostly I wanted to say that my last remark did not come out as I intended it to.

[ken@…]

Replying to randy@…:

Anyway, mostly I wanted to say that my last remark did not come out as I intended it to.

Nae worries. On my linux systems, I'm from the "every package needs to justify its inclusion" tendency, so patching the shipped versions is attractive to me. In this case, I'll have to go with either 'recommended' or 'required' (until a newer ghostscript appears).

Meanwhile, I'm mostly away from my machines at the moment, more-urgent things to do.

[ken@…]

These packages that include copies of other things are hard. I'm increasingly forming the view that where ghostscript includes a library that is a copy of one from elsewhere, we ought to *recommend* the system version so that people have a chance of fixing vulnerabilities.

So, libpng, jpeg, lcms1, expat, freetype, zlib, tiff and even jasper should be recommended. The internal copy of lcms1 appears to have been patched up to date, but who knows what the future will hold. The internal tiff (3.9.2) has *some* patches, but I can't confirm if all the known vulnerabilities have been fixed (some were only reported against opensuse/novell and I can't find how they fixed them).

This adds a shedload of dependencies, but since we are specifically building the x11 driver I suppose they aren't excessive.

[ken@…]

r8741

[bdubbs@…]

Milestone 6.7 deleted