>>> Hi NG
>>>
>>> I use AIX 5.3, GCC 4.2.2 and ld 1.65.2.4 (2/8/07).
>>>
>>> I have a problem when linking some binaries which are part of our
>>> product.
>>> I could reduce the problem to a hello-world program. I get the following
>>> errors when linking my hello-world program with the libraries of our
>>> product:
>>>
>>> ld: 0711-783 WARNING: TOC overflow. TOC size: 955784 Maximum size:
>>> 65536
>>> Extra instructions are being generated for each reference to a
>>> TOC
>>> symbol if the symbol is in the TOC overflow area.
>> From
>> http://www-304.ibm.com/jct09002c/isv...sp?oid=1:15856
>> ...
>> On AIX 4.x there is no limit for TOC size. You can use -bbigtoc flag
>> and get around MAX TOC size using regular ld/bind. You will still get
>> the WARNING: TOC overflow message. This warning is expected whenever
>> TOC overflow occurs and the -bbigtoc option is used.
>>
>> So i would assume the same for AIX 5.3
>>
>> hth
>> hajo
>
>
> Thanks for your answer.
>
> This warning is not my problem. I posted it because I don't know whether
> it is relevant or not for the error which occurs while linking.
> Btw, I use the -bbigtoc option as mentioned in my first post.
>
>>> 2. Does it have to do with the TOC overflow warning? (Please note that I
>>> already link with -bbigtoc)
>
>
> Regards, Chris
>

Hi NG

I could not solve the problem above by myself in the meantime.
Finally, some AIX guys were able to help.
Here is the last mail they've written to me which includes the solution:

> This is a bug in gcc (or g++), as evidenced by locale-init.o (and I
> suspect wlocale-init.o).
>
> There are multiple .text csects in locale-init.o, and there is a branch
> from 1 csect to another. When the linker assigns addresses to the
> csects, the csects are far enough apart that the branch overflows.
> Normally, the overflowing branch instruction would be replaced (by the
> linker) with a branch to a branch, ultimately reaching the desired target
> instruction.
>
> Unfortunately, the referenced symbol used for the branch causes the
> overflow fixup code to fail. In order for branches to be fixed up
> properly, the branch has to be a branch to the target symbol, not the
> target plus an offset. That is, if you have :
> .extern .foo
> bl .foo+4
>
> This instruction can't be fixed up, because of the "+4".
>
> In locale-init.o, symbol 8818 is a csect containing 2 labels: symbol
> 9656 and 9753. Symbol 9565 has an address of 0, while symbol 9753 has
> an address of 0x130
>
> The branch instruction is in the csect at symbol 14092, whose only label
> is at 14094. The address of the branch is 0x9f7c, and it is generated as
> a branch to 0x130 (the address of symbol 9753).
>
> The relocation for this branch (which you can see by extracting
> locale-inst.o and running dump -X64 -r locale-inst.o | grep 0009f7c) is
> based on symbol 8818 (=3D0x2272).
>
> If the relocation were to symbol 9753, the target of the branch would be
> to the address of the referenced symbol with no offset, and fixup would
> work. Other branches were fixed up successfully.
>
> A workaround is to use -Wl,-bnoobjreorder. This keeps .text csects in
> the same object file together, so no branch overflow occurs.
> Nevertheless, the compiler problem should be reported to the gcc (g++)
> developers.
>
>
> (By the way, the limit on the size of a single csect containing branches
> to other csects is not explicitly documented, but it is implied by the
> PowerPC architecture, where the branch instruction is described. This is
> similar to the restriction on the target of a conditional branch
> instruction, which contains a signed, 16-bit offset.)
>

With the option -Wl,-bnoobjreorder everything works fine.
I've not reported the bug to gcc.

Greetings Chris