Autoconf fixes #2979

No description provided.

https://github.com/wtogami/bitcoin/commit/aa176a07374f456b9e3a3c030f5ea8fe475a9984 Please add libdb4 to the db4 search paths.

Please also search for lrelease-qt4 and lrelease-qt5 instead of just lrelease.

"configure: Prefer specific known-good versions of Qt metacompiler tools"

Please add the -qt5 equivalents after the -qt4. It works for me if I completely remove the qt4 headers and tools. Yes, it needs more work so it isn't confused when both are installed.

@wtogami Qt5 support can be something for a future pull request. As long as it doesn't build correctly (I don't think having to remove Qt4 counts), configure should fail.

Nice improvements to the configure script! When trying the current master, I found that ./configure --enable-hardening would not build unless I added -fPIC option to CXXFLAGS. Should the configure script be made aware of this, and automatically add -fPIC if needed? Or is this just a local symptom of some bug/misconfiguration on my system, and so wouldn't be needed by anybody else?

We should be enable hardening all the time, with an AC test to make sure the hardening flags work, and whining at you if they don't.

ACK on the BDB changes, though I've not tested yet.

I also wondered why that wasn't already the default, as it seems like a good idea. Perhaps --disable-hardening for those who explicitly wish to disable hardening for whatever reason (old build tools, debugging, etc.)?

If your build tools are that old, your OS likely lacks dependencies needed by Bitcoin anyway. For now please focus on getting this to build on all common operating systems, every typical variant of Linux, and all gitian targets.

I strongly recommend two more "fixes" in order to prevent confusion and many useless bug reports from hundreds of future builders.

1. Automatically remove the old leveldb.a from pre-autotools builds. If necessary name the new target something else so it is easy to distinguish the old leveldb.a from new.
2. Automatically remove the old bitcoind, or print something at the end of each frontend build where the binary is located. Right now it is easy to mistake the old bitcoind in the base directory as the output.

@wtogami The proposed solutions are largely an artifact of transitional code. New checkouts should not see the problem, and pre-autotools builds will quickly plunge in frequency, in a few months after release.

Seems like an issue for release notes, something easily grep-able and google-able for people finding common pre->autotools transition issues.

Speaking of release notes, an easy documentation bug to fix.

In doc/build-unix.md where it says CXXFLAGS="-i/usr/include/db4.8"

The -i should be -I (capital I, as in India).

I feel like i now never could contribute again to compiler switches, hardening or whatever. That autotools stuff looks like magic an I miss my .pro file ^^. I have yet to try builing bitcoin-qt with this.

I whish Qt5 support is working as I don't use Qt4 anymore.

@Diapolo The secret of autotools is that no one else in the world understands it either. Really you just randomly poke at it until it works. Once you've done this long enough everyone will assume that you actually know what you're doing, and you can smirk quietly and carry on the great secret. :)

Don't worry, if you get stuck everyone will help you. Autotools is like a big hazing as part of the initiation into the free software brotherhood. At conferences we all sit around over beer griping about how much autotools stinks. :)

<gmaxwell> ... this is being compiled without optimization 0_o <warren> gmaxwell: yeah, I complained about that. -O1 is needed at least for hardening to work <warren> gmaxwell: our old default was -O2 right?
<gmaxwell> we absolutely shouldn't be compiling with just O1. <gmaxwell> right.

@Krellan Programs are not supposed to be built with -fPIC (it's for shared libraries only), so I'm not sure where your problem is coming from. I'll make a note to remove the CXXFLAGS from build-unix.md (it's no longer necessary). @wtogami bitcoind was never built in the base directory, so the location is already the same.

@luke-jr Oops, I meant bitcoin-qt.

@luke-jr As for -fPIC, nonetheless, it seems to be required. Can you compile on your system with --enable-hardening without adding -fPIC? I can't, without getting the error message about relocation and the reminder to use -fPIC. With ASLR hardening, the address space is randomized, so position-independent code would already be a necessity, right?

On my system, a hardened executable shows up as "shared object" (ET_DYN) instead of "executable" (ET_EXEC) in the file and scanelf -e commands respectively. So, although -fPIC is for shared libraries only, as you said and I agree with, maybe a hardened executable counts as a shared library for this purpose?

Does it work with -fPIE (and not -fPIC)? That's what some hardening systems use (I don't know what --enable-hardening is supposed to do)

Perhaps a hardened executable requires a randomized address space, rather than compiler-chosen static offsets.

NACK. Breaks on my macports/OSX machine:

checking for db_version in -ldb_cxx-4.8... no checking for db_version in -ldb_cxx... no configure: error: libdb_cxx missing

Compare with master:

checking db_cxx.h usability... yes checking db_cxx.h presence... yes checking for db_cxx.h... yes checking for main in -ldb_cxx... yes

Please hold off on these for a day or two, I have portability concerns with many of them. I'll be back in the office on Mon/Tues.

Hardening should be on by default already, the help string is just backwards.

@Diapolo: I have patches for enabling qt5, and it builds fine. But I excluded it from the initial autotools pull to avoid overcomplicating it.

I'd like to point out that I made a big effort to make this functionally the same as the old build (I'm not claiming that I succeeded, far from it I'm sure). But the old build was very static and manual, so new options open up now that users can easily configure the build.

If the behavior doesn't make sense, let's fix the core issues. For example, the old system had a notion of debug/release builds, and hardened/unhardened builds. I tried to match those for the sake of feature-parity, but that's not to say they make sense anymore. I'd prefer to have a good discussion/debate about what actually needs to be configurable, and what are sane defaults.

Hardening definitely requires some form of position independent executable, for address space randomization. And I think PIE only applies to libraries. Not sure tho, the difference between PIE/PIC is a bit hazy to me.

I agree that we should harmonize hardening options and review them for all OSes. Also there is still my old pull I remember, which activates -fstack-protector-all for Windows, which never worked because of our ancient compiler suite. Shouldn't we now switch to something newer in order to allow this for Windows builds also? Maybe we can now also start looking in hardening our used libs?

I'm looking forward to your Qt5 fixes :) and would suggest we also start looking into dependency lib versins, as some are rather out of date and may contain serious bugs or security issues!?

Is the mingw Ubuntu 12 toolchain new enough?

hardening flags can be seen here: https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L296

For the most part, each one is tested and applied wherever possible, to avoid the need to specify per-toolchain.

@wtogami yes,the mingw-w64 (don't mind the name, it's for 32 bit as well) cross compilation stuff in Ubuntu 12.04 is new enough for hardened builds (w/ stack-protector-all) to work correctly on Windows.

ACK.

ACK. Builds for me now.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1e9d3b1392b604fafc6802e4d43469f519d14424 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

This seems to lack -O by default. gmaxwell says it will probably be in the next pull though.

Yep, it's part of my autoconf_pt2 branch (out of 4).