This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64bit: C++ templates


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]