Warren Togami Jr. [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-24 📝 Original message:On Wed, Apr 23, 2014 at ...
📅 Original date posted:2014-04-24
📝 Original message:On Wed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj at gmail.com> wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/feeeee08/attachment.html>;
📝 Original message:On Wed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj at gmail.com> wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/feeeee08/attachment.html>;