🚀 go-pugleaf

In article <1992Jun29.152009.27415@daimi.aau.dk> eks@daimi.aau.dk (Eigil Krogh S|rensen) writes:

>   Maybe somone is able to help with the following problem I have with
>   gcc.
I try again, and would like to have your results puplished and discussed.

>   The system is Motorola SysV68 R3V5.1 MVME147 (delta).
As always, condolence!

>   When compiling & assembling with the old build-in cc and as everything
>   goes well (in this special case. Normally the build-in cc can't handle
>   GNU source !!). After running make, vh (copied to jargon while making)
>   runs ok.
Interesting, as strings are put into data-segment by cc. ... and the whole
libc was compiled with cc.

Indeed they often write into strings, as done in strtok. Please
refer to manual pages strtok(3).

>   If I use gcc-1.37.1 + gas-1.38  or  gcc-2.1 + as  I get the following
>   message, when vh (jargon) is started:
>	   Memory error  - core dumped.
>

gcc puts strings into text segment by default, and above error is to
be expected, if gcc-compiled objects are linked with libc.a from
Motorola.

Rule of thumb: use -fwrite-strings, if you intend to link your
	programs with libraries provided by Motorola.

>   Is this an error in the gcc's or am I doing something wrong. What
>   could it be that I'm doing wrong when using gcc ????

None of both. It is sloppy code in libc. The old cc would not complain
about, so it was right, right ?

>   When gcc is used, the following flags are set:
>
>   CFLAGS= -g -O -lm881
>   LIBS= -lm881
Perfect legal.

>   It's what I'm doing wrong when using gcc I'm interested in, not the
>   probelms with vh. As mentioned above I can use the build-in cc & as.
>   I'm interested in hearing about what one should do special, to get
>   gcc to work correct on this system (Motorola sysV68 R3V5.1 MVME147
>   (delta)).

Ever remember, that those porting the runtime libraries to 
Motorola-Delta3300 did not have GCC or comparable compilers, but
>> cc <<. 

Therefor expect: 

	- to have major bugs in the libraries caused by a buggy compiler
		( multiple dereferencing of a pointer chain blows it )

	- Programmers using it did not know anything about "const" data types,
		and did write to strings.

	- to have even buggy source code for sysgen. Some 
		versions of immu.h lacked a semicolon in a structure
		definition. GCC complained about syntax error, but
		cc did not, and compiled the structure into an array,
		no one  had intended I guess. 
 
BTW: My version of jargon works, compiled with 
	make jargon "CC=gcc -fwritable-strings "

>   Thank you in advance

The poor, beaten and desperate should keep together, and suport each other

adams@pdv2.fmr.maschinenbau.th-darmstadt.de