#error "GCC no longer implements <varargs.h>"

Hi!

Just compiled 3R6P1 with gcc 3.3.4.

Everything compiles fine, also with Scons
(great job! very useful!), except
the programs in the meta directory.

gcc 3.3 doesn't like the use of <varargs.h> any more ...
the error is:

-----8<----cut-here-----8<----cut-here-----8<----cut-here-----8<----

In file included from src/meta/imPfuncs.h:18,
                 from src/meta/impress.c:15:
/usr/lib/gcc-lib/i486-linux/3.3.4/include/varargs.h:4:2:
#error "GCC no longer implements <varargs.h>"
/usr/lib/gcc-lib/i486-linux/3.3.4/include/varargs.h:4:2:
#error "Revise your code to use <stdarg.h>."

-----8<----cut-here-----8<----cut-here-----8<----cut-here-----8<----

With gcc 2.95 the meta stuff compiles perfectly.

Simply changing
#include <varargs.h>
to
#include <stdarg.h>
doesn't work in this case ...

I've been using x11meta and the plot functions from time to time:
is there anybody else still using the libmeta related programs?

···

--
Francesco Anselmo <[email protected]>

Hi again!

Simply changing
#include <varargs.h>
to
#include <stdarg.h>
doesn't work in this case ...

I forgot to say how I fixed it ...

Here is what I've modified in ray/src/meta/imPfuncs.c to make it compile
again (also same #include modification in ray/src/meta/imPfuncs.h).

15c15
< #include <stdarg.h>

···

---

#include <varargs.h>

127c127,129
< imCreateFamilyTable(int count,...)
---

imCreateFamilyTable(va_alist)

va_dcl

136c138
< va_start(vars, count);
---

    va_start(vars);

161c163,165
< imCreatePath(int mcount, ...)
---

imCreatePath(va_alist)

va_dcl

169c173
< va_start(vars, mcount);
---

    va_start(vars);

--
Francesco

HiFrancesco,

Thanks for the bug report, and the fix. For whatever reason, varargs is still supported on the gcc 3.3 compiler under Mac OS X. I've noticed other differences between the Linux gcc and the Mac OS X one, to the point where I really don't think the version means much.

Anyway, I'm not sure it's even worth making this fix, since the Impress printer drivers are not used anymore. We should simply remove this program from the build list and fix it that way. There's no sense in maintaining obsolete programs in my opinion, though we seem to have a lot of them. We really need to compile a list of programs no one uses anymore and decomission them.

-Greg

Thanks for the bug report, and the fix. For whatever reason, varargs
is still supported on the gcc 3.3 compiler under Mac OS X. I've
noticed other differences between the Linux gcc and the Mac OS X one,
to the point where I really don't think the version means much.

Varargs is not C90, btw--I'm not sure what platform it comes from.

Anyway, I'm not sure it's even worth making this fix, since the Impress
printer drivers are not used anymore. We should simply remove this
program from the build list and fix it that way. There's no sense in
maintaining obsolete programs in my opinion, though we seem to have a
lot of them. We really need to compile a list of programs no one uses
anymore and decomission them.

I daresay. Can we even test this driver? Anyone have an Impress
printer?

Randolph

···

On Sun, Oct 31, 2004 at 02:01:00PM -0800, Greg Ward wrote:

Randolph Fritz wrote:

I daresay. Can we even test this driver? Anyone have an Impress
printer?

What *IS* an Impress printer ??? Maybe I'm too young to know about this..

-cb

Randolph Fritz wrote:

>
> Thanks for the bug report, and the fix. For whatever reason, varargs
> is still supported on the gcc 3.3 compiler under Mac OS X.

Varargs is not C90, btw--I'm not sure what platform it comes from.

Varargs is K&R C (pre ANSI). It is still supported by most
compilers (resp. the associated libraries) for backwards
compatibility. Apparently some gcc packages are starting to
abandon that tradition now, which was to be expected eventually.

> Anyway, I'm not sure it's even worth making this fix, since the Impress
> printer drivers are not used anymore.

If that's the only place where we use varargs.h, then dropping
that driver is a reasonable solution. If it's used elsewhere as
well, then we should fix those places to use the ANSI stdarg
macros instead. That's one of the remaining items in my
ANSIfication efforts.

Apropos: Can we establish any kind of consensus about which
modules in the current distribution are considered obsolete?
I'm sure there are a few more, and if we remove all of them in
one go, then that might eliminate a few more potential build
hassles. The deleted files will go to the CVS attic, where
people can still get them if anyone should ever need them again.

-schorsch

···

On Sun, Oct 31, 2004 at 02:01:00PM -0800, Greg Ward wrote:

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

I don't think varargs.h is used anywhere else -- at least, I've never used it. I took the impress functions from somewhere else. I don't think the printers have existed since 1989 or so, and they weren't even all that popular back then. PostScript took over the printer market about that time.

Here's my candidate list of programs for the CVS attic:

oki20 - printer driver for OkiMate 20 printer (B&W)
oki20c - printer driver for OkiMate 20 color printer
pcwarp - intended as more general substitute for macbetcal, but never quite worked
plotin - convert old Unix plot(5) files to metafile graphics
ra_avs - convert to & from AVS image format
ra_bn - convert to & from Barneyscann format
ra_pr - convert to & from 8-bit Sun rasterfile format (still used by anyone?)
ra_pr24 - convert to & from 24-bit Sun rasterfile format
thf2rad - convert GDS "things file" to Radiance scene format
ttyimage - picture to ASCII output converter (useful for anything anymore?)

So, not quite as many as I thought. In fact, I notice that the impress driver isn't in my list of built executables -- meaning that it's already effectively "off the list" of Radiance programs. However, it's still in the source directories, along with a lot of other flotsam that's no longer used for anything. I wonder now why Francesco was even seeing this error, and now I see that my gcc 3.3 compiler does NOT support varargs when I try to build the "impress" executable manually. Perhaps he was using SCONS, and schorsch included things there that are not built by the default Rmakefile.

So, we should add to the list source files that are not built by default these days. Unused headers:

hd/rhd_sample.h
hd/sm.h
hd/sm_flag.h
hd/sm_geom.h
hd/sm_list.h
hd/sm_qtree.h
hd/sm_stree.h
meta/macplot.h
meta/random.h
meta/span.h
meta/tgraph.h
px/tardev.h
px/x11icon.h
px/xraster.h
rt/newsconstants.h

Unused C-files:

common/bcopy.c
common/fixargv0.c
common/frexp.c
common/fwrite.c
common/malloc.c
common/peano.c
common/popen.c
common/random.c
gen/genmarble.c
gen/genbeads.c
gen/hermite3.c
hd/rhd_glx.c
hd/rhd_glx2.c
hd/rhd_ogl.c
hd/rhd_ogl0.c
hd/rhd_oglo.c
hd/rhd_ogls.c
hd/rhd_oglso.c
hd/rhd_x11dbg.c
hd/rhdisp3.c
hd/sm.c
hd/sm_del.c
hd/sm_geom.c
hd/sm_list.c
hd/sm_ogl.c
hd/sm_qtree.c
hd/sm_samp.c
hd/sm_sets.c
hd/sm_stree.c
hd/sm_test.c
hd/sm_usets.c
meta/aed5.c
meta/convect.c
meta/cvmaze.c
meta/ealloc.c
meta/genflake.c
meta/gentree.c
meta/hfio.c
meta/imPfuncs.c
meta/imagew.c
meta/implot.c
meta/impress.c
meta/mac.c
meta/macplot.c
meta/macprt.c
meta/mplot.c
meta/mqdraw.c
meta/mt160.c
meta/mt160l.c
meta/mtext.c
meta/mx80.c
meta/okimate.c
meta/plotout.c
meta/tbar.c
meta/tcurve.c
meta/tgraph.c
meta/tscat.c
meta/xplot.c
px/aedimage.c
px/brandom.c
px/colorscale.c
px/d48c.c
px/glimage.c
px/greyscale.c
px/hexbit.c
px/mt160r.c
px/paintjet.c
px/panim.c
px/psum.c
px/ra_im.c
px/ra_pixar.c
px/ra_xim.c
px/scan.c
px/slide.c
px/t4027.c
px/vgaimage.c
px/xdebugamb.c
px/ximage.c
px/xraster.c
rt/aed.c
rt/msmouse.c
rt/tty.c
rt/vga.c
util/contour.c
util/makedist.c
util/pranim.c
util/scanner.c
util/swaprasheader.c
util/t16anim.c

···

------------------

The README files in the corresponding directories explain what some of these are. For others, you have to examine the files themselves. Some have clearly not been compiled for a long, long time. As far as I'm concerned, we can retire them all to the CVS attic. If it turns out we made a mistake on one or two, we can always pull them down again. There's no real rush on this, so if anyone has any thoughts or wants to speak up for a favorite routine, now's the time.

-Greg

It was a competitor to PostScript developed by Imagen, back in the
long-long ago. There are probably still some imPRESS printers out
there operating--there are at least some Linux drivers for them. I am
hoping they are rare enough that we can stop worrying about imPRESS,
though.

Randolph

···

On Sun, Oct 31, 2004 at 11:53:58PM +0000, Carsten Bauer wrote:

Randolph Fritz wrote:

>
>I daresay. Can we even test this driver? Anyone have an Impress
>printer?
>

What *IS* an Impress printer ??? Maybe I'm too young to know about this..

Greg Ward wrote:

I don't think varargs.h is used anywhere else -- at least, I've never
used it.

I couldn't find any other instance either.

Here's my candidate list of programs for the CVS attic:

[...]
ttyimage - picture to ASCII output converter (useful for anything
anymore?)

Ttyimage is used in the test suite. It is generally a nice
debugging tool, which I also used when I wrote my image file
parser for Python some time ago.

  I wonder now why Francesco was even seeing this error,

He obviously tried to build the "special" selection.

and now I see that my gcc 3.3 compiler does NOT
support varargs when I try to build the "impress" executable manually.
Perhaps he was using SCONS, and schorsch included things there that are
not built by the default Rmakefile.

SCons has the same "special" targets as the RMakefiles, but
I'd be happy to get rid of them.

Unused C-files:

common/fixargv0.c

This is (or should be?) used on Windows to remove the *.exe
file name extension from executable paths. I'm not sure how
necessary it really is though, because even the SCons build
seems to ignore it at the moment.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Greg Ward wrote:

common/malloc.c

This also eliminates common/getpagesize.c, which does a few things
that we should definitively avoid anyway...

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Greg Ward wrote:

Unused C-files:

Two more I don't see used anywhere:

common/preadwrite.c
common/mktemp.c

Then there's common/fropen.c, which we might reimplement
in a more general way with the help of common/getpath.c

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/