Build report (XUbuntu 17.10)

[tmeysson]

Hello, Went through building and running philosopherstone-qt on a NIC server running UbuntuStudio 17.10 (some kind of XUbuntu). Here's what I found: 1) latest release DOES NOT WORK, crashes just after initialisation, can't remember the message but I think it fails to create the GUI. So, compiled it from GitHub source, works. 2) build instructions are missing, even though it should just be something like "qmake && make". Might be helpful in case of doubt (I'm not so used to Qt compilation, personally). 3) possibly some deps aren't mentionned, like libboost and libdb_cxx. For libdb_cxx, had to edit the .pro file to remove $$LIB_DB_SUFFIX from the corresponding LIBS+= line, suggest setting it to null when platform is linux. 4) I can remember having a problem with libboost also, but I forgot about how I fixed it, sorry.

Otherwise seems to work, thanks a lot ! Keep up the good work, otherwise Linux people will have to run this from a virtual machine...

[toxtox]

Thanks for your experiences! One question: Is your NIC server powered by an ARM-CPU or an X86-64 CPU?

1. I guess it is an portable issue I had only two systems on which I could try the portability of the binary releases (two raspberry pis and two X86-64 machines). I tryed to make is as portable as possible by supplying/putting all required libs in the "_shared_libsactive" subdirectory. You could try to delete some of the libs in "_shared_libsactive" subdirectory one by one. Then the PHS-wallet tries to use your system libs (if installed). This should be more stable but less portable.

... some more infos later ...

[tmeysson]

It's X86_64, a Celeron I think.

Supposing you wanted to package it, it would be bad practise to add the libs seeing as this should be dealt with through the package dependencies. That leaves the problem of library versions, but you'll run into that sooner or later because the libs you need also have their dependencies. So you end up having to target package versions for a specific distro release, I think.

By the way, I got it wrong: this is XUbuntu-14.04, not 17.10. I haven't upgraded my server yet. I might try to compile it on my laptop to check it doesn't break on the latest version, if it can help. I can try pruning the libs as well in that case, and make a list of what deps can be met through package management.

Le 2 mars 2018 13:07:48 CET, toxtox notifications@github.com a écrit :

Thanks for your experiences! One question: Is your NIC server powered by an ARM-CPU or an X86-64 CPU?

1. I guess it is an portable issue I had only two systems on which I could try the portability of the binary releases (two raspberry pis and two X86-64 machines). I tryed to make is as portable as possible by supplying/putting all required libs in the "_shared_libsactive" subdirectory. You could try to delete some of the libs in "_shared_libsactive" subdirectory one by one. Then the PHS-wallet tries to use your system libs (if installed). This should be more stable but less portable.

... some more infos later ...

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/toxtox/philosopherstone/issues/1#issuecomment-369904490

[toxtox]

Updating your system might help, because I compiled the release on Ubuntu 16.04. If your system is newer then 16.04 it should work, too. Yes you are right, supplying shared libs that have their own dependencies is not the usual way of publishing a release but I did not succeed to compile a fully static binary. But this practice should work if the required system libs are installed and are not too old. For comparison you will have round about 50 directly needed shared libs if you compile the wallet just normally. (=> absolutely not portable) So I tried to link the all libs statically but some libs could not be linked statically and these libs you can find in the _"shared_libsactive" subdirectory.

[tmeysson]

Yes, well, I'm not going to upgrade this system just yet seeing as it's also used as a Web server, a Tor node, and a headless host for my musical projects (none the least an MPD server I use everyday for quadriphonic rendering of the music I listen to). If you want to test that against different hardware and software architectures, I suggest that virtual machines are a solution. Development is full of people who couldn't possibly afford the hardware they're building for.

This being said, it's probably a good choice to rely mostly on static linking if you want your application to be as portable as possible with minimal casuistics on platform definition. But if you want to take it to the next level of multiplatform development, you'll have to think of packaging, which is going to involve separating the program's own logic from the software dependencies available in such or such distribution. Porting the whole stuff to Linuxes might involve a major version change, because you'll need to make abstraction of what's Windows-specific and leave that to optional code, reworking the architecture as needed. I'm ready to give some help about that, being specifically interested.

Also (though this is more of a feature request), I think it would be better to think in terms of client-server architecture, because you might want to have the wallet minting at all times, but you don't want it to be open for transfers except when necessary. The former could be undertaken by a background process, and the latter might be hapening via a GUI on a remote machine. It's probably hard to dissociate business logic from man-machine interface though, might take a complete rewrite. The fact that the console exists is a good indication, if access to the console can be made secure, and headless operation is possible, then Bob's your uncle :-)

Whew ! That's a lot of stuff, so don't take it as an urge for action, but rather some food for thought. And as I said, I'm willing to help if I can.

Thanks for your work, T

Le 2 mars 2018 21:41:34 CET, toxtox notifications@github.com a écrit :

Updating your system might help, because I compiled the release on Ubuntu 16.04. If your system is newer then 16.04 it should work, too. Yes you are right, supplying shared libs that have their own dependencies is not the usual way of publishing a release but I did not succeed to compile a fully static binary. But this practice should work if the required system libs are installed and are not too old. For comparison you will have round about 50 directly needed shared libs if you compile the wallet just normally. (=> absolutely not portable) So I tried to link the all libs statically but some libs could not be linked statically and these libs you can find in the _"shared_libsactive" subdirectory.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/toxtox/philosopherstone/issues/1#issuecomment-370046391

[toxtox]

to 2. and 3.) You can find the build instructions and dependencies in "/doc/build-unix.txt" and if you want compile with QT-GUI you will find additional informations in "/doc/readme-qt.rst" I am little bit surprised that you do not need the _"$$BDB_LIBSUFFIX" of _"LIBS += -ldb_cxx$$BDB_LIBSUFFIX" entry because as I know only Berkeley DB 4.8 is supported by PHS-wallet. So I hardcoded the version: _"BDB_LIBSUFFIX = -4.8" Do you use a different version of Berkeley DB that runs with PHS-wallet?

[tmeysson]

Tried a proper compilation of philosopherstone-qt on my UbuntuStudio17.10 laptop, seems to run fine (though the release version seems to run fine too). Attached the relevant parts of the transcript. philosopherstone-build.log As you can see it seems to be using libdb5.3++, and that doesn't cause the application to malfunction -- yet. I'm currently trying to load blockchain.dat, of course this is going to take some time. Starting it without doing that simply causes it to report it is out of sync and 4 years behind, but probably catching up.

[tmeysson]

Sorry about my comments about it not being a client/server app, now you told me where to find the build instructions I see this is not true. Apparently the daemon suits my needs perfectly, except it doesn't seem to recognize the UPnP client, so I'll have to do without that. It's not complaining about ports not being open, but then I haven't looked much either. How important is that ?

[toxtox]

If you want to run your PHS-wallet/daemon as a "full node" you have two options:

1. enable UPNP in your router and enable UPNP in your "Philosopherstone.conf" (if you do not have this file, you must create this configuration file in your "walled.dat"-directory, note the capital "P" of "Philosopherstone.conf") Just write

   # [network]
   upnp=1
   listen=1

   in this file.

2. Just do the same as described in 1. but do not enable UPNP in your router, instead open the port 16281 manually in your router for the LAN-IP-address of your server. (This is what I have done because of security concerns with active UPNP in my router)

Running your PHS-wallet/daemon as a "full node" means that you do not have only outbound connections (max. 8) you will have additional inbound connections for supporting the network (you will upload your copy of the database/blockchain to other users). This is especially very important for small coins like Philosopherstone to survive.