On Wed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj@gmail.com> wrote:

> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami@gmail.com>
> wrote:
> >> If you are
> >> a rare user who needs Bitcoin-Qt on an incompatible system you can at
> least
> >> build it from source.
> >
> > Tails users usually can't really build it from source— talks is a live
> > boot mostly stateless linux distribution for privacy applications.
> > It's really good in general.
>
> Aside: But is Bitcoin Core a well-suited application for those uses? I
> cannot imagine someone running a full node on a stateless system.
>
> Anyhow: As this is only one symbol, we can probably get rid of it (as
> we didn't use it in 0.8.6?), or put it behind some #ifdef
> COMPATIBILITY_BUILD...
>
> Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.
>
> Wladimir
>

I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.

It is more than one symbol.  It does not seem to be a wise thing to replace
functions beyond the trivial in glibc and libstdc++.

I personally think we need to decide upon a cut-off point beyond which it
makes no sense to add the risk of increased complexity.  RHEL6 had qt-4.6.2
as well and I don't think I've heard a single complaint about bitcoin-qt
being broken there given almost nobody uses it as a desktop.

Warren