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

Re: [MiNT] linker problem with -r (relocateable)



Hello, Alan.

I'm away until next week and I don't have access to the tools.
You experienced a crash, it may be related to standard binutils code or MiNT patch. In any case, it is a bug and must be fixed.

I have never tested the -r option, it is well known that things not tested don't work :-(

I think there may be a mess between file formats.

gcc -c main.c

Good, main.o is an object file in format a.out-zero-big.

ld -r -o main2.o main.o

I'm not sure what is main2.o... By defaut, ld produces files in a.out-mintprg format. So in that case, main2.o is probably a "relocatable" file (in an a.out point of view) in format a.out-mintprg. I never tested such a thing, I'm don't know if something correct is generated.

Indeed, using the following command may do the right thing :
ld -r -o main2.o main.o --oformat a.out-zero-big

ld -o main3.o main2.o 			-> crash.

Here, there is no specific option, so the output file is a standard a.out-mintprg executable, it should not be named with ".o". Anyway, it is not a problem. But if main2.o is actually what I described above, I'm really not sure the linker is able to deal with it as input... Obviously, it is not the case, because of the crash...

I will look at it when possible.

Now -r means generate relocateable code and I don't think we should be
allowing that with our a.out format ?

You are probably right. The a.out-mintprg file format should be used only for final linker output, it is not intended to be treated as a linker input file.

> Maybe just silently ignore the -r
option as quite a few tools use it.

Where did you find usage of the -r option ?
Is it a real world issue ?
Or was it only a test for linker options ?

Vincent