linker issue with 1.7.6 release

[pnemade]

Just reporting here in case anyone knows solution for this issue.
1.7.5 release is building fine for Fedora 27 but the 1.7.6 release introduced something that is causing linker error.
e.g. See this failed build log -> https://kojipkgs.fedoraproject.org//work/tasks/9948/25659948/build.log

few lines from log given below

libtool: link: DIE_RPATH_DIE="/usr/lib64:" gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -Wl,-z -Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Bsymbolic-functions -o .libs/test-subset-hmtx test-subset-hmtx.o  ../../src/.libs/libharfbuzz.so -lglib-2.0 ../../src/.libs/libharfbuzz-subset.so
make[3]: *** [Makefile:896: test-shape] Error 1
../../src/.libs/libharfbuzz.so: undefined reference to `__gxx_personality_v0'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:876: test-object] Error 1

[ebraminio]

/usr/lib/rpm/redhat/redhat-hardened-cc1 is in your command and -fexceptions is explicitly stated, hmmm. I guess you need to build harfbuzz with --with-libstdc++.

[pnemade]

Okay. I also read CMakeLists.txt and found that switch. Let me check if build passes with that switch.

[ebraminio]

Oh, it is for autotools already and is defined here, you should pass it either to ./autogen.sh or ./configure. But you are right, the no-exception was used to be applied globally to the project but on 1.7.6 and it is just passed to certain objects, I wonder however why no one, even our dear fedora bot doesn't complain about the situation and passes the tests also, perhaps it has something to do with redhat-hardened-cc1. We like to improve the situation if we know what is exact steps to reproduce this.

[behdad]

That's weird. Can you check the link / compile commands across the two version and see what changed? We didn't intend to change how libharfbuzz.so is built. Using --with-libstdc++ is NOT the solution.

[behdad]

But you are right, the no-exception was used to be applied globally to the project but on 1.7.6 and it is just passed to certain objects,

Is it? At least in master, my reading is that it applies to everything.

[pnemade]

I asked help to Florian but could not able to get his reply on downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1552962

I still have not officially built the new update in Fedora yet.

[behdad]

I tried a fix. Please let me know if it fixes and I'll roll a new release. Thanks.

[pnemade]

I am still getting linker error with the current snapshot of this project code.
See https://koji.fedoraproject.org/koji/taskinfo?taskID=25995018
and failure is still same

libtool: link: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -Wl,-z -Wl,relro -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Bsymbolic-functions -o .libs/test-blob test-blob.o  ../../src/.libs/libharfbuzz.so -lm -lfreetype -lgraphite2 -lglib-2.0
../../src/.libs/libharfbuzz.so: undefined reference to `__gxx_personality_v0'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:923: test-shape] Error 1

Maybe above should use g++ and not gcc to link as suggested in downstream bug?

[behdad]

Why is there -fexceptions in there? That's the problem.

[behdad]

Also, our CXXFLAGS are missing. I wonder where they went. This looks very suspicious. What command is used to configure?

[behdad]

Humm. I don't see them when I try here either. Let me debug.

[behdad]

I take that back. I see them here. I see -fno-exceptions -fno-threadsafe-statics -fno-rtti in my compile commands, as we expect. We have to figure out why you don't.

[behdad]

Humm. Ok, you don't see because this is compiling a C source file.

Still, question is why do we have -fexceptions there. Apparently your build system has added it. How did that work before, I don't know.

[ebraminio]

Still, question is why do we have -fexceptions there. Apparently your build system has added it. How did that work before, I don't know.

That's why I asked they should test it with --with-stdc++ #880 (comment) (as a starting point) I guess the way it was used to work before was having -fexception which was reverted by -fno-exception (or the reverse way) on the same command. Don't get me right, I just don't like to touch stdc++ related things anymore... (specially as you want to revert the whole thing on #936)

Of course I don't know also how it used to work as it is a C file, maybe CXXFLAGS was leaked to CFLAGS there but that shouldn't work AFAIK...