64bit: gcc vs. harfbuzz

Post by Yaakov (Cygwin/X)
harfbuzz (since at least 0.9.12) is failing to link with gcc-4.8.0-1 on
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/harfbuzz

gcc-4.8.0-2 does NOT solve this, and boost is also affected:

git clone --recursive
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/boost

Dependencies are gcc-g++, libicu-devel, python, python3.

bin.v2/libs/regex/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instances.o:instances.cpp:(.rdata+0x158):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost9re_detail12perl_matcherIPKcSaINS_9sub_matchIS3_EEENS_12regex_traitsIcNS_14c_regex_traitsIcEEEEE15match_startmarkEv'
bin.v2/libs/regex/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instances.o:instances.cpp:(.rdata+0x15c):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost9re_detail12perl_matcherIPKcSaINS_9sub_matchIS3_EEENS_12regex_traitsIcNS_14c_regex_traitsIcEEEEE15match_startmarkEv'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/regex/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instances.o:
bad reloc address 0x160 in section `.rdata'
collect2: error: ld returned 1 exit status

bin.v2/libs/locale/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/win32/numeric.o:numeric.cpp:(.rdata+0x254):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost6locale4util15base_num_formatIwE11do_real_putIdEESt19ostreambuf_iteratorIwSt11char_traitsIwEES8_RSt8ios_basewT_'
bin.v2/libs/locale/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/win32/numeric.o:numeric.cpp:(.rdata+0x258):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost6locale4util15base_num_formatIwE11do_real_putIdEESt19ostreambuf_iteratorIwSt11char_traitsIwEES8_RSt8ios_basewT_'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/locale/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/win32/numeric.o:
bad reloc address 0x25c in section `.rdata'
collect2: error: ld returned 1 exit status

bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_k.o:cyl_bessel_k.cpp:(.rdata+0x13c):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost12basic_formatIcSt11char_traitsIcESaIcEE5parseERKSs'
bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_k.o:cyl_bessel_k.cpp:(.rdata+0x140):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost12basic_formatIcSt11char_traitsIcESaIcEE5parseERKSs'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_k.o:
bad reloc address 0x144 in section `.rdata'
collect2: error: ld returned 1 exit status

bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_kf.o:cyl_bessel_kf.cpp:(.rdata+0x15c):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost12basic_formatIcSt11char_traitsIcESaIcEE5parseERKSs'
bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_kf.o:cyl_bessel_kf.cpp:(.rdata+0x160):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost12basic_formatIcSt11char_traitsIcESaIcEE5parseERKSs'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/math/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/cyl_bessel_kf.o:
bad reloc address 0x164 in section `.rdata'
collect2: error: ld returned 1 exit status

bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:xml_iarchive.cpp:(.rdata+0xe0):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost7archive9iterators18dataflow_exception4whatEv'
bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:xml_iarchive.cpp:(.rdata+0xe4):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost7archive9iterators18dataflow_exception4whatEv'
bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:xml_iarchive.cpp:(.rdata+0x48):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost7archive9iterators18dataflow_exception4whatEv'
bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:xml_iarchive.cpp:(.rdata+0x4c):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost7archive9iterators18dataflow_exception4whatEv'
bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:xml_iarchive.cpp:(.rdata+0x50):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZNK5boost7archive9iterators18dataflow_exception4whatEv'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/serialization/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/xml_iarchive.o:
bad reloc address 0x0 in section
`.pdata$_ZN5boost7archive6detail15common_iarchiveINS0_12xml_iarchiveEE5vloadERNS0_12version_typeE'
collect2: error: ld returned 1 exit status

bin.v2/libs/wave/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instantiate_re2c_lexer.o:instantiate_re2c_lexer.cpp:(.rdata+0x18c):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost4wave4util11flex_stringIcSt11char_traitsIcESaIcENS1_9CowStringINS1_22AllocatorStringStorageIcS5_EEPcEEE6assignEPKc'
bin.v2/libs/wave/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instantiate_re2c_lexer.o:instantiate_re2c_lexer.cpp:(.rdata+0x190):
relocation truncated to fit: R_X86_64_PC32 against
`.text$_ZN5boost4wave4util11flex_stringIcSt11char_traitsIcESaIcENS1_9CowStringINS1_22AllocatorStringStorageIcS5_EEPcEEE6assignEPKc'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
bin.v2/libs/wave/build/gcc-4.8.0/release/pch-off/python-2.7/threading-multi/instantiate_re2c_lexer.o:
bad reloc address 0x194 in section `.rdata'
collect2: error: ld returned 1 exit status

Corinna Vinschen

2013-04-18 06:57:01 UTC

Hi Yaakov,

Post by Yaakov (Cygwin/X)
harfbuzz (since at least 0.9.12) is failing to link with gcc-4.8.0-1 on
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/harfbuzz

git clone --recursive
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/boost
Dependencies are gcc-g++, libicu-devel, python, python3.
relocation truncated to fit: R_X86_64_PC32 against `.text$_ZN5boost9re_detail12perl_matcherIPKcSaINS_9sub_matchIS3_EEENS_12regex_traitsIcNS_14c_regex_traitsIcEEEEE15match_startmarkEv'
relocation truncated to fit: R_X86_64_PC32 against `.text$_ZN5boost9re_detail12perl_matcherIPKcSaINS_9sub_matchIS3_EEENS_12regex_traitsIcNS_14c_regex_traitsIcEEEEE15match_startmarkEv'
bad reloc address 0x160 in section `.rdata'
collect2: error: ld returned 1 exit status
[...]

Kai is going to take a look in the next couple of days. This is
something weird. It looks like the 64 bit Mingw gcc is not affected
by this.

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-04-18 07:37:36 UTC

Post by Corinna Vinschen
Kai is going to take a look in the next couple of days. This is
something weird. It looks like the 64 bit Mingw gcc is not affected
by this.

No, it's not; I was able to build the same version of boost with my
mingw64-x86_64-gcc 4.8.

Yaakov

Corinna Vinschen

2013-04-18 08:26:21 UTC

Post by Corinna Vinschen
Kai is going to take a look in the next couple of days. This is
something weird. It looks like the 64 bit Mingw gcc is not affected
by this.

No, it's not; I was able to build the same version of boost with my
mingw64-x86_64-gcc 4.8.

Did you try to eliminate if one of the extra patches applied to stock
4.8 is the culprit, perhaps?

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Corinna Vinschen

2013-04-18 09:15:41 UTC

Post by Corinna Vinschen
Kai is going to take a look in the next couple of days. This is
something weird. It looks like the 64 bit Mingw gcc is not affected
by this.

No, it's not; I was able to build the same version of boost with my
mingw64-x86_64-gcc 4.8.

Did you try to eliminate if one of the extra patches applied to stock
4.8 is the culprit, perhaps?

Btw., I can't prep from from the 4.8.0-2 sources:

$ cygport --64 *port prep
*** Info: Building native toolchain for x86_64-pc-cygwin host

Post by Corinna Vinschen
Preparing gcc-4.8.0-2
Unpacking source gcc-4.8.0.tar.bz2

*** Info: Removing DISTCLEANFILES...
*** Info: applying patch 4.7-ada.patch:
[...]
*** Info: applying patch 4.7-boehm-gc-cygwin.patch:
[...]
*** ERROR: patch 4.7-execstack.patch will not apply

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-04-18 17:57:37 UTC

Fixed in git.

Yaakov

Yaakov (Cygwin/X)

2013-05-10 06:13:44 UTC

Post by Yaakov (Cygwin/X)
harfbuzz (since at least 0.9.12) is failing to link with gcc-4.8.0-1 on
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/harfbuzz

git clone --recursive git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/boost
Dependencies are gcc-g++, libicu-devel, python, python3.

Kai? Dave?

Yaakov

Kai Tietz

2013-05-14 12:45:27 UTC

Hi,

Post by Yaakov (Cygwin/X)
harfbuzz (since at least 0.9.12) is failing to link with gcc-4.8.0-1 on
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/harfbuzz

git clone --recursive
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/boost
Dependencies are gcc-g++, libicu-devel, python, python3.

Kai? Dave?
Yaakov

I tried to track this reported down, but it still puzzles me. From
POV of compiler there is no real difference between mingw and cygwin
which could reason this different behavior (at least I didn't found
until now).
So it might be a linker issue?! Yaakov, could you try to use instead
of the cygwin-linker the mingw 64-bit one? It might be a
linker-spec-file or linker-issue.

Kai

Kai Tietz

2013-05-15 09:32:36 UTC

Hi,

the issue is a more general on and related to harfbuzz' use of
-fvisibility-inlines-hidden for mingw-targets, but not for cygwin
targets. Btw the issue should be latent present for 32-bit too.
Well, nevertheless my test have shown that this option indeed fixes
that described issue.

Question here is if we shouldn't make visibility for inlines always
hidden on pe-coff targets. I will think about this a bit. The
following patch would do that:

Regards,
Kai

Index: decl2.c
===================================================================
--- decl2.c (Revision 198882)
+++ decl2.c (Arbeitskopie)
@@ -2308,7 +2308,11 @@ determine_visibility_from_class (tree decl, tree c
static bool
determine_hidden_inline (tree decl)
{
- return (visibility_options.inlines_hidden
+ return ((visibility_options.inlines_hidden
+#ifdef TARGET_PECOFF
+ || TARGET_PECOFF
+#endif
+ )
/* Don't do this for inline templates; specializations might not be
inline, and we don't want them to inherit the hidden
visibility. We'll set it here for all inline instantiations. */

Kai Tietz

2013-05-15 10:41:43 UTC

Sorry, wrong patch. Proper is:

Index: decl2.c
===================================================================
--- decl2.c (Revision 198882)
+++ decl2.c (Arbeitskopie)
@@ -2309,6 +2309,9 @@ static bool
determine_hidden_inline (tree decl)
{
return (visibility_options.inlines_hidden
+#ifdef TARGET_PECOFF
+ && !TARGET_PECOFF
+#endif
/* Don't do this for inline templates; specializations might not be
inline, and we don't want them to inherit the hidden
visibility. We'll set it here for all inline instantiations. */

Corinna Vinschen

2013-05-16 08:25:34 UTC

Hi Yaakov,

Post by Kai Tietz
Hi,
the issue is a more general on and related to harfbuzz' use of
-fvisibility-inlines-hidden for mingw-targets, but not for cygwin
targets. Btw the issue should be latent present for 32-bit too.
Well, nevertheless my test have shown that this option indeed fixes
that described issue.

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.

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

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.

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-05-20 06:59:39 UTC

Post by Corinna Vinschen
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?

Post by Corinna Vinschen
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.

Post by Corinna Vinschen
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.

Post by Corinna Vinschen
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

Corinna Vinschen

2013-05-20 09:26:14 UTC

Hi Yaakov,

Post by Corinna Vinschen
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.

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.

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?

Please keep me posted.

Sure!

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Kai Tietz

2013-05-20 13:14:51 UTC

Post by Corinna Vinschen
Hi Yaakov,

Post by Corinna Vinschen
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?

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.

With this, the link succeeded but I got SEGVs in one of the same
symbols that failed to link previously.

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?

Cheers,
Kai

Corinna Vinschen

2013-05-21 10:13:01 UTC

Post by Kai Tietz
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?

Do you have a direct link to this issue?

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Corinna Vinschen

2013-05-21 11:06:30 UTC

Post by Kai Tietz
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?

Do you have a direct link to this issue?

Never mind, I found the patch:

http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/cp/decl2.c?r1=197830&r2=199104&view=patch

Yaakov, any chance you can try that?

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-05-21 23:45:45 UTC

Post by Kai Tietz
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?

Do you have a direct link to this issue?

http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/cp/decl2.c?r1=197830&r2=199104&view=patch
Yaakov, any chance you can try that?

GCC 4.8.1 is due out this week or next, so if it's already in the
branch, I can try it then.

Yaakov

Yaakov (Cygwin/X)

2013-05-27 06:15:07 UTC

Post by Kai Tietz
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?

Do you have a direct link to this issue?

http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/cp/decl2.c?r1=197830&r2=199104&view=patch
Yaakov, any chance you can try that?

Just tried the 4.8-20130523 snapshot, which includes that patch, but the
results were the same.

Yaakov

Corinna Vinschen

2013-05-22 08:10:13 UTC

Hi Yaakov,

Post by Corinna Vinschen
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?

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?

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?

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-05-22 19:34:09 UTC

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?

No, I haven't had time to look into it.

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?

e.g. running gtk-demo (from the gtk2.0-demo package).

Yaakov

Kai Tietz

2013-05-23 08:26:24 UTC

Hi Yaakov,

A bit off-topic, but there is a better solution for bug c++/56742.
See recent attachment to this PR on gcc's bz for the patch. It
deprecates my patch to config/i386/i386.c about this subject.

Kai

Kai Tietz

2013-05-23 09:58:31 UTC

Post by Corinna Vinschen
Hi Yaakov,
A bit off-topic, but there is a better solution for bug c++/56742.
See recent attachment to this PR on gcc's bz for the patch. It
deprecates my patch to config/i386/i386.c about this subject.
Kai

A link to that problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742

Kai

Yaakov (Cygwin/X)

2013-05-27 06:11:33 UTC

Post by Kai Tietz
A bit off-topic, but there is a better solution for bug c++/56742.
See recent attachment to this PR on gcc's bz for the patch. It
deprecates my patch to config/i386/i386.c about this subject.

Queued for 4.8.1.

Yaakov

Corinna Vinschen

2013-05-23 08:46:16 UTC

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?

No, I haven't had time to look into it.

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?

e.g. running gtk-demo (from the gtk2.0-demo package).

And what kind of action will trigger the SEGV?

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Yaakov (Cygwin/X)

2013-05-27 02:30:59 UTC

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?

e.g. running gtk-demo (from the gtk2.0-demo package).

And what kind of action will trigger the SEGV?

For me it SEGV'd upon launch.

Yaakov

Corinna Vinschen

2013-05-27 09:43:43 UTC

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?

e.g. running gtk-demo (from the gtk2.0-demo package).

And what kind of action will trigger the SEGV?

For me it SEGV'd upon launch.

Conmfirmed :(

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Corinna Vinschen

2013-05-27 09:53:05 UTC

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?

e.g. running gtk-demo (from the gtk2.0-demo package).

And what kind of action will trigger the SEGV?

For me it SEGV'd upon launch.

Conmfirmed :(

And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

marco atzeri

2013-05-27 10:22:19 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

Post by Corinna Vinschen
Corinna

Marco

Corinna Vinschen

2013-05-27 10:42:15 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

marco atzeri

2013-05-27 10:59:09 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

Post by Corinna Vinschen
Corinna

Corinna Vinschen

2013-05-27 11:15:19 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

marco atzeri

2013-05-27 12:49:40 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

default -mcmodel=medium

Slang is a small library and the failure is
during "make check" when UTF8 is not used

http://mailman.jedsoft.org/pipermail/slang-users-l/2013/000788.html

about the test, I need to look, but I will wait after 4.8.1

Post by Corinna Vinschen
Corinna

Marco

Corinna Vinschen

2013-05-27 13:22:08 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

default -mcmodel=medium
Slang is a small library and the failure is
during "make check" when UTF8 is not used
http://mailman.jedsoft.org/pipermail/slang-users-l/2013/000788.html

Hmm. For some reason that reminds me of the problem we had with the
localtime changes two weeks ago. Just out of curiosity, would you mind
to try an optimized build again, but this time add the -fwrapv option?

Post by Corinna Vinschen
about the test, I need to look, but I will wait after 4.8.1

Sure, that's fine.

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

marco atzeri

2013-05-27 14:39:52 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

default -mcmodel=medium
Slang is a small library and the failure is
during "make check" when UTF8 is not used
http://mailman.jedsoft.org/pipermail/slang-users-l/2013/000788.html

it works, thanks

Post by Corinna Vinschen
about the test, I need to look, but I will wait after 4.8.1

Sure, that's fine.
Thanks,
Corinna

Corinna Vinschen

2013-05-27 14:57:32 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

default -mcmodel=medium
Slang is a small library and the failure is
during "make check" when UTF8 is not used
http://mailman.jedsoft.org/pipermail/slang-users-l/2013/000788.html

it works, thanks

Wow, I haven't actually believed this would help. Given it's apparent
dangerousness, wouldn't it make sense to enable the -fwrapv option (or,
FWIW, disabling the -fstrict-overflow option) by default with -O2, at
least on x86_64?

Kai? Yaakov?

Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Ryan Johnson

2013-05-27 15:09:33 UTC

Post by Corinna Vinschen
And worse, the problem goes away when building without optimization.
There might be another GCC bug lurking in the background...

Probably there is more than one.
I hit a gcc-4.8 optimization bug testing slang, the workaround
was to build the 64 bit package without any optimization.

slang is written in c++?

in C

And you built it with the default -mcmodel=medium, I assume. Well,
it's not that gcc would be entirely bug free and 4.8.1 is lurking
around the corner already. Any chance to create a simple testcase?

default -mcmodel=medium
Slang is a small library and the failure is
during "make check" when UTF8 is not used
http://mailman.jedsoft.org/pipermail/slang-users-l/2013/000788.html

it works, thanks

I guess lots of folks assume two's complement wraparound for signed
ints, even though the standard says it's undefined? I guess this is
destined to turn out like -fstrict-aliasing... when in doubt, disable it.

Ryan

Yaakov (Cygwin/X)

2013-06-03 05:00:51 UTC

Post by Yaakov (Cygwin/X)
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.

WRT gtk3, the culprit was actually an apparent LTO bug in
libcairo-gobject (a thin GObject wrapper for libcairo which gtk2.0 does
not use); any call to CAIRO_GOBJECT_TYPE_* seems to go to la-la land and
SEGV. Recompiling libcairo-gobject without -flto allows gtk3 to work.
(Strangely enough, the much larger libcairo itself seems to work even
with -flto.) As for fixing LTO, well, that will have to be a different
discussion; at least we can move forward again with the GNOME stack.

Yaakov

Corinna Vinschen

2013-06-03 08:08:36 UTC

Post by Yaakov (Cygwin/X)
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.

WRT gtk3, the culprit was actually an apparent LTO bug in
libcairo-gobject (a thin GObject wrapper for libcairo which gtk2.0
does not use); any call to CAIRO_GOBJECT_TYPE_* seems to go to la-la
land and SEGV. Recompiling libcairo-gobject without -flto allows
gtk3 to work. (Strangely enough, the much larger libcairo itself
seems to work even with -flto.) As for fixing LTO, well, that will
have to be a different discussion; at least we can move forward
again with the GNOME stack.

I'm glad to read that.

Thanks,
Corinna

--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Corinna Vinschen

2013-06-04 13:51:49 UTC