search

namecoin / namecoin-legacy

Legacy client. New version here: https://github.com/namecoin/namecoin-core Note the release branch! - Official website:
https://namecoin.org
MIT License
448 stars 177 forks source link

Minimal changes to get building on OS X with clang and Homebrew #136

Closed taoeffect closed 10 years ago

taoeffect commented 10 years ago

Install dependencies with Homebrew and then from within src directory:

make USE_UPNP=1 -j $(sysctl -n hw.ncpu) -f Makefile.osx all

The only concern is how to install specific versions of the dependencies (to avoid accidentally resulting a hard fork).

Unfortunately, I couldn't find "db-4.7.25.NC" via Homebrew. The farthest back they have is 4.8.30. Is that OK?

Also, I haven't tested yet if boost 1.5 builds on OS X or not. 1.55 does, but I'm not sure about 1.5.

taoeffect commented 10 years ago

Note also that this is just for building namecoind (not the QT GUI).

Midar commented 10 years ago

This would be obsoleted if https://github.com/namecoin/namecoin/pull/135 is merged

taoeffect commented 10 years ago

:+1: @Midar. commented

taoeffect commented 10 years ago

Update: this was fixed. Safe to merge!

Also, just an FYI, this does contain a breaking change for some compilers. If someone needs me to fix that just let me know and I'll figure out the macro for detecting clang compilers (instead of just commenting this section out).

Midar commented 10 years ago

PR #108 doesn't break compilation with non-Clang compilers BTW.

cassiniNMC commented 10 years ago 
LIBS+= \
 -Wl,-dynamic \ 
 -lgthread-2.0 \

Do we really need gthread?

Midar commented 10 years ago

The other Makefiles have that, too, but it shouldn't be necessary. My PR that introduces a proper build system doesn't have it and it works :).

indolering commented 10 years ago

So this does NOT work for Namecoin-QT, correct?

taoeffect commented 10 years ago

@indolering Correct.

taoeffect commented 10 years ago

I don't expect this to be merged btw. It's just an illustration of the minimal changes needed to build on OS X.

indolering commented 10 years ago

@taoeffect Yeah, I had it working ~8 months ago, then changes to 10.9 and the switch to Clang broke Boost.

phelixbtc commented 10 years ago

It seems OS X is even worse than windows in regard to building. Somebody please make it work! With GUI! @taoeffect Windows version is also using db-4.8.30.NC

Midar commented 10 years ago

@phelixbtc I got it working with GUI, see my other PR.

indolering commented 10 years ago

@Midar https://github.com/ceptacle/libcoinqt Interested?

indolering commented 10 years ago

@phelixbtc could we get this PR request accepted? Namecoind is better than nothing and Midar's other build system isn't going anywhere.

taoeffect commented 10 years ago

What's libcoind missing that namecoind has? I like libcoind's build system better (and I got it to build on OS X, I should probably submit a PR for that too...)

JeremyRand commented 10 years ago

@taoeffect libcoind is missing a few things, including RPC calls for registering names. There's more info on the forum. I might be able to arrange some bounties for getting libcoind up to par with namecoind feature-wise, if that's something you're interested in.

taoeffect commented 10 years ago

I wouldn't be able to do it (allergic to C++), but I might be able to chip in. Grumble. What about bitcore? Can it do namecoiny things yet? I think @ryancdotorg was working on that...?

taoeffect commented 10 years ago

NM, @ryancdotorg said on IRC that he's not entirely sure what bitcore is... lol. And I can't figure it out either! Is it a liteclient? It doesn't seem to be a full node.

taoeffect commented 10 years ago

OK, so figured out what bitcore is thanks to jgarzik on #bitcore.

Bitcore is:

Copay is:

Insight-API seems to be:

So... nm about the bitcore. Looks like all we have is namecoind and libcoin --namecoin, so it seems we'd better focus on libcoind.

domob1812 commented 10 years ago

Sorry for the OT, but I think I should comment here regarding libcoin: Yes, exactly, the missing features are registering names and name_list. I'm actually planning to start working on these "really soon" (next week at the latest), so hopefully they will be implemented in the not too distant future. Bounties would, of course, be appreciated, but I'm determined to do it nevertheless.

phelixbtc commented 10 years ago

Is there a consensus this is a step in the right direction? @cassiniNMC?

@taoeffect Could you give example lines for how to install dependencies with proper versions with homebrew? Why did you not expect this to be merged?

taoeffect commented 10 years ago

@taoeffect Could you give example lines for how to install dependencies with proper versions with homebrew?

Like I said, the "proper versions" aren't available on Homebrew, so I used what was available there. boost 1.55 seems to be working. I also installed openssl via Homebrew, as well as berkeley-db. These were installed just using regular brew install [blah] commands (I think). Try this out and let me know if you run into problems (I'm unfortunately rather pressed for time).

Why did you not expect this to be merged?

Because this comment.

phelixbtc commented 10 years ago

@taoeffect OK, we should be able figure these out, thanks!

cassiniNMC commented 10 years ago

this does contain a breaking change for some compilers. If someone needs me to fix that just let me know and I'll figure out the macro for detecting clang compilers

@taoeffect Yes, it would be great if you could find out a suitable macro/pragma for that section in serialize.h

indolering commented 10 years ago

Bounties would, of course, be appreciated, but I'm determined to do it nevertheless.

Please don't say this, you yourself said that you have 5-10 hours of contract work per week: bounties enable you to work on Namecoin. It's nice that you squeeze it in anyway, but the impact is greater than what you lead people to think.

taoeffect commented 10 years ago

@cassiniNMC: if either you or @phelixbtc or anyone else can just tell me what the pragma is i'll paste it in there and push a commit. right now i've a billion things going on that are higher priority, and this should be a simple google search for ya'll (and me, admittedly, it's just that for me the google search must be put off until I knock out the high priority items).

phelixbtc commented 10 years ago 
#ifdef __WXMSW__
    // Windows
#else
#ifdef MAC_OSX
    // MAC
#else
    // ...
#endif
#endif
taoeffect commented 10 years ago

Hmm, that assumes clang isn't being used anywhere but OS X. Isn't it possible these issues could happen on Linux with clang?

indolering commented 10 years ago

@taoeffect the only reason we are using clang on OS X is because Apple fucking replaced GCC specific commands with Clang aliases and removed GCC from OS X 10.9. If someone wants to use Clang on Linux, that's their problem.

taoeffect commented 10 years ago

@taoeffect the only reason we are using clang on OS X is because Apple fucking replaced GCC specific commands with Clang aliases and removed GCC from OS X 10.9. If someone wants to use Clang on Linux, that's there problem.

mmk... that is because clang is better than GCC. :P

OK, I decided to google it. It's __clang__.

I'll try to get a commit pushed shortly.

taoeffect commented 10 years ago

Um, somebody please remind me: this branch is pretty far behind namecoinq now, so what should I do... merge those changes on top of this commit, rebase (too late probably), just make my changes in a new commit after this one and push without merging, or close PR and re-open after merging?

cc @phelixbtc @cassiniNMC @JeremyRand @domob1812

taoeffect commented 10 years ago

I feel like (1) merge, (2) make changes, commit, and push is the right answer, but am not sure.

taoeffect commented 10 years ago

OK, impatient so I went ahead with merge, fix, commit, push.

Should be safe to merge now!

taoeffect commented 10 years ago

Please test this to make sure it compiles on Linux/Windows before merging! I verified it works on OS X.

indolering commented 10 years ago

@taoeffect Does this require berkeley-db4 to be installed or will db5 work? Is this working with QT?

taoeffect commented 10 years ago

@taoeffect Does this require berkeley-db4 to be installed or will db5 work? Is this working with QT?

I actually compiled this with db5... but it should probably be done with db4, right @JeremyRand @ryancdotorg? (cc @domob1812).

Should I change it to use db4 or leave it as-is for use with db5 (which is in homebrew for berkeley-db).

indolering commented 10 years ago

I actually compiled this with db5... but it should probably be done with db4, right @JeremyRand @ryancdotorg? (cc @domob1812).

Should I change it to use db4 or leave it as-is for use with db5 (which is in homebrew for berkeley-db).

@taoeffect, well, it's not building with db4.

I'm not sure if I should put the following instructions in docs/build-osx.txt or the main readme.md, so I'm going to put it here:

  1. Install dependencies using Brew:

    brew install openssl boost miniupnpc berkeley-db

  2. Execute make command from the src directory:

    cd ./src make USE_UPNP=1 -j $(sysctl -n hw.ncpu) -f Makefile.osx all

  3. Standard compiler warnings will appear but if the build is successful you will find a binary at ./src/namecoind.
taoeffect commented 10 years ago

@taoeffect, well, it's not building with db4.

Yeah I know, I need to change the Makefile for that to work. The paths to the libraries and headers need to be manually specified for db4 (like I've done for openssl, for example).

brew install openssl boost miniupnpc berkeley-db

Yep, except it would be berkeley-db4 if the others think that's what it should be.

domob1812 commented 10 years ago

Actually, I would have preferred to rebase (git rebase instead of git merge) your commits on top of the current branch, so as to not have a "merge" commit in the history. But it doesn't matter for now - just remember this for the future. ;)

Apart from that, I'm fine with the changes as long as everyone confirms it works for them and fixes the problems on OS X.

indolering commented 10 years ago

@taoeffect if moving to db4 is easy, just do it. It can't hurt.

phelixbtc commented 10 years ago

IIRC database format has changed between db4 and db5 so it is important to always use db4 for compatibility.

Compiles fine on Windows.

I'm not sure if I should put the following instructions in docs/build-osx.txt or the main readme.md

build-osx.txt imho but I suggest a separate commit to get this one merged.

taoeffect commented 10 years ago

OK, I'll push an update (hopefully today if I don't forget) to change the Makefile to use db4.

taoeffect commented 10 years ago

K. This is ready to be merged. I got rid of gthread and am requiring miniupnpc to be installed (cause... there's no reason not to), simplified Makefile.osx somewhat, and switched to berkeley-db4.

Compiled and verified.

Will crash if you have previously used this PR to run namecoind because of database downgrade to berkeley db 4!!!

You have two options:

Or

If you go with the second option, you will need to delete all your database stuff and re-download. You can use my node on okturtles.com to "quickly" get up to speed (I have bandwidth to spare):

./namecoind -gen=0 -server -addnode=192.184.93.146

Then after it boots up add re-import your private keys that you exported:

./namecoind importprivkey 23rjkjf823jf98jsfj8932jfj98fw982jf982jf9fj8

(Obviously, the key above isn't a real one, just an example.)

taoeffect commented 10 years ago

Also, regarding build-osx.txt, instructions are simple now:

  1. brew install openssl berkeley-db4 boost miniupnpc
  2. cd src && make -f Makefile.osx -j $(sysctl -n hw.ncpu) all

If you know your CPU count, you can just use it: make -f Makefile.osx -j 8 all

taoeffect commented 10 years ago

Actually, I would have preferred to rebase (git rebase instead of git merge) your commits on top of the current branch, so as to not have a "merge" commit in the history. But it doesn't matter for now - just remember this for the future. ;)

@domob1812 I decided to not do a rebase because I had already pushed the changes publicly. You aren't supposed to rebase if you've made your stuff public (as that will cause history conflicts).

domob1812 commented 10 years ago

@taoeffect Considering that this branch on your repo is just a "work in progress", I see no problem with rebasing it. This is also what Bitcoin devs usually want, and it makes the official repo's history cleaner. I think this counts more than following some "supposed to be" Git guidelines to-the-letter.

taoeffect commented 10 years ago

OK, I actually replaced __clang__ with __APPLE__ because ironically enough that broke compilation with clang under linux. Now I've verified it compiles on OS X and Linux using clang. I wasn't able to test gcc on either platform however (OS X doesn't have it, and on linux my VPS kills the process for probably using too much RAM).

phelixbtc commented 10 years ago

Compiles and runs on Windows. ACK. Linux GCC?

JeremyRand commented 10 years ago

IMO someone should test on Linux GCC before this is merged. Maybe someone can ask pmc to look at it?