64bit: C++ templates

Kai Tietz ktietz70@googlemail.com
Mon May 20 13:15:00 GMT 2013

2013/5/20 Corinna Vinschen wrote:
> Hi Yaakov,
> On May 20 01:59, Yaakov (Cygwin/X) wrote:
>> On 2013-05-16 03:25, Corinna Vinschen wrote:
>> >Yesterday it turned out that the visibility stuff is not the real
>> >problem.  Mingw gcc 4.8 also produces the same set of symbols, but it
>> >doesn't fail when linking.
>> Is that surprising, given that PE-COFF medium/large code models were
>> only added to trunk (AFAIK) post-4.8?
> well, this is not exactly related to the medium/large code model
> introduction but rather a feature of gcc 4.8.  The same problematic
> symbols are generated in the small code model in 4.8, but not with gcc
> 4.7.2.
>> >Some more testing now showed clearly that this problem is related to the
>> >high address used as base addresses in the Cygwin toolchain.  If you
>> >build the harfbuzz DLL not with
>> >
>> >   -Wl,--enable-auto-image-base
>> >
>> >but instead with a fixed address in the lower 31 bit address area,
>> >for instance
>> >
>> >   -Wl,--image-base -Wl,0x7ff00000
>> >
>> >the problem disappears and you can successfully build the DLL.
>> This seems to fix harfbuzz wrt gtk2; gtk3 still isn't working, but
>> I'm not sure it's related yet.
> Dunno, but more info on that might help my collegues to fix the issue.
>> >Alternatively, you can also workaround this issue by building harfbuzz
>> >with the -mcmodel=large option, which doesn't suffer this problem due to
>> >the way symbols are only indirectly addressed.
>> With this, the link succeeded but I got SEGVs in one of the same
>> symbols that failed to link previously.
> This is a weird one!  Maybe there's still some bug in the large model
> code generation?!?  OTOH, if that's only related to this kind of symbol
> it might be a related issue.  Can you check if setting
> -fvisibility-inlines-hidden or -fno-visibility-inlines-hidden changes
> the outcome?
>> >Right now it seems this is a bfd bug in the relocation code.  The code
>> >tests these 32 bit pc-relative offsets by checking if the result still
>> >fits into 31 bit, without taking the high image base into account.
>> >Also, for some reason this doesn't occur with all symbols, but only with
>> >a very specific set of symbols (weak and a special kind of section
>> >symbols).
>> >
>> >That's it for now.  We're still looking into providing a solution.
>> Please keep me posted.
> Sure!
> Thanks,
> Corinna

Beside the ongoing testings I do to solve this issue for binutils, it
might be of interest to see if change referenced at

c++/57317 might have impact on the template-issue here?


More information about the Cygwin-developers mailing list