[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amd-dev
Subject:    Re: Solaris 2.6/SunPRO C 4.2 out of the box problems
From:       Erez Zadok <ezk () shekel ! mcl ! cs ! columbia ! edu>
Date:       1998-01-24 5:44:02
[Download RAW message or body]

In message <m0xvn9s-0003HtC@ainur.ee.surrey.ac.uk>, B.King@ee.surrey.ac.uk writes:
> First up, many thanks to Rainer Orth for his help with the 
> varargs issue.
> 
> I've found another point where the compile barfs, which is even
> sillier...
> 
> cc -DHAVE_CONFIG_H -I. -I../../amd -I.. -I../../include  -g -D_LARGEFILE64_SOURCE  \
> -c ../../amd/get_args.c "../../amd/get_args.c", line 338: newline in string literal
> 
> Methinks someone has been using Gcc way too much...  Doing the
> obvious and removing the imbedded newlines from the source file
> solves the problem.

That's not the right way, b/c amd -H will print one long string.  a15 was
missing a "\n\" at the end of the help string.  a16s1 fixed this.


As for the stdarg/vararg, the proper way is to use one and only one of them,
at least on solaris.  Including both causes problems on some systems.
Am-utils tries to ensure that only one of them will be used, when both are
available.  Unfortunately 2.6's <sys/fs/autofs.h> directly includes
<sys/varargs.h> so if you use stdargs.h in a source code with autofs, you
will undoubtedly get a conflict.  Sigh.

Using #undef va_end et al may not work well, b/c still, the rest of the
second file's definitions are included, and they could potentially conflict
later.  It's better to not include a second *arg header if possible, and
that's what a16s3 does.

Erez.


[prev in list] [next in list] [prev in thread] [next in thread]