• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

So, I thought I would poke at the codebase a bit (aka, I can't even build this thing called Dash)

t0dd

t0dd

Active member
A wild inspiration hit me to take a look at the codebase of dash a bit. I found it on github, I forked it, poked around the code a tad... And then I decided I would try to build the sucker. Oh, how silly of me.

Platform: Fedora 23 (Fedora is upstream for CentOS and RHEL).

Like most folks, I read the build docs...
https://github.com/dashpay/dash/blob/master/doc/build-unix.md

Somewhat helpful, but they are written in "debian" which only helps so far. I found the SRPM for bitcoin that a dude has been building for Fedora, and that has been uber-helpful. It allowed me to crack open that spec file and see what Fedora needs from a dependency perspective. For you Fedora folks out there, this page is also helpful: https://fedoraproject.org/wiki/How_to_create_an_RPM_package

Bitcoin builds fine for me. I just wanted to put that out there. Bitcoin with gui and "everything".

With dash, I first tried to compile the master branch. That failed in several ways. So I tried to build from 0.12.0.56 (latest stable). So... this is what I am slamming into...

1. the -fPIC wall I keep running into
"""
/usr/include/qt5/QtCore/qglobal.h:1067:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
# error "You must build your code with position independent code if Qt was built with -reduce-relocations. "
"""

It been awhile since I have built from makefiles and with C++ for that matter. I have googled this to death, but I can't seem to resolve this. Help getting me to a -fPIE compliant build platform, or ... getting the compile to force -fPIC (less ideal)?

2. Can't find boost libraries. UPDATE -- this was a red herring
When I ./configure from the stable 0.12.0.56 branch, it finds the boost libraries just fine. But for the master branch? Nope... can't find the libraries. I am still trying to determine if I fouled something up in my attempt to solve other problems versus being a problem out of the box, but it baffles me.

....

I am writing out what I am doing to solve dependencies and edits and whatnot with the end objective of building Fedora RPMs for dash stable as well as maybe even dash master. With the end goal of making it easy for me to experiment and build... and then maybe make it easy for other folks to experiment and build. Plus... Fedora (and the Red Hat ecosystem) needs a dash RPM, yo! :)

Anyway. I would love your thoughts. And if someone would make themselves asynchronously available for stupid-compiler-questions, that would be stellar. I can be found in the slack community and here.

Thanks a bunch for any guidance. And, oh, hey! First post. :)
-dA
 
Last edited by a moderator:
Thanks for offering your time crowning. I may still poke you for advice if I get stuck again. In the meantime...

Boostlib issue: Red Herring. I have no idea what caused that.

The fPIC errors due to configure.ac settings:
  • I "resolved" the blocker.
  • The Fedora bitcoin package maintainer says that fedora enables a host of security mechanisms that debian and ubuntu do not. And this seems to be associated to that. He was not sure how to resolve it though (cursory examination only, by him of course). Note: His bitcoin compile / packaging works, and fPIC settings seem more generic.
  • I took a look at what the Arch linux dudes (thank you for pointing me their way, Joshua on #slack) were doing and they brute force -fPIC -- "inelegant and wrong". I think.
  • I tried the route that the bitcoin RPM maintainer did... and failed
  • I ended up brute forcing through the problem like the Arch Linux dudes did.
    https://github.com/bitcoin/bitcoin/pull/6248/files
  • I still don't quite grok what this is all about and how it should be appropriately handled.
So, I was able to build things! :)

Thus far:
  • Built stable dash (0.12.0.56) from a raw tarball on Fedora 23. Yay!
  • Built a stable dash(0.12.0.56) Fedora 23 compatible RPM. Yay!
    But! Doesn't include all that pesky masternode stuff
    Note: This was MUCH harder than anticipated.

Next is...
  • cleaning up RPM spec file -- UPDATE: DONE!
  • generalizing the -fPIE/-fPIC flag logic, if possible -- UPDATE: probably not doing for 0.12.0.56
  • included all the masternode and other dashy bits into the RPM -- UPDATE: DONE all along
  • making everything available via github or some such
  • building from a branch well ahead of master: maybe 0.12.1.x ? -- UPDATE: DONE!
Thanks everyone who responded. I will post the RPMs somewhere for testing soonish. :) -- UPDATE: DONE! (see later posts in the thread)
 
Last edited by a moderator:
dAgrarian said:
Thus far:
  • Built stable dash (0.12.0.56) from a raw tarball on Fedora 23. Yay!
  • Built a stable dash(0.12.0.56) Fedora 23 compatible RPM. Yay!
    But! Doesn't include all that pesky masternode stuff
    Note: This was MUCH harder than anticipated.

Next is...
  • cleaning up RPM spec file
  • generalizing the -fPIE/-fPIC flag logic, if possible
  • included all the masternode and other dashy bits into the RPM
  • making everything available via github or some such
  • building from a branch well ahead of master: maybe 0.12.1.x ?
Thanks everyone who responded. I will post the RPMs up for testing soonish. :)
Click to expand...

Thanks for taking the time to look into a Fedora build! Just out of curiousity, what am I missing with regards to that "pesky masternode stuff"? I thought it was all built-in to dashd source.

Do you have to do something different to create an RPM with masternode functionality?
 
The masternode bits were built, but they are not included in the RPM... because, essentially what I did was build the RPM no differently than a bitcoin RPM. So, all the basics are there, but not all the dashy stuff. That's next on my list. (UPDATE -- I was incorrect see next posting)

Step 1 was to get it to build and package.

Step 2 will be to get my patches of the configure.ac build code and such separated from the tarball and include the masternode (and other) missing bits. I then have to look at adding system services associated to that, if needed, and probably write SELinux policies and all the other stuff needed to round things out.
 
Last edited by a moderator:
New RPMs - 0.12.0.56-3.taw - fixed a bunch of packaging stuff.
https://drive.google.com/folderview?id=0B0BT-eTEFVLOdWJjWGRybW1tMjQ
Check out the "README" document there, first.

By the way, I kept saying the masternode and dashy bits were not included. That's because, I don't have a masternode and didn't know any better. :) Everything should be included in these RPMs. Lemme know if they are not.

These RPMs were build for x86_64 bit linux -- Fedoa 23 specifically. They should/may work on another RPM-based distributions and certain modern Red Hat family of products (maybe... RHEL7 is Fedora... 18? I think?). If not... the SRPM is there. But there is a bunch of squirreliness in the configure.ac file surrounding -fPIE and -fPIC that I don't understand.
 
Last edited by a moderator:
MORE RPMs!!!! :)
0.12.0.56, 0.12.1.x and 0.13.0.x -- a built and re-buildable for different RPM-based platforms. 0.12.1.x should rebuild the easiest.
https://drive.google.com/folderview?id=0B0BT-eTEFVLOdWJjWGRybW1tMjQ

By the way, devs... 0.13.0.x needs to be rebased sometime to at least align with 0.12.1.x. It's bitcoin base is well behind 0.12.1.x's.

Hmm... Maybe this should be a new thread since I got over the "can't build this thing" subjectline.
 
Last edited by a moderator:
Good job! .. though I have no idea what to do next with these rpms :D Can we incorporate this in our release pipeline somehow maybe? flare
And btw I guess you can "forget" about 0.13.0.x branch for some time, we'll take few more 0.12.x.x steps first on our way to 0.13.x afik.
 
dAgrarian said:
MORE RPMs!!!! :)
0.12.0.56, 0.12.1.x and 0.13.0.x -- a built and re-buildable for different RPM-based platforms. 0.12.1.x should rebuild the easiest.
https://drive.google.com/folderview?id=0B0BT-eTEFVLOdWJjWGRybW1tMjQ

By the way, devs... 0.13.0.x needs to be rebased sometime to at least align with 0.12.1.x. It's bitcoin base is well behind 0.12.1.x's.

Hmm... Maybe this should be a new thread since I got over the "can't build this thing" subjectline.
Click to expand...
Thanks, I'll dig into this and incorporate your work into our Build process so that we can deliver rpms for new releases from the start from now on :)
 
flare said:
Thanks, I'll dig into this and incorporate your work into our Build process so that we can deliver rpms for new releases from the start from now on :)
Click to expand...

Okay. I have no idea how you guys publish things, so... just let me know how you'd like to make this process work, and hopefully I can help.
 
Oi! There is already a "dash" package ... in almost all linux distributions. So I will have to rename the dash package that provides the dash-qt node and wallet. Grr. What dash collides with our dash? This one: https://en.wikipedia.org/wiki/Almquist_shell

Alas. If anyone has a favored name for these packages... lemme know. I am thinking "digital-cash" or "digitalcash" or... some such. Or... I just call the package that houses dash-qt, simply that, "dash-qt" or maybe even "dash-client" (even though as a full node, it is not really a client per ce). Dunno. This is annoying.
 
Last edited by a moderator:
It's going to be "dash-client" -- that is most consistent with the other packaging. And it keeps "dash" in the package names. Lemme know if any of you have further questions. I should be done rebuilding and signing and documenting everything... tonight? tomorrow? Somewhere in there.
 
Okay. Everything rebuilt. Rebuilt from these source RPMs...
  • dash-0.12.0.56-6.taw.fc23.src.rpm
  • dash-0.12.1.x-20160410.taw.fc23.src.rpm ...and...
  • dash-0.13.0.x-20160410.taw.fc23.src.rpm
The RPMs that house the client program (dash-qt) is now called dash-client versus just dash (see name collision mentioned in prior comment).

I have a Source RPM github space now: https://github.com/taw00/dash-srpms
There is even instruction on how to build and compile from the source RPMs there.

All the binary RPMs are in their old location:
https://drive.google.com/folderview?id=0B0BT-eTEFVLOdWJjWGRybW1tMjQ

Instruction as to what they are, verification, and some installation instruction is there as well.
 
dAgrarian said:
It's going to be "dash-client" -- that is most consistent with the other packaging. And it keeps "dash" in the package names. Lemme know if any of you have further questions. I should be done rebuilding and signing and documenting everything... tonight? tomorrow? Somewhere in there.
Click to expand...
I think that's gonna be confusing for people who just want to run dashd. Just a thought. I would be confused as hell personally.
 
nmarley said:
I think that's gonna be confusing for people who just want to run dashd. Just a thought. I would be confused as hell personally.
Click to expand...

dashd is a daemon. Not a client. Ie. It is properly a server ... a service that should ultimately be managed as such using systemctl if a system were really properly deployed and set up correctly. You can pretend it is a "client" by calling it directly, but it really isn't.
 
You must log in or register to reply here.
Back
Top