Re: [hatari-devel] Compile error, zip.c

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 05 kesäkuu 2012, Uwe Seimet wrote:
> > Line 122 looks like this:
> > extern int ZEXPORT unzStringFileNameCompare OF ((const char* fileName1,
> > 
> >                                                  const char* fileName2,
> >                                                  int
> >                                                  iCaseSensitivity));
> > 
> > What happens if you comment it out?
> 
> Then it works, but other lines fail with the same problem.

Ok, then I think it's either of the defines I listed.


> > If you for some wierd reason have some Windows or BeOS defines
> > enabled in your build, ZEXPORT will probably be bogus.
> 
> Except for a newer zlib nothing on my machine changed that could
> influence the build, as far as I can tell. The update from zlib 1.2.5 to
> 1.2.5.1 may have caused this problem. If this is the reason I would
> expect the build to fail on other Linux machines as well, sooner or
> later.

My Debian stable has zlib1g-dev v1.2.3.4.

What you ZEXPORT and especially OF definitions look like?


> > You could also try installing LLVM and check what clang compiler
> > tells you.  It gives often better error messages than GCC.
> 
> I prefer to continue using gcc, it has worked fine for me for decades

I wasn't suggesting replacing gcc with clang, just that you use
clang to find out what the actual problem is as gcc's error
messages are sometimes useless gibberish.

Newer Clang versions can point out exact place of error even in
recursively expanded macros for which GCC gives completely misleading
error messages.


GCC still has edge in getting more speed out of the code and its warning
options finding more problems, but gap is closing.

Especially Clang's static analyzer produces really nice reports, it's
HTML with annotated sources pointing out the branches in the code leading
to the issue...  While e.g. Coverity finds (much) more errors and its
database backend allows you to mark issues as checked so that they
don't bug you on next run of the checker, the explanation of issues is
about as nice.

And to make sure code doesn't have problems, it's good to build it with
a wide variety of compilers as they often find different issues.


	- Eero