64bit: C++ templates
Wed May 22 08:10:00 GMT 2013
On May 20 11:26, Corinna Vinschen wrote:
> 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
> > >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.
Any more info here?
> > >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.
Assuming the build worked, how can one reproduce this SEGV?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
More information about the Cygwin-developers