🚀 go-pugleaf

In article <mt00.710416072@chough> mt00@eurotherm.co.uk (Martin Tomes) writes:
>umrose05@ccu.umanitoba.ca (Dave Rose) writes:
>
>>Hello, 
>>	I've been trying to compile gcc 2.2.2 on my ISC 2.2.1 machine for
>>quite a few days now. I have it configured like: i386-isc-sysv32
>
>>And here is how my compile goes....Any help or suggestions would be
>>appreciated.
>
>..... Loads of stuff deleted .....
>
>>	./gcc    -g -B./  enquire.o -o enquire
>>undefined			first referenced
>> symbol  			    in file
>>putc                                enquire.o
>>ld fatal: Symbol referencing errors. No output written to enquire
>>*** Error code 1
>>`all' not remade because of errors
>
>putc is a macro which is not defined in ANSI C. It is a function in
>POSIX and can be found in libcposix.a.  I don't know which solution to
>your problem you should choose, gcc2.2.2 compiles fine on version 3.0
>of ISC UNIX.  Either you want to be in traditional C to get the macro
>or posix mode to get the function.
>
gcc 2.[n] run for ISC Versions 1.2 and 1.3 (latest) 'out of the box'
as does libg++-2.2 (first release to do so), both work *VERY RELIABLE*.
GCC:
The trick for ISC is to say 'configure i386-isc' which will automagically
invoke -lcposix for binding, the i386-isc-sys* configuration does not
work (for me).
If you try to compile your POSIX programmes later on with gcc, donot
forget to say '-posix' as POSIX secure signal handling and other things will
not work as expected if you don't (this flag invokes /lib/crtp0.o which
defines the OS - Environment in a static variable).

LIBG++:
2.2 is the first release that works for me under ISC.
However, configuration for me is 'configure i386-isc-sysv32' in the
libg++-2.2 main directory with the following changes to the config/mh-sysv
(I know I should change this to mh-isc and add another entry in configure.in,
but it's just for me):
CC = gcc -Wall
INSTALL = cp
RANLIB = echo.

Do not use gcc -posix during compilation of libg++ and do not define
_POSIX_SOURCE globally, this will cause many trouble due to different
function prototypes of POSIX and g++-include; however, I did not 
figure out how to enable ANSI/POSIX and libg++ to work together
without great hacking 
(might cause problems if the return value of a function under POSIX
is unsigned short and the g++-definition is int ...)

Hope this helps you
Bernd