🚀 go-pugleaf

--

Has anyone tried using the -traditional switch to the Ccompiler under NS 3.0?

I have the following little test program:

	david> cat problem.c

	#define CALL(a,b,c) ((a=b),c)
	#define CALL_R CALL
	void problem (bc)
	int *bc;
	{
       		int *t1, *t2;
        	CALL_R(t1, (int *)(CALL_R(t2, bc, t2)), t1);
	}

	david> cc problem.c             
	/bin/ld: Undefined symbols:
	_main
	_CALL

The program doesn't make any sense, it is a heavily abstracted snippet of code
generated automatically by a language compiler. However, I used it to
illustrate
a problem under NS3 PR 2 that cpp didn't fully resolve the macros (which
it used
to do under NS 2.1).

I've since heard that the solution is to use the -traditional switch to the
compiler:

	david> cc -traditional problem.c
	/bin/ld: Undefined symbols:
	_main

All well and good, until I add an #include statement:

	#include <stdio.h>
	#define CALL(a,b,c) ((a=b),c)
	[...]

	david> cc -traditional problem.c
	/NextDeveloper/Headers/ansi/machine/stddef.h:11: #include expects
"fname" or <fname>
	/NextDeveloper/Headers/ansi/machine/stdarg.h:11: #include expects
"fname" or <fname>

I've tried this in combination with other switches (e.g. -gnu-cpp) to no avail.

Other relevant information is that I still have NS3 PR2 but I've heard that
the problem persists under NS3.0. 

Aynone have any suggestions? (or even better, a solution!).

-------------------------------------------------------------------------------
	David Quarrie					CEBAF MS 12H
							12000 Jefferson Ave
Internet: quarrie@cebaf.gov				Newport News VA 23606
DECnet  : cebaf::quarrie				Tel: (804) 249-7562
BITNET  : quarrie@cebaf					Fax: (804) 249-7363