Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Dec 2001 11:06:55 +0200
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Mikhail Teterin <mi@aldan.algebra.com>
Cc:        ports@FreeBSD.org, cvs-committers@FreeBSD.org
Subject:   Re: cvs commit: ports/print/ghostscript-afpl Makefile distinfo      pkg-plist ports/print/ghostscript-afpl/files escputil.contrib.mak        hpijs.contrib.mak patch-hpijs:makefile patch-hpijs:platform.h          patch-src:unix-gcc.mak stp.contrib.mak  ports/print/ghostscript-afpl/scripts ...
Message-ID:  <3C2C362F.7A151056@FreeBSD.org>
References:  <200112280837.fBS8bVf26137@aldan.algebra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote:
> 
> On 27 Dec, Maxim Sobolev wrote:
> > On Thu, 2001-12-27 at 21:59, Mikhail Teterin wrote:
> >> On 27 Dec, Mario Sergio Fujikawa Ferreira wrote:
> >>
> >> >   - Better support for jpeg WRKDIR location
> >>
> >> According to the Ghostscript's Make.htm, the only reason GS needs its
> >> own  version  of JPEG,  is  because  Adobe's PostScript  interpreters
> >> "don't follow JPEG  standard exactly". Which forces  GS developers to
> >> build JPEG with the following:
> >>
> >>      #define D_MAX_BLOCKS_IN_MCU 64
> >>
> >> perhaps, this is how we should build  our JPEG port to start with and
> >> make gs use -ljpeg, like everything else?
> >
> > What's the gain?
> 
> Generally, it is  considered advantageous to share  the common libraries
> between  different executables.  Smaller  run-time memory  requirements,
> smaller on-disk binary size, easier maintainance, etc.

I would say "no" if it means that the resulting library would read, or
even worse produce, non-conformant jpeg images, especially considering
that the code bloat is only around 100k.

-Maxim

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C2C362F.7A151056>