Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdEoP-00044z-Ug for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:15:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.182 as permitted sender) client-ip=209.85.160.182; envelope-from=wtogami@gmail.com; helo=mail-yk0-f182.google.com; Received: from mail-yk0-f182.google.com ([209.85.160.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdEoP-0004GS-2Z for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 08:15:17 +0000 Received: by mail-yk0-f182.google.com with SMTP id 142so1769941ykq.13 for ; Thu, 24 Apr 2014 01:15:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.207.194 with SMTP id n42mr336470yho.153.1398327311507; Thu, 24 Apr 2014 01:15:11 -0700 (PDT) Received: by 10.170.58.146 with HTTP; Thu, 24 Apr 2014 01:15:11 -0700 (PDT) In-Reply-To: References: <53581D1D.1000709@gmail.com> Date: Wed, 23 Apr 2014 22:15:11 -1000 Message-ID: From: "Warren Togami Jr." To: Wladimir Content-Type: multipart/alternative; boundary=089e0163387aaea7fb04f7c572bd X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (wtogami[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WdEoP-0004GS-2Z Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:15:18 -0000 --089e0163387aaea7fb04f7c572bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2014 at 10:02 PM, Wladimir wrote: > On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell > wrote: > > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. > 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=E2=80=94 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 --089e0163387aaea7fb04f7c572bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj@gmail.com> wro= te:
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=E2=80=94 tal= ks 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. =C2=A0Lucid has qt-4.6.2.

<= div>It is more than one symbol. =C2=A0It does not seem to be a wise thing t= o replace functions beyond the trivial in glibc and libstdc++.

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

Warren

--089e0163387aaea7fb04f7c572bd--