Linker Aztek C 3.6

Hi folks,
over the holidays I got my nifty Kyroflux device (enabling me to convert my old Amiga disks to ADFs).

Now... I wanted to check my old programming stuff, setup a quite extensive UAE environment. Got all my C-Sources together installed diverse Aztek/Lattice C and so on.

Now - there seems to be everthing working again, I can assemble, compile and -nearly- link all stuff.

The linker from the from the Aztekt C package (ln) gives following message:

Relocation table invalid from 0 to 0, of -65536!!

I know (naturally) what a relocation table is, but I can't get to grips with this error message.
I searched the net, was astonished about all the documentation I got on Aztek C. But alas, in all the documentation there is *NO* description of Linker errors.

Can anybody out there give me a clue what this is about and how I can fix it?
(The environment is now about exactly the same as the original, I am pretty sure of that).

... and please don't tell me to use Lattice, SAS or Dice or so... I would like to get the damn Aztek working again .-).

Thx for listening...

Regards

Malban

[alkis]

Longshot...could it be a small data model configuration limitation? Can you switch to _not_ using small data?

Thanks for the interest - but no. I use large memory model.
This is configured correctly.
The error message is another one, can't remember right now, but something with

your data/code segment is larger than 65536 ...

Regards
Malban

[kamelito]

Try search on usenet I saw post from 1988 not sure if a fix is given though.
Why not trying a newer version of Manx?
Kamelito

[alkis]

Aztec C68k/ Amiga COMPILER

cc prog- small code, small data

cc +C prog large code, small data

cc +D prog small code, large data

cc +C +D large code, large data

1.4.4 Libraries

The modules in the Aztec C68k libraries use the small code, small
data memory modeL

1.4.5 Multi-module programs

The modules that you link together to form an executable program
can use different memory models, with the following caveat

When large data and small data modules are linked together, the
linker will create an arbitrarily large data segment, without attempting
to sort the data into those that are accessed by large data modules and
those that are accessed by small data modules. When the program is
running, address register A4, which the small data modules use to
access data, will point into the middle of this data segment.

Here's the caveat data that the small data modules attempt to access
must be within 32k bytes of the location pointed at by A4. The linker
will detect data accesses by small data modules for which this condition
isn't satisfied, and issue a message. If you get this message, try
reordering the order in which the linker encounters them; if that
doesn't solve the problem, you'll have to recompile the small data
modules, making them use large data.

As we mentioned above, the modules in the libraries supplied with
Aztec C68k use the small data memory model; hence, recompilation of
a program's small data modules to use large data must include the
library modules.

source: https://archive.org/stream/Manx_Azte...stems_djvu.txt

Yeah, I already read that to, I did find the archive and the docs there :-)!
But as I said, I am pretty sure that the memory model is not the wrong.

• I generate all C-sources with +D and +C
• the one Assembler file I have has the lines:
  far data
  far code
  (as required)
• - I link the cl.lib (that is the c "LARGE".lib)

If I change any of that and use small model I get the following error:

Total data size > 64K! Too large for small data model.
ln failed returncode 10

Since "my" error is different - I don't think it is the memory model.

Regards

Malban

[phx]

The last time I used Aztec-C 3.4 or 3.6 must have been more than 25 years ago, and I don't remember this error. But the first I would try to find out is the source of the error.

Isn't there any note about the name of the object file which had this invalid relocation table?

It is hard to guess what this error means, because I remember Aztec-C, unlike Lattice-C, used a custom object file format (it was definitely not hunk format). Maybe from/to 0 is the section offset to relocate or just the section index (first section)? -65536 looks like a 16-bit overflow. Who knows...

You should also try to find out in which situations this error is generated. Does it happen always? Then maybe your linker libraries are corrupted. Or when linking a specific program? Try to isolate the problem and generate a simple source for reproduction which you can post here.

Found a news entry from 1988:

comp.sys.amiga.tech

I guess, I will just try another C package - though Im sure I did all my developing with Aztekt C 3.6 back than...

Regards

Malban