FYI Bitcoin is now running fine again, after a reboot from another Windows Update.

Ok good to know others are able to run it ok.

Unfortunately bitcoin is not a critical application for me and need to spend my time on other things.  If however there is a debugging build of the application which can provide line numbers for the crashed code (0xc0000005 - ACCESS VIOLATION) then I'd be happy to run it to identify the line causing the problem.

Have tried turning off Windows Defender, Real Time checking and excluding "C:\Program Files (x86)\bitcoin" but this made no difference.

As another recent thread indicates their problem was fixed or potential solution in this way.



This thread below is the closest match.  I can say the crash started the moment I rebooted after October 2010 patch Tuesday, windows update (which were only applied a few days ago).

http://bitcointalk.org/index.php?topic=991.0

FYI - I was not overclocking or otherwise buggering about with anything in ways I'm not meant to.  Which the above thread OP claims to have done.  Also My Wallet.dat looks fine, none of the AppRoaming files have been modified since I rebooted after installing the 23 updates all in one go.

This is from 0.3.14-win32-setup.exe.  Previously I was running (up until an hour ago) a version of bitcoin.exe from Jul-2010 (which also was crashing) and the crash reports look similar.  So I upgraded to see if the problem has been fixed.

To clarify what I am saying any starting of the EXE immediately reports the crash.  So when I login I see the Win7 crash report and if I manually try to start it the same.  The dialog beyond the crash report is "The application was unable to start correctly (0xc0000005).  Click OK to close the application."

Please also try to tag the application .EXE with the version information if possible, as you can see it is 0.0.0.0.

This is irrelevant to finding memory leaks.  (humour)

Yes understood on ECDSA use (and Fedora patent policy), this is a seperate matter and not the question you asked.

Your original query was over "running" bitcoin not "building".  Hence the reply from me relating to running (and hence my humour comment).

No its a breaking DSO major version change.  The problem with Fedora is that it cuts backward compatibility ASAP, where as for RHEL/CentOS there would be compat-openssl providing the libraries you need.

# Maybe look at
yum search crypto | egrep -i "(ssl|crypto)"

# Shot in the dark.
yum install compat-openssl

I only have Fedora12 (been advised to say away from 13, maybe its unlucky!)


Hopefully I can have an OBS build up at https://build.opensuse.org/project/packages?project=home%3Adlmiles over the weekend.  This should allow a native Fedora build to exist.

Please cite exactly which library is using which feature of very recent glibc version (or any library for that matter) ?  (just so we can all understand the problem in the way you state).


From what I can see wxWidgets and boost are linked statically.  I guess this is due to the "build against very specific versions of its dependent libs".  But from what I can see there is _NO_ need for either of thes libraries to use a recent glibc, wxWidgets for example only has a check for glibc 2.1 or newer (during its ./configure).  But it is not clear which features of wxWidgets 2.9.0 and/or boost 1.40.0 require the use of a glibc say above version 2.5 (which is also pretty old, but pretty compatibile).  I have sucessfully been able to build these versions (of wxWidgets/boost) against glibc 2.5.

I believe this can be confirmed by the use of -Bstatic in "src/makefile.unix".


The only reason that glibc is a "compatibility worry" (as you put it) is because the project was build on a very new linux system.  This forces all the downloaders to have as-new-a linux system as the build system in order to run it.  This is not because there is some intrinsic compatibility worry as you describe it.


I think I have created a custom wxWidgets 2.9.x build on OpenSUSE build service (OBS).  I shall have a go with "boost" over the new few hours if all goes well.  Then I can commit bitcoind package and get openSuSE builds.  Then I can enable other distribution repos (CentOS, Ubuntu, SLE, Fedora, etc...).

Can anyone confirm if boost "1.40.0" is needed or just "1.40.0 or newer" ?  since 1.42.x is current (and that is already available for a number of platforms as packages).  Can anyone explain the story behind this matter.

With wxWidgets 2.9.x is a development series so it is pre-release, so that is clear cut that a custom version needs to be built to get access to pre-release versions.  But this problem I have solved in an OBS build.

Google found me http://virtualboxes.org/images/ubuntu/

Maybe head for item 3 for http://downloads.sourceforge.net/virtualboximage/ubuntu-8.04-x86.7z (505Mb download, for a 2.67Gb uncompressed image)

Just to clear up any (potential) misconception, from the use of the phrase "for older distro support".  Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way.

When they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries.  Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC.


I am somewhat asserting that, if it is indeed possible to compile with older versions (because the features the newer versions add are not actually required by the application) then this version that should be made available via a single binary download (since it will work with the widest audience).


Also to repeat, that the OpenSUSE Build Service is like a remote virtualized service which you can use compile your application on multiple major distributions and the output is a bunch of packages tailored to suit each distro.


The clear problem I see is not with the support for aux lbiraries (Xlib,GTK+,OpenSSL,freetype) but with basic GLIBC and GCC libstdc++.  The problem with this is that you can't expect to simply place the DLLs you need in the same directory as the bitcoin executable and fix up LD_LIBRARY_PATH (man ld.so) so it can see them.

For example lets say that it was compiled with an older GTK+ than is available for your distribution of choice (a DSO major release change, this is indicated in the 2nd "0" in the /usr/lib{,64}/libgtk+-x11-2.0.so.0.1800.9) - note it is still zero, this indicates long term stability re-backward compatibility.  Well it is possible to easily fix this problem without installing the libraries by fixing them up with LD_LIBRARY_PATH.  But for glibc solving the problem in this way is not so straightforward.

Fair enough.  I've not found any version of bitcoin that works with any enterprise version of Linux I have found.  Often enterprise linux uses older tried and trusted versions several years old.  This has parity with the LTS series of Ubuntu.

I think you'd be better doing your distribution with http://releases.ubuntu.com/hardy/  (8.04.4 LTS Hardy Heron).  If you really must use Ubuntu.  This being the _PREVIOUS_ release of their LTS series, once 10.4 LTS passes the 18months old test consider a release engineering rebase.

Maybe you can setup a 2Gb "8.04.4 LTS" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use.

dpkg -l | egrep "(libc6|glibc)"
# This will display what version you currently have installed

# I guess you have glibc version 2.10 or older installed.

apt-get update
apt-cache showpkg libc6 | less
# Look (near the bottom) for the versions available for a 2.11 version

#Maybe you can just upgrade with:
apt-get upgrade libc6


# Above instruction for a real debian system, they might work with Ubuntu

Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.

Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.

Sorry to post to my own post.


One possible solution would be to create a project on the OpenSUSE OBS platform http://wiki.meego.com/Build_Infrastructure .

This platform is an auto-builder anyone can use (by creating your own account and home area).

You can upload your project and *.spec (build descriptor) and it will build your distribution in the format of all the leading Linux distributions (OpenSUSE, CentOS/RHEL, Fedora, Ubuntu, ...).  So there is no need for you to maintain them seperately it will do that for you.

The result will be a *.deb or *.rpm or whatever your platform uses.

It is because the system the lead developer is using is probably "bleeding edge" (as in very new, very recent, very uptodate).  This is not a system that should be used to build something aimed to be redistributable to the widest audience.

Please see some potential improvements in my thread http://bitcointalk.org/index.php?topic=612.0


Do the Windows and MacOS binary downloads come without these respective libraries (re boost/wxWidgets) ?   The Linux specific parts such as glibc and GCC toolchain to use the LGPL for the runtime redistributable components.  I believe the X11 library parts to be MIT.  I believe the GTK+ to be LGPL.  Freetype is LGPL (and/or BSD like).  Expat is LGPL.  OpenSSL is BSD+Notice (although you already know that from your credits).

Looking through the list "ldd bin/{32,64}/bitcoin" I think I have just about covered them all.

I have just opened a new thread over how to provide a better Linux binary distribution.

http://bitcointalk.org/index.php?topic=612.0

Hi,

I am a software developer and while I am well versed with building things on Linux I thought I might provide some pointers to making like easier for others.


There is one aspect with distributing a single download package for Linux that is dynamically linked, "You should use the oldest versions of glibc/libstdc++ you can get away with.  i.e. unless you know you need a new feature or a bug fix take is as a given that the libraries at runtime will be newer and contain those fixes."

The problem with linking against the bleeding edge versions of glibc/libstdc++ is that you force the users to have a bleeding edge system also (to run these binaries).  Which should not be a necessary pre-requisite unless you know of specific cause for it to be so.  Such causes should be explained in documentation. Where as if you simply linked on an older system it would work both on that older system and on the bleeding edge system.

If there are areas of C code which you really-really need some new and recent GCC optimization to be enabled, consider providing the dumped out ASM file *.s which you generate once from your bleeding edge GCC version but include in the source to allow anyone to complile (even on older GCC versions).


Here are some recomendations:
 * Use the oldest base distribution you can get away with to build the binaries.  For example the most recent copy of the _PREVIOUS_ release of debian.  Not the most update to date copy of the current release of debian.
 * Provide a download containing static binaries (use the "-static" option to linking and maybe add this so the name of the executables "bitcoind-static"). Provide this in a seperate download file.
 * Make the source distribution build work from working copies of the libraries they need.  In particular boost and wxWidgets, if you know you need very recent versions of these to build against, then make building and linking work right out of their respective build tree (so you don't have to install them).  Installing them in /usr/local maybe an issue (it certainly is for me) but having themin the current working directory just for bitcoin's use would be fine.  At the end of the day all bincoin needs is access to header filer and DSOs or *.a to build and access to the DSOs at runtime.


I can put a 24/7 headless bitcoind up but because of these issues, until I find/make time to resolve them I can not at this time.