Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <39531B26.6D53DD60@ece.gatech.edu>
Date: Fri, 23 Jun 2000 04:09:10 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: cygwin-apps AT sourceware DOT cygnus DOT com, cosmin AT cs DOT toronto DOT edu, pcg AT goof DOT com
Subject: Re: test versions of zlib-1.1.3-2 and libpng-1.0.7rc1-1
References: <394D1C1A DOT 4F1B80B8 AT ece DOT gatech DOT edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks to some more advice from Marc Lehmann I was able to make a little
more progress on getting the asm stuff for libpng (pnggccrd.c) to work
with gcc-2.95.2. It still doesn't work, but it's getting closer. I had
to add more dummy arguments for all the asm inputs that were changed,
not just the ones that gcc complained about. Also, I had to make the asm
statements volatile.

However, that led to the following problem, which is where I'm stuck
again. gcc now complains that a few of the asm routines are using more
than 10 arguments, which they are not since I'm referring to the dummy
args by number -- this should NOT use up an 'argument slot' but it is.

In any case, I've uploaded an updated pngccrd.diff to sourceware. You
can get it at
ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/pnggccrd.diff2.gz 

Does anyone have any ideas?

--Chuck


"Charles S. Wilson" wrote:
> 
> are available at
> ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/
>    zlib-1.1.3-2-src.tar.gz
>    zlib-1.1.3-2.tar.gz
> 
>    libpng-1.0.7rc1-1-src.tar.gz
>    libpng-1.0.7rc1-1.tar.gz
> 
>    pnggccrd.diff.gz (additional [non-functional] patch for asm stuff)
> 
> I've made a few cleanups and packaging changes to zlib and libpng (as
> well as the obvious update to 1.0.7rc1 from 1.0.6c) I've also made those
> two packages conform to the new cygwin 'standards' as it were:
> 
> o import-lib libfoo.dll.a  (not libfoo.a-dll)
> o static-lib libfoo.a      (not libfoo.a-static)
> o no funny symlink games
> o cygwin-specific docs in /usr/doc/Cygwin/<package>-<version>.README
> o generic docs in /usr/doc/<package>-<version>/*
> o source archive has already had the cygwin specific patch applied
> 
> o cygwin specific README and patch are stored in the source archive,
> under <top>/CYGWIN-PATCHES/* (although the patch has already been
> applied to the archive itself).
> 
> o define -DZLIB_STATIC (and -DPNG_STATIC) to get the 'correct' #define's
> when compiling a .o that will be linked statically -- as well as using
> '-static' during the link step.
> 
> o no special -D options needed (or link options) to link with the dll.
> 
> These packages (libpng especially) are not yet ready for primetime. I'd
> like feedback on several issues:
> 
> 1) test reports (does it work for you? is building from the source
> tarball painless?)
> 
> 2) package structure (What do you think about CYGWIN-PATCHES?
> Pre-applied patches in the source archives?).
> 
> 3) help (additional patches?) in getting the dll (no asm) to pass the
> pngtest tests.
> 
> 4) help (additional patches?) in getting both static lib and dll *with*
> pnggccrd.c to compile and pass the pngtest tests. I have already
> developed a patch -- thanks to Marc Lehmann -- that allows pnggccrd.c to
> compile, but the resulting library fails pngtest in both static and dll
> versions. That patch is available as
> ftp://sourceware.cygnus.com/pub/cygwin/private/cygwin-extras-392/pnggccrd.diff.gz
> 
> The official libpng-1.0.7 should be coming out in about two weeks, and
> I'd like to be in sync and ready to go for that.
> 
> I've also realized that there are a few problems with even the
> non-assember libpng dll. The pngtest linked with that dll fails some of
> the tests. I'm not sure why, but am trying to track it down (help and
> patches are always appreciated). It may be related to the recent change
> in the cygwin-gcc specs file, which no longer defines WIN32 and friends.
> Some of the #ifdefs in libpng may have depended on that...and need to be
> fixed.
> 
> --Chuck