Building gcc/g++ 2.2 on a Motorola Delta

Thread View: gnu.g++.help

2 messages

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

2 total messages Started by Steve Robertshaw Thu, 20 Aug 1992 02:20

#201

Author: Steve Robertshaw
Date: Thu, 20 Aug 1992 02:20

23 lines
1454 bytes

Hi,

I have finished building gcc/g++ on a Motorola Delta system (MVME147)
which is currently running sysV68 r3V5.1 (Motorola's Unix). The gcc seems to
work just dandy. The g++ compiler on the other hand produces assembly code 
label extensions for the function protoypes using the '$' character. I have
tried playing around with the cp-tree.h and associated tm.h files.
Unfortunately the assembler's only separator characters available are '_',
which wreaks havoc with C labels if that is the JOINER, '~', which would work
fine except that the assembler only lets you place it at the beginning of the
label, and '%', which of course will wreak havok with all the sprintf
statements. Does anyone know of a solution to this dilema as well as any other
pitfalls which may befall the unsuspecting. Thanks.

Steve Robertshaw

-- 

Steve Robertshaw                curtech!swr@nic.unh.edu
Current Technology              (603) 868-2270
99 Madbury Rd.
Durham, NH   03824

Re: Building gcc/g++ 2.2 on a Motorola Delta

#204

Author: Adams
Date: Fri, 21 Aug 1992 00:34

37 lines
2411 bytes

In article <9208200218.AA25714@ctnet> swr@curtech.UUCP (Steve Robertshaw) writes:

>   Hi,
>
>   I have finished building gcc/g++ on a Motorola Delta system (MVME147)
>   which is currently running sysV68 r3V5.1 (Motorola's Unix). The gcc seems to
>   work just dandy. The g++ compiler on the other hand produces assembly code 
>   label extensions for the function protoypes using the '$' character. I have
>   tried playing around with the cp-tree.h and associated tm.h files.
>   Unfortunately the assembler's only separator characters available are '_',
>   which wreaks havoc with C labels if that is the JOINER, '~', which would work
>   fine except that the assembler only lets you place it at the beginning of the
>   label, and '%', which of course will wreak havok with all the sprintf
>   statements. Does anyone know of a solution to this dilema as well as any other
>   pitfalls which may befall the unsuspecting. Thanks.

>   Steve Robertshaw

Your observations are right. Methods in cp-tree.h etc. generating
symbol names have  to be beefed up a just `little' bit for this marvellous 
architecture (MVME147 rnning sysV68R3.[456]). 

Already I started a port of GCC-2.2.2. gcc works fine, as optimization
might be to be improved (I know I got the sources ....). g++ is able
to compile most of our c++ sources, but groff shows a strange bug in
the system provided libc.a. Closing a file will provoke a SIGBUS
/SIGSEG, as runtime library claims buffers are lost .... ...

If there is interest, I will put this work on
	"ftp.th-darmstadt.de:/pub/incoming/local_ports/sysV68/..."

Please mail to :
	gnu@pdv2.fmr.maschinenbau.th-darmstadt.de.

This port is  approved neither by FSF nor RMS.

best, adams

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