Re: [cc65] Problems with va_copy

Hello Uz,

* On Sun, Dec 11, 2005 at 04:55:22PM +0100 Ullrich von Bassewitz wrote:

> > As always, this tool can be good is used properly, and bad if used in
> > places where it should not.
> 
> I coan see a use for autoconf for unix only programs because there are lots of
> subtle differences if you're going to things like threads and such.

This is what I meant with libraries - but not only this. For example, if
libpcap is available, on can use this for even better experience. libnet
is available? Good, use that. Oh... There are two incompatible versions
of libnet available? Find out which one we have, and use the
implementation of that.

> But it's always worth a try to go without, since the resulting
> programs are often more portable. Which is not a value by itself, but
> - in my eyes - leads to better and cleaner designs.

Well, I must admit that I learned much about portable programming lately
in de.comp.lang.c and comp.lang.c. I must admit that my programs are not
that portable as I thought before. ;)


> > Ok, good. Anyway, while this is the theory, we all know that compilers
> > have always polluted the namespaces with their own extensions.
> 
> This is a common excuse, but it is not true. Not even the microsoft compiler
> does this.

Wasn't there some version of gcc where many standard include files were
mangled into just one include file? Thus, if you included either of
them, it just included the generic one, which made all names, even the
ones which should not have been included? Ok, this is not exactly the
same, although the namespace is polluted with names it should not have
been.

Additionally, I remember some version of the Microsoft Compiler
including windows.h if some of the standard header were included. :(
 
> > - Cygwin:
> >   The build stops with:
> >   make[4]: Leaving directory `/home/trikalio/cc65-snapshot-2.11.9.20051211/libsrc/geos/system'
> >   ar65: Error: `../geos.lib' is not a valid library file

> That sounds like a binary/text mode problem. Is it possible that you
> try this with -std=c99?

Ok, I have replaced std=c89 with std=c99 in all make files: The error
remains exactly the same.

BTW: Do you think this error to be related to this late changes?


> There may also be problems with binary mounts noted in the FAQ.

Where? I search http://www.cc65.org/faq.php for "binary" (2 matches, but
no one which counts here), "cygwin", "mount", but did not find anything.

> In any case, it's a problem of the compiler (it was my goal to allow
> me to say this in case of problems, and now I can:-)

I tried on another Win machine with a newer cygwin install:

$ gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

Here, it compiles flawlessly.

For comparison reasons: The non-working gcc has version

$ gcc --version
gcc (GCC) 3.3.1 (cygming special)

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.