Theres probably another way to do it (I know @theuni wanted to build with different flags for release, but it would be good to at least fix build).

We discussed this on IRC. I don't think -fPIC should be the default, for executables -fPIE is superior option. See e.g. http://www.openbsd.org/papers/nycbsdcon08-pie/

Though I'm fine with enabling it as a fallback if you can add a check to autoconf that PIE is broken on a platform.

Many distros force PIC anyway, so this actually wont change anything for most builds.

After researching the issue some over the weekend, I agree with @laanwj.

To clarify, this is an issue with gcc5 and newer clang+lto when qt is built with -reduce-relocations. Upstream GCC discussion is here.

We have a few options:

• Do nothing. I think I'd prefer this, reasoning below.
• use -PIC instead for known-problematic compilers. This would mean maintaining a black-list since I don't believe this can be easily tested.
• Use -PIC instead only when building bitcoin-qt and using a problematic compiler and when qt was built with -reduce-relocations (this can be tested via preprocessor).
• Default to -PIC everywhere and override with -PIE when creating release binaries.

2 and 3 would be necessary only for building bitcoin-qt, but we'd end up having to disable PIE for bitcoind as well, to avoid building 2 sets of objects.

I believe that the root issue here is that distros are shipping qt libs with -reduce-relocations, which is known to violate abi specs and makes assumptions about how downstreams will use their libs. That abi spec violation became a real-world issue with the latest compilers.

So IMO, the more reasonable thing to do here would be to try to convince Arch to disable -reduce-relocations for their qt build. We can't be the only downstream with this issue.

OK, @theuni I filed a bug at https://bugs.archlinux.org/task/45283 lets see what the maintainers there say.

@cfields I'm ok with all those options, except "Default to -PIC everywhere and override with -PIE when creating release binaries." Let's not have everyone suffer because a distro builds libraries with broken options.
Either we work around this specific case when it happens, or we do nothing and have Arch users provide an extra option as workaround (could be documented in build_unix.md).
Would be even better if the problem could just be solved upstream.

@cfields would you mind discussing with the arch maintainer @ https://bugs.archlinux.org/task/45283#comment136231 ?

On June 9, 2015 11:06:00 PM PDT, "Wladimir J. van der Laan" [email protected] wrote:

@cfields I'm ok with all those options, except "Default to -PIC
everywhere and override with -PIE when creating release binaries."
Let's not have everyone suffer because a distro builds libraries with
broken options.
Either we work around this specific case when it happens, or we do
nothing and have Arch users provide an extra option as workaround
(could be documented in build_unix.md).
Would be even better if the problem could just be solved upstream.

---

Reply to this email directly or view it on GitHub:
#6248 (comment)

This issue is present on Fedora 22 as well.

I have a fix for this in the works. I'll try to push it up in the next few days.

Arch changed their build settings and this is no longer an issue there, is it still on Fedora? Can we file a bug there? @dankeder

Yes, the problem is still present on F22:

In my bitcoin repo (checkout tag v0.10.2):

$ ./configure --prefix=/home/dan/programs/bitcoin-0.10.2 --with-gui=qt5 --with-pic --disable-shared --disable-tests
(...)
$ make                     
Making all in src
make[1]: Entering directory '/home/dan/tmp/src/bitcoin/src'
make[2]: Entering directory '/home/dan/tmp/src/bitcoin/src'
  CXX      qt/qt_bitcoin_qt-bitcoin.o
In file included from /usr/include/qt5/QtGui/qwindowdefs.h:37:0,
                 from /usr/include/qt5/QtWidgets/qwidget.h:37,
                 from /usr/include/qt5/QtWidgets/qframe.h:37,
                 from /usr/include/qt5/QtWidgets/qlabel.h:37,
                 from /usr/include/qt5/QtWidgets/QLabel:1,
                 from qt/bitcoingui.h:14,
                 from qt/bitcoin.cpp:9:
/usr/include/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. "\
    ^
Makefile:5494: recipe for target 'qt/qt_bitcoin_qt-bitcoin.o' failed
make[2]: *** [qt/qt_bitcoin_qt-bitcoin.o] Error 1
make[2]: Leaving directory '/home/dan/tmp/src/bitcoin/src'
Makefile:6246: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/dan/tmp/src/bitcoin/src'
Makefile:568: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

I have these QT5 packages:

$ rpm -qa | grep qt5-qtbase 
qt5-qtbase-gui-5.4.2-2.fc22.x86_64
qt5-qtbase-5.4.2-2.fc22.x86_64
qt5-qtbase-devel-5.4.2-2.fc22.x86_64
qt5-qtbase-common-5.4.2-2.fc22.noarch

I'm unsure what to do here. I have a rather complicated patch that changes around the PIC flags for qt objects if it was built with -reduce-locations, but since Arch elected to quit doing that, I'm somewhat hopeful that we can lobby the other distros to do the same. That really is the correct fix.

I asked a friend who is a contributor to the Fedora Project what he thinks about this issue.

His opinion is that bitcoin build logic shouldn't set compiler options on its own, it should rather make use of qmake to get the flags of the particular platform. Also, it seems that -fPIC is set as the default directly in qt build scripts. So if you think that the flags need to be changed, they should be changed upstream, not in each and every Linux distribution that has this problem.

We're setting custom compiler options because of --enable-hardening, which sets some (relatively) obscure options to improve worst-case security. With --disable-hardening this problem it just uses the suggested flags and I don't think this problem exists.

I do like having hardening enabled by default, though. @theuni Can we add a test to configure that detects this problem, and disables or falls back to other options if it fails?

Well, reviewing PIE vs. PIC, no immediate security issue jumps out (via hardening) at the introduction of PIC. It's just a bit slower. Capturing the flags from qmake seems reasonable?

Building with PIC instead of PIE means the Address Space Layout Randomization & features from Grsecurity / PaX are less effective.

In Alpine Linux qt5 is built with -no-reduce-relocations &bitcoin / bitcoin-qt are still built with -fPIE

Use -PIC instead only when building bitcoin-qt and using a problematic compiler and when qt was built with -reduce-relocations (this can be tested via preprocessor).

Right, detecting this would be the right way to solve this. Although the logic is quite ugly, it's not that much worse than other auto* checks.

And agree it would be even better if -reduce-relocations was not provided to the Qt build upstream. That's the root issue, not PIE versus PIC.

Still NACK on setting -fPIC by default, so going to close this.

Bleh, getting the same on Ubuntu 15.10 now.
Seems a lot of distributions are compiling Qt with that awful option.
We do need to detect it somehow in configure.

@theuni can you take a look at this?

Closing in favor of #6978