Great work, utACK (will test later)

Thanks, Concept ACK.

Can confirm default settings ($ ./autogen.sh ;./configure ;make) work again with 69d0513 on latest fedora. (You may want to put "closes #6248" in the OP)

Nice! utACK.
Gitian build for all three platform works: https://bitcoin.jonasschnelli.ch/pulls/6978/

On Ubuntu 15.10 this gives:

checking whether -fPIE can be used with this Qt config... no

Which is correct. However on On Ubuntu 14.04 I also get:

checking whether -fPIE can be used with this Qt config... no

While I know in fact that that does work. Error in config.log is:

configure:23385: g++ -c -fPIE -g -O2 -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wno-self-assign -I/usr/include/qt5/QtCore -I/usr/include/qt5 -I/usr/include/qt5/QtGui -I/usr/include/qt5/QtNetwork -I/usr/include/qt5/QtWidgets    -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:67:15: error: 'choke' was not declared in this scope
               choke;
               ^
At global scope:

Strange. QT_REDUCE_RELOCATIONS is indeed enabled:

./qt5/QtCore/qconfig.h:#define QT_REDUCE_RELOCATIONS

However it just works with fPIE. Gcc version issue?

@laanwj I believe it's a Qt issue. They tightened the requirements with newer qt versions, -fPIE used to compile fine. But -fPIE + gcc5 + older Qt will still likely cause problems regardless if it does compile.

So the real issue is -fPIE + newer gcc regardless of when qt tightened the error. I think it makes sense to always fall back to -fPIC any time that reduce_relocations was used. The alternative would be a blacklist/whitelist for compilers, which i was trying to avoid.

Wouldn't compiling+linking an example program w/ -fPIE and Qt be the most sure way to check? Or is there a specific reason you didn't go that route?

@laanwj It compiles/links fine with the busted config. So there's no point in linking if we're not going to run it, and a run-test is a no-go because it doesn't work with cross.

The alternative would be compiling a stub object with fPIE and objdump to check for relocations.

Huh are we talking about the same issue?
On at least ubuntu 15.10 this fPIE/freduced-relocations conflict causes a build-time issue, not a run-time isue.

This is the error I get (one for every executable that uses qt):

In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:37:0,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:41,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:40,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QObject:1,
                 from qt/test/uritests.h:8,
                 from qt/test/test_main.cpp:10:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
    ^

@laanwj Sorry for being unclear. To summarize the issue:

Qt build can enable -Bsymbolic-functions via the reduce-relocations config option. The qt devs assumed that -fPIC or -fPIE would disable copy-relocations, but gcc5 changed that behavior and allows copy-relocs with -fPIE. So -fPIC is the only way to guarantee that -Bsymbolic-functions will work as intended.

Source: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886#c16

When Qt discovered this issue (somewhere around 5.4), they added the check in qconfig.h so that compilation would fail in this QT_REDUCE_RELOCATIONS+-fPIE case. Prior to that, the check looked like this:

#if !defined(QT_BOOTSTRAPPED) && defined(QT_REDUCE_RELOCATIONS) && defined(__ELF__) && !defined(__PIC__) && !defined(__PIE__)
#  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
         "Compile your code with -fPIC or -fPIE."
#endif

Just because compiling succeeds in versions with the old check, that does not mean that it's safe to build/run with gcc5+. So testing to see if something builds against qt+-fPIE is not enough, as older versions weren't aware of the problem.

Ok, fair enough

Tested ACK.

pardon me for necroing this thread but if -fPIC weakens PaX/Grsec patches then i wonder if silently using it as a fallback option is the right way to solve this.
maybe a clear warning can be shown and more effort undertaken to convince upstream or package maintainers to ship Qt without reduce-relocations?