1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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 <wtogami@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CA+s+GJDY6c2-fjbL=JcrF3umM4ji8Y5j5ppxX_mAzZdTh1_QRw@mail.gmail.com>
References: <CAEz79PrAg=yydd3UOk51wGQUWey-KZHUH1Npzwb=qL+6zTj+pQ@mail.gmail.com>
<53581D1D.1000709@gmail.com>
<CAEz79Poy0XEVyC=nOdhYNVOASvfB-2zHJcjU2hvjA7iDWGDDyw@mail.gmail.com>
<CAAS2fgSQ6rh1XKao6pv8BmpeRbtqWfUOVF+C1Fi3LEzY1YcPiA@mail.gmail.com>
<CA+s+GJDY6c2-fjbL=JcrF3umM4ji8Y5j5ppxX_mAzZdTh1_QRw@mail.gmail.com>
Date: Wed, 23 Apr 2014 22:15:11 -1000
Message-ID: <CAEz79PqoWOUEwrsaaHjX58QqYbFUdS6k5jg2V9XvOAAUBw00Ug@mail.gmail.com>
From: "Warren Togami Jr." <wtogami@gmail.com>
To: Wladimir <laanwj@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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=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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 23, 2014 at 10:02 PM, Wladimir <span dir=3D"ltr"><<a href=3D"mai=
lto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div class=3D"">On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <<a hr=
ef=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> wrote:<br>
> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <<a href=3D"mail=
to:wtogami@gmail.com">wtogami@gmail.com</a>> wrote:<br>
>> If you are<br>
>> a rare user who needs Bitcoin-Qt on an incompatible system you can=
at least<br>
>> build it from source.<br>
><br>
> Tails users usually can't really build it from source=E2=80=94 tal=
ks is a live<br>
> boot mostly stateless linux distribution for privacy applications.<br>
> It's really good in general.<br>
<br>
</div>Aside: But is Bitcoin Core a well-suited application for those uses? =
I<br>
cannot imagine someone running a full node on a stateless system.<br>
<br>
Anyhow: As this is only one symbol, we can probably get rid of it (as<br>
we didn't use it in 0.8.6?), or put it behind some #ifdef<br>
COMPATIBILITY_BUILD...<br>
<br>
Another option: Instead of statically building it'd be easy enough to<b=
r>
build against the 4.6 Qt headers instead without even swapping the<br>
library. Qt is, after all, forward-compatible - between the 4.x<br>
versions. This will lose some GUI features but if compatibility is<br>
more important here that's a choice that can be made.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Wladimir<br></font></span></blockquote><div><br></div><div>I now see how it=
worked with Bitcoin 0.8.6. =C2=A0Lucid has qt-4.6.2.</div><div><br></div><=
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++.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Warren</div></div><br></div></div>
--089e0163387aaea7fb04f7c572bd--
|
