64bit: C++ templates

Yaakov (Cygwin/X) yselkowitz@users.sourceforge.net
Mon May 20 06:59:00 GMT 2013


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?

> 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.

> 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.

> 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.


Yaakov



More information about the Cygwin-developers mailing list