I can certainly do that... I have a BOINC manager installed which works, with a GUI and everything, and have suspended E@H for now.
I just wanted everybody to know that I was able to get 5.10.28 to compile! (Yay!) There appears to be an unspoken reason for which this build error is not explained, and I will maintain the code about that.
As it stood, the binary which gets distributed to general users was compiled against GLIBC 2.4 , where GLIBC governs such things as system calls (to the kernel). Common documentation tells us that these system calls are better taken care of by using libstdc++ , but what they don't tell people often, is that the shared and static libraries of libstdc++ were themselves linked to static libraries such as GLIBC before they were shipped with the compilers. Long story short, if we don't have a GLIBC 2.4 kernel, there isn't much we can do to comply with GLIBC 2.4 capabilities from the executable. Mine is GLIBC 2.2 .
But this means that there are no explicit calls to system-trap functions within the source code of the BOINC client, which is why I was able to compile the same source code against my GLIBC 2.2 , which is still packaged separately from the other packages that make up Etch. Even though we have no choice about it under Etch. And so my custom compiled version will run under GLIBC 2.2 .
But the way this gets organized, the developers of BOINC would rather that most of the compiling be done by professional package maintainers. I was actually a little over my head with this one.
But maybe I should in fact just let this rest until the weekend, since SETI@Home is still able to run fine, using BOINC client and managers version 5.4.11. At that later point in time, I can take on uninstalling 5.4.11 , and installing the just-compiled version into my root file system. This is not the kind of setup that one runs as easily in userspace.
Okay. So what I have done now, was to uninstall my boinc core client, version 5.4.11 from the task manager, as well as the BOINC Manager that came with it. And then I installed the version 5.10.28 which I previously compiled. The only configuration issue, if one wants to call it that, was that the old programs were installed into /usr/bin, while the custom-compiled ones, predictably enough, are located in /usr/local/bin . Big deal.
I also installed the new BOINC Manager in the same step, and that I reinstalled KBoincSpy for good measure.
The only quirk which I find, is that if I close the window of this BOINC Manager window, it exits ungracefully, that is with segfaults all over the place according to a terminal window. But even doing so doesn't stop the core client or its work. However, if I choose Exit from the BOINC Manager command menus, then it exits without any error code (and still leaves the core client running).
So now we can observe, whether work unit h1_0185.10_S5R4__6_S5GC1a_2 will complete and upload normally, which preceding units failed to do. And if this work unit fails, we'll see whether this takes down my core client again.
But I can already tell you, that work unit h1_0185.10_S5R4__2_S5GC1a_2 exited with a "Computation Error" at 100% completion, according to the new BOINC Manager, and without taking out the core client, where I suspect that the older version of the core client would have bombed by now...
It seems that the first problem has been solved. The BOINC client is downloading and completing one Einstein@Home work unit after the other.And they all say, "Ready To Report" now.
So the problem which prompted this thread is solved.
I can certainly do that... I
)
I can certainly do that... I have a BOINC manager installed which works, with a GUI and everything, and have suspended E@H for now.
I just wanted everybody to know that I was able to get 5.10.28 to compile! (Yay!) There appears to be an unspoken reason for which this build error is not explained, and I will maintain the code about that.
As it stood, the binary which gets distributed to general users was compiled against GLIBC 2.4 , where GLIBC governs such things as system calls (to the kernel). Common documentation tells us that these system calls are better taken care of by using libstdc++ , but what they don't tell people often, is that the shared and static libraries of libstdc++ were themselves linked to static libraries such as GLIBC before they were shipped with the compilers. Long story short, if we don't have a GLIBC 2.4 kernel, there isn't much we can do to comply with GLIBC 2.4 capabilities from the executable. Mine is GLIBC 2.2 .
But this means that there are no explicit calls to system-trap functions within the source code of the BOINC client, which is why I was able to compile the same source code against my GLIBC 2.2 , which is still packaged separately from the other packages that make up Etch. Even though we have no choice about it under Etch. And so my custom compiled version will run under GLIBC 2.2 .
But the way this gets organized, the developers of BOINC would rather that most of the compiling be done by professional package maintainers. I was actually a little over my head with this one.
But maybe I should in fact just let this rest until the weekend, since SETI@Home is still able to run fine, using BOINC client and managers version 5.4.11. At that later point in time, I can take on uninstalling 5.4.11 , and installing the just-compiled version into my root file system. This is not the kind of setup that one runs as easily in userspace.
Okay. So what I have done
)
Okay. So what I have done now, was to uninstall my boinc core client, version 5.4.11 from the task manager, as well as the BOINC Manager that came with it. And then I installed the version 5.10.28 which I previously compiled. The only configuration issue, if one wants to call it that, was that the old programs were installed into /usr/bin, while the custom-compiled ones, predictably enough, are located in /usr/local/bin . Big deal.
I also installed the new BOINC Manager in the same step, and that I reinstalled KBoincSpy for good measure.
The only quirk which I find, is that if I close the window of this BOINC Manager window, it exits ungracefully, that is with segfaults all over the place according to a terminal window. But even doing so doesn't stop the core client or its work. However, if I choose Exit from the BOINC Manager command menus, then it exits without any error code (and still leaves the core client running).
So now we can observe, whether work unit h1_0185.10_S5R4__6_S5GC1a_2 will complete and upload normally, which preceding units failed to do. And if this work unit fails, we'll see whether this takes down my core client again.
But I can already tell you, that work unit h1_0185.10_S5R4__2_S5GC1a_2 exited with a "Computation Error" at 100% completion, according to the new BOINC Manager, and without taking out the core client, where I suspect that the older version of the core client would have bombed by now...
It seems that the first
)
It seems that the first problem has been solved. The BOINC client is downloading and completing one Einstein@Home work unit after the other.And they all say, "Ready To Report" now.
So the problem which prompted this thread is solved.