No need to use make install. Just copy client/boinc in to a empty directory and run it from there.

-108 is some error in fopen
512 is a bug, it's child exited with exit status 2, which might be file not found

05-Feb-2016 13:29:25 [---] [coproc] launching child process at boinc_client

How did you start the client? Try starting it from command line, as in ./boinc .

05-Feb-2016 13:29:25 [---] [coproc] launching child process at boinc_client

How did you start the client? Try starting it from command line, as in ./boinc .

yes, boinc is trying to fork a copy of itself with the "--detect_gpus" parameter and so is failing at that point.

OMG. I think it worked!

2$ ./boinc
05-Feb-2016 19:53:22 [---] Starting BOINC client version 7.6.23 for x86_64-pc-linux-gnu
05-Feb-2016 19:53:22 [---] log flags: file_xfer, sched_ops, task, coproc_debug
05-Feb-2016 19:53:22 [---] Libraries: libcurl/7.43.0 NSS/3.21 Basic ECC zlib/1.2.8 libidn/1.32 libssh2/1.6.0 nghttp2/1.6.0
05-Feb-2016 19:53:22 [---] Data directory: /home/<username>/local/BOINC
05-Feb-2016 19:53:22 [---] [coproc] launching child process at ./boinc
05-Feb-2016 19:53:22 [---] [coproc] relative to directory /home/<username>/local/BOINC
05-Feb-2016 19:53:22 [---] [coproc] with data directory /home/<username>/local/BOINC
05-Feb-2016 19:53:22 [---] OpenCL: AMD/ATI GPU 0: AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) (driver version 11.1.0, device version OpenCL 1.1 MESA 11.1.0, 1024MB, 1024MB available, 1680 GFLOPS peak)
05-Feb-2016 19:53:22 [---] OpenCL: AMD/ATI GPU 1: AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) (driver version 11.1.0, device version OpenCL 1.1 MESA 11.1.0, 1024MB, 1024MB available, 1680 GFLOPS peak)
05-Feb-2016 19:53:22 [---] OpenCL CPU: pthread-AMD FX(tm)-8350 Eight-Core Processor (OpenCL driver vendor: The pocl project, driver version 0.12, device version OpenCL 1.2 pocl)
05-Feb-2016 19:53:22 [---] [coproc] NVIDIA: libcuda.so: cannot open shared object file: No such file or directory

Wow! This is awesome! I had no idea this would work. Actually I was pretty sure it wouldn't...I spent years fighting proprietary drivers because I thought it wouldn't.

I stand happily corrected! You are right and I was wrong, so wrong.

Thank you for all your help. Really; you may not know how much easier this makes my life.

I have only have one other question and it's much easier, I'm sure:
Do you think this worked because it was a newer version or something else? I want to know because, if it's just an improvement made between 7.2.42 and now, then I want to request an update to the Fedora repository package and I don't need to give any other instructions. (I think it must be because I didn't change a single thing on my computer.)

Oh, one more thing, sorry...

Do I need to build the manager now to talk to the client? I figured my old manager would work, but it doesn't seem to want to stay connected.

Nevermind. After trying a few times with boinccmd, it started working and so I tried my distribution's boincmgr again, it also worked. So, all good.

Should have project tasks running very soon!

Rats! Seems like SETI doesn't have any apps for these GPUs, although BOINC is asking the project for AMD/ATi tasks. That's why I came here and you delivered.

Many thanks, again!

I guess I can head over to SETI forums and see if someone there can help me like you did. I can try other projects, too, that'd be almost as good.

If you unhide your systems at Einstein, people helping you can check what its scheduler reports why it isn't sending you any work.

But it may well be that both Einstein and Seti require OpenCL 1.2

Edit: I asked that your thread at Seti be moved to the Number Crunching forum there, because that's where the developers of the applications post. Hope I didn't intrude. :)

---

If you unhide your systems at Einstein, people helping you can check what its scheduler reports why it isn't sending you any work.

But it may well be that both Einstein and Seti require OpenCL 1.2

Correct - Einstein uses OpenCL 1.2 see here but the logs will, if visible, may show more.

Edit: I'm not 100% that 1.1 is not supported on AMD, it is not supported on Intel iGPUs - i do know that.

Do you think this worked because it was a newer version or something else? I want to know because, if it's just an improvement made between 7.2.42 and now, then I want to request an update to the Fedora repository package and I don't need to give any other instructions.

Yes, it's most likely the new version. You could ask Fedora packagers to update BOINC anyway, F24 is going to have GCC 6 and 7.2 doesn't build with it without patching. 7.6.23 is compatible with GCC 6.

I have initiated a bug to have BOINC (and related libs) updated in Fedora. My main goal is to make sure this gets into F24, since it sounds like that will have to happen, anyway. Depending on how that goes, I'll also push for an update into F23.

But, they have asked me for all the details regarding this bug with wxWidgets and boincmgr. Will BOINC folks please post or send me details? I need to know (or be able find out by researching): A) what is the wxWidgets patch that is needed for boincmgr (it sounds like the patch already exists and has been tested, is that true?); and 2) what is happening upstream with wxWidgets development team regarding this bug/patch.

I have to search through various emails and email lists, not all public for the answers to all your questions. But I will do that tomorrow, am now going to bed.
In the mean time, wxWidgets 3.0.2 available now is all right, if all is well BM will build with that.

---

Oh, really? Well, F23, which is latest, has wxGTK3-3.0.2-12.fc23. So, perhaps Fedora's wxWidgets is good.

But, I thought not, since Paulie (over at Einstein@Home) tried to build boincmgr before and had problems. I'm sure he has Fedora and I'm almost certain he tried on F23. For myself, _autosetup (or was it configure?) couldn't find wxWidgets and turned off disabled building the manager, so, I'm not really sure what would happen if I got it to build. Perhaps I'll check that out. I read somewhere that having 2.x and 3.x available would confused the build process, so I'll try to give wxWidgets3 path and see if that will at least build it... More later.

Thanks Ageless! Sorry to make you work for it; if it's not public I guess can't find without your help. No hurry, of course. Feel free to just point me somewhere if you can.

Wow, that was easy. I pointed ./configure at my system wx-config-3.0 and that prevented it disabling the mgr build. The build completed and it seems to work file. Paulie reported 100% CPU usage, but I don't see that on my system.

So, I think that's that. It looks better just about everywhere, too. System tray mouse-over is improved (proper location, system style).

I'll report back here if I find problems, but I'll talk to Paulie and see if we can get it built for him, too.

Thanks Ageless! Sorry to make you work for it; if it's not public I guess can't find without your help. No hurry, of course. Feel free to just point me somewhere if you can.

I think some of the discussion happened on the BOINC Alpha list which isn't public, but I should be able to point to discussions on the BOINC Development and BOINC Projects email lists. It's just slow going, as my health has taken a turn back towards coughing my lungs out. So it may take me a couple of days. Sitting with a pounding head behind a monitor makes me want to throw my wireless keyboard from the table. ;-)

---

I think we have some confusion here. There shouldn't be any need to patch wxWdidgets. The early versions of wx 3 weren't perfect and early 7.3/7.4 versions of BOINC weren't perfect either. wxWidgets 3.0.2 and BOINC 7.6.23 should work together just fine.

Now regarding stable versions. BOINC 7.6.23 is good. Since .23 a developer decided it would be good idea to destabilize the stable client branch and started developing a new feature there. As far as I know it has not been properly tested and I don't know if the feature is even complete yet. Because of that .24 and later should not be used until such time that there is a recommended version for both Windows and Mac.

And the recommended versions. Since BOINC developers don't any more build packages for Linux distro maintainers should use Windows and Mac recommended versions as a guide.

I think we have some confusion here. There shouldn't be any need to patch wxWdidgets. The early versions of wx 3 weren't perfect and early 7.3/7.4 versions of BOINC weren't perfect either. wxWidgets 3.0.2 and BOINC 7.6.23 should work together just fine.

That was what I was going to look for, the whole discussion behind it, what was broken, where and when it was fixed. But wasn't wxWidgets 2.8 already broken as well at one point for Linux?

---

I don't remember any problems with wx 2.8 but it may have been before I started watching BOINC development. I'm relatively new here and the mailing lists, been here since sometime in the early 7.0 series.

wx 3.0.0 had broken mousewheel support and BOINC 7.3/7.4 had some problems scrolling and updating project and task lists. I forget which version had those fixed, we've had too many versions since then.

Oh, good. So, the picture is getting more clear quite quickly.

I can also report that Fedora has just released new testing packages based on 7.6.22 for F23(current), & RHEL7. Now that I have converted back to a local copy, I need to take care not to mess things up when I test it, but I'm going to try to do that later this week. There is one report of problems already, though.