has anyone tried the -traditional switch under NeXTSTEP 3.0 ?

Thread View: comp.sys.next.programmer

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by David Quarrie Thu, 03 Sep 1992 13:38

#1070

Author: David Quarrie
Date: Thu, 03 Sep 1992 13:38

61 lines
2248 bytes

--

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

Re: the -traditional switch under NeXTSTEP 3.0 ?

#1097

Author: David Quarrie
Date: Fri, 04 Sep 1992 12:56

67 lines
3033 bytes

--
In article <1992Sep3.133809.8477@murdoch.acc.Virginia.EDU>,
quarrie@cds001.cebaf.gov (David Quarrie) writes:
|>Subject: has anyone tried the -traditional switch under NeXTSTEP 3.0
|>?
|>Reply-To: quarrie@cds001.cebaf.gov (David Quarrie)
|>Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
|>Date: Thu, 3 Sep 1992 13:38:09 GMT
|>
|>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);
|>	}
|>
    [some lines omitted]
|>
|>I've since heard that the solution is to use the -traditional switch
|>to the
|>compiler:
|>
    [remainder of posting omitted]

I've just had a rapid response from NeXT on the above. The correct switch is

	cc -traditional-cpp

which does correctly compile the code sample whilst still correctly locating
the NeXT header files. This is documented in the NeXTSTEP 3.0 Release Notes.

Mike Monegan from NeXT says:

  NeXT implemented a new version of cpp (cpp-precomp) for NS 3.0 to support 
  precompiled headers.  This is the default preprocessor, but
unfortunately its 
  behavior is not completely identical to the standard GNU cpp.  In case
of the 
  above problem, an obscure bug fix to cpp-precomp was not released in
NS 3.0 due 
  to compiler stability concerns.  Subsequent releases of NeXTSTEP will
contain 
  this fix.  The temporary workaround is to use -traditional-cpp, which
is 
  documented in
/NextLibrary/Documentation/NextDev/ReleaseNotes/Preprocessor.rtf, 
  to get the old behavior (but without precompiled header support).

I'd like to thank Paul Richardson and Mike Monegan from NeXT for their help
in tracking this problem down and for pointing out the correct solution. I'd
should also admit to not using the correct channels on this - that's what
NeXTdeveloper support is for. Sorry about the wasted bandwidth.

-------------------------------------------------------------------------------
	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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads