Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3C728E72.7090701@ece.gatech.edu> Date: Tue, 19 Feb 2002 12:42:10 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Dario Alcocer CC: cygwin-apps AT cygwin DOT com, Greg Bond Subject: Re: Ghostscript ready to upload References: <15474 DOT 24004 DOT 831754 DOT 756103 AT coyote DOT priv DOT helixdigital DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dario Alcocer wrote: > Chris, > > I've *finally* finished testing and packaging Ghostscript. I've put > the packages and MD5 files at: > > http://members.cox.net/dalcocer/gs > > As soon as I hear back from you that the package has been uploaded, > I'll send out the announcement. Thanks, and sorry about taking so > long to get this release out. Okay, I've uploaded it -- but I am curious about one thing: ---------- Previous releases required shared libraries for zlib, libpng, and jpeg. However, due to the very specific requirements Ghostscript has regarding these libraries, these libraries are instead statically linked. As a result, Ghostscript no longer requires the use of shared libraries. The libraries are included in the source package, ready to be built with Ghostscript. ---------- What specifically is wrong with the existing shared libraries? I do *not* want to see a trend start where other packages start shipping the source to the libraries they depend on. Linking statically is okay -- e.g. linking against the libtiff.a file in tiff-3.5.7-1 package by using "gcc -static .... -ltiff", for instance -- but duplicating my work is a bit, ah, insulting. If you can't build ghostscript against the shipped libraries, then either the libraries or ghostscript is broken and need to be fixed. What *specifically* is wrong with cygtiff.dll, cygz.dll, or cygpng2.dll? --Chuck