[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] About GCC 2.9.1



Hi Frank,

>> In fact I finally succeded in compiling my program. But there
>> was strange things that I noticed. First the path are "hardcoded"
>> but I could cope with it.
>
>I don't understand. Which hardcoded paths do you mean? If you refer to the
>internal compiler error, this is a completly other thing and has nothing
>todo with hardcoded paths.

Hardcoded paths is the fact that include and library directories
should be at /usr/local/[lib|include]. In fact I was unable
to compile since I understood that those directory should
be present. That can't be replaced by a "-I" or a "-L" option
from GCC.

For the internal error, I just had to rearange my sources.
Internal errors seems to be caused by a too big C source file.

>> Second, it always failed during assembly
>> stage. In fact, the tempory asm file "luyfluyf.s" was erased before
>> it was loaded by the "as" assembler. The solution I found is to
>> compile with the "-S" option, producing a "eureka.s" file. Then
>> to assemble with the "-c" option, to generate an object file
>> "eureka.o".
>
>This looks strange for me. Please post the exact command line. I think
>there is something wrong with GCC calling command.

I'm not calling GCC directly. The Makefile is usefull for that.
But in my makefile I have something like that :

________________________________________________________
CFLAGS=		-O4 -m68000 -I/usr/include
LFLAGS =	-o eureka.prg -L/usr/lib
CC =            /usr/local/bin/gcc

# Make's implicit rules for making a .o file from a .c file...
#
.c.o :
	$(CC) -S $(CFLAGS) $*.c
	$(CC) -c $(CFLAGS) $*.s
	rm -S $*.s

....

eureka:	$(OBJS)
	$(CC) $(LFLAGS) $(OBJS) -lc16 -lm -lgem16 -lldg16

________________________________________________________


>> The third thing was that I linked with the binutil 40 "ld"
>> (from 2.8.1) because the 2.9.1 version was unable to find
>> the "crt0.o" file, though it was in the correct path.
>
>I strongly recommend to use the new binutils. If you have problems it's
>mostly a configuration problem from your side. For example: you can't use
>old style libraries with the new binutils. You must first convert your
>libs.

Yes, the new libs are .a instead of .olb and should begin with
lib. Just one thing, how MT_AES16.olb should be renamed taking
account of the 8.3 format ? I'm working with TOSFS !

But what I told you is that the latest ld from binutil 2.9.1
doesn't recognize the "crt0.o". He tells me /usr/lib/crt0.o
file not found, though it exists. I just took the older ld,
renaming the libraries, and all is fine now. Have a look
at http://eureka.atari.org/eurk1199.zip it's correct !
I haven't followed the latest developments of MiNTlib
(no object format are given).

I wish I've been clear enough.

Bye for now ...

-- Francois LE COAT
Author of Eureka 2.12 (2D Graph Describer 3D Modeller)
http://eureka.atari.org
mailto:lecoat@atari.org