Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Sailfish OS #21

Closed
anthony-cros opened this issue Nov 18, 2015 · 49 comments
Closed

Support Sailfish OS #21

anthony-cros opened this issue Nov 18, 2015 · 49 comments
Assignees
Labels

Comments

@anthony-cros
Copy link
Member

No description provided.

@martinbrook
Copy link

https://github.com/doublethinkco/webthree-umbrella-cross/releases/tag/eth.151123231644.tgz

Libs don't look compatible.

[root@Jolla bin]# strace ./eth console
execve("./eth", ["./eth", "console"], [/* 40 vars */]) = 0
brk(0) = 0x17a1000
uname({sys="Linux", node="Jolla", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f55000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/v7l/neon/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/v7l/neon/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/v7l/neon/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/v7l/neon", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/v7l/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/v7l/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/v7l/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/v7l", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/neon/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/neon/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/neon/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/neon", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/tls/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/tls", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/v7l/neon/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/v7l/neon/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/v7l/neon/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/v7l/neon", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/v7l/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/v7l/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/v7l/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/v7l", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/neon/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/neon/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/neon/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/neon", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/vfp/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/home/nemo/eth/lib/vfp", 0xbeff7ec8) = -1 ENOENT (No such file or directory)
open("/home/nemo/eth/lib/libmicrohttpd.so.10", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\364\37\0\0004\0\0\0"..., 512) = 512
lseek(3, 248016, SEEK_SET) = 248016
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1440) = 1440
lseek(3, 70829, SEEK_SET) = 70829
read(3, "A0\0\0\0aeabi\0\1&\0\0\0\5ARM10TDMI\0\6\3\10\1\t"..., 49) = 49
exit_group(1) = ?
+++ exited with 1 +++
[root@Jolla bin]#

@bobsummerwill
Copy link
Member

Hey @martinbrook! Thanks for that test.

Please excuse my Linux ignorance here, but please could you explain what is happening here? The TGZ has an executable and SOs. What exactly is the OS doing at this point? What degree of versioning or "hinting" is there in the ELF format?

I'm guessing that armel vs armhf is important, but what else have we got going on which will need lining up? Thanks!

@bobsummerwill
Copy link
Member

These are the system calls, but how is this path, for example, being constructed?

/home/nemo/eth/lib/tls/neon/libmicrohttpd.so.10

@bobsummerwill
Copy link
Member

Hmm. Path issue perhaps?
There is that whole LIB directory parallel to the BIN directory inside the TGZ.

@martinbrook
Copy link

Hmm. Path issue perhaps?
There is that whole LIB directory parallel to the BIN directory inside the
TGZ.

Already added the LD library path to the lib directory as it failed
initially with can't find libmicrohttpd


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

Why is it looking in /home/nemo/eth/lib/tls/neon/, though?
Rather than in the local LIB/ directory where there should be a libmicrohttpd.so.10?

Again, please excuse my ignorance of what the loader/linker behaviour is at this point, and talk to me like an undergrad!

@bobsummerwill
Copy link
Member

So it fell over on libmicrohttpd.so, you added the library path, and then it falls over on libmicrohttpd.so.10? And the .10 suffix is a versioning element, right? Which is specified directly within the symbolic links in the ELF? Are both of the SOs used?

@bobsummerwill
Copy link
Member

So is that sequence of errors just ld.so trying its set of built-in LD paths?
Does the search start in the current directory?
And then try PATH? And then these built-ins?
Was it PATH you had to prepend that LIB directory to? Or some other variable?

@bobsummerwill
Copy link
Member

Would dumping all the SOs in the same directory as the executable make a difference?

@martinbrook
Copy link

I added the path to LD_LIBRARY_PATH env variable.

I used ldd to see if that recognised the so files, it did not, which means
the dynamic linker would not be able to resolve

not sure about the tls/neon/ bits.

On Tue, Nov 24, 2015 at 10:13 PM, Bob Summerwill [email protected]
wrote:

Would dumping all the SOs in the same directory as the executable make a
difference?


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

Could this be as simple as the armel vs armhf?
Any insight into that this kind of error message USUALLY means?

@martinbrook
Copy link

Ref:
http://www.cnx-software.com/2013/04/22/how-to-detect-if-an-arm-elf-binary-is-hard-float-armhf-or-soft-float-armel/

sailfish libcurl

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6

docker built libcurl

Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM10TDMI"
Tag_CPU_arch: v5T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_DIV_use: Not allowed

So docker toolchain is nowhere near

On Tue, Nov 24, 2015 at 10:48 PM, Bob Summerwill [email protected]
wrote:

Could this be as simple as the armel vs armhf?
Any insight into that this kind of error message USUALLY means?


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

So then presumably when ld.so is running for any particular platform is has some set of minimum requirements for that ABI compatibility, and will just skip binaries in LD_LIBRARY_PATH which don't meet those minimum requirements? Rather than giving a hard error, like ...

"libmicrohttpd.so in ~/LIB is ABI incompatible" or whatever?

@bobsummerwill
Copy link
Member

So how do we determine those minimum requirements for a given distro/platform?

They are currently nowhere near because we have made no effort (yet) to make them so. This is the very first run :-)

Do you know off-hand what the minimum requirements WOULD be for getting to a compatible binary? Maybe the first step is for me to just get that armhf configuration building a binary, and then for us to look what comes out of the other end.

@martinbrook
Copy link

So then presumably when ld.so is running for any particular platform is
has some set of minimum requirements for that ABI compatibility, and will
just skip binaries in LD_LIBRARY_PATH which don't meet those minimum
requirements? Rather than giving a hard error, like ...

"libmicrohttpd.so in ~/LIB is ABI incompatible" or whatever?

Agree strange it does not give any warning but last thing it does is read
the elf header

read(3, "A0\0\0\0aeabi\0\1&\0\0\0\5ARM10TDMI\0\6\3\10\1\t"..., 49) = 49

which has the wrong cpu name and exits.

Running ldd elicits a warning though.


Reply to this email directly or view it on GitHub
#21 (comment)
.

@martinbrook
Copy link

So how do we determine those minimum requirements for a given
distro/platform?

Good question, I've always tried to match the toolchain. As you can see
there are many more variants on the arm side of things. I've not considered
a minimum set.

They are currently nowhere near because we have made no effort (yet) to
make them so. This is the very first run :-)

Sorry if that sounded harsh, it was not meant to be.

Do you know off-hand what the minimum requirements WOULD be for getting to
a compatible binary? Maybe the first step is for me to just get that armhf
configuration building a binary, and then for us to look what comes out of
the other end.

Compatible with what ? sailfish, ubuntu touch, android, SoC versions. As I
said before I've always tried to use the same toolchain as the rest of the
platform.

Now I have a top level view of the codebase I"ll try a native build using
the Mer/Sailfish SDK.

Welcome to ARM


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

Welcome to ARM

Thank you!

As you can see there are many more variants on the arm side of things. I've not considered
a minimum set. Compatible with what ? sailfish, ubuntu touch, android, SoC versions.
As I said before I've always tried to use the same toolchain as the rest of the platform.

Well - for the stage we are in right now of trying to get cross-built eth binaries working on anything, as broad a range of platforms as possible initially. If there is some really crappy-low spec which works across a large range of ARM devices (mobile/wearable/SBC) then that would be a big win for getting some kind of broad range of coverage. Even if they are very suboptimal for performance, it lets us work through other crap like the pre-main() statics which we are hitting in Tizen and other "tidy up".

Native binaries will always be best, and even for cross-builds I am sure that we will want a perfect match on toolchain EVENTUALLY, but if we can make binaries which can be used across multiple ARM platforms now, that helps us do more in parallel.

@martinbrook
Copy link

geth is whirring away on the nexus 5 sailfish now so that looks like a good
stating point.

Its also a static executable so no dynamic linking to complicate.

[nemo@Jolla ~]$ readelf -A geth
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5T"
Tag_CPU_arch: v5T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int

On Wed, Nov 25, 2015 at 12:26 AM, Bob Summerwill [email protected]
wrote:

Welcome to ARM

Thank you!

As you can see there are many more variants on the arm side of things.
I've not considered
a minimum set. Compatible with what ? sailfish, ubuntu touch, android, SoC
versions.
As I said before I've always tried to use the same toolchain as the rest
of the platform.

Well - for the stage we are in right now of trying to get cross-built eth
binaries working on anything, as broad a range of platforms as possible
initially. If there is some really crappy-low spec which works across a
large range of ARM devices (mobile/wearable/SBC) then that would be a big
win for getting some kind of broad range of coverage. Even if they are very
suboptimal for performance, it lets us work through other crap like the
pre-main() statics which we are hitting in Tizen and other "tidy up".

Native binaries will always be best, and even for cross-builds I am sure
that we will want a perfect match on toolchain EVENTUALLY, but if we can
make binaries which can be used across multiple ARM platforms now, that
helps us do more in parallel.


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

So very, very similar to the Docker eth one, eh?

Just Tag_CPU_name different, is probably the "breaker".

Also, geth has:
Tag_ABI_FP_rounding: Needed
eth has:
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_DIV_use: Not allowed

@bobsummerwill
Copy link
Member

Especially based on you seeing that read and then it exiting:

read(3, "A0\0\0\0aeabi\0\1&\0\0\0\5ARM10TDMI\0\6\3\10\1\t"..., 49) = 49

@martinbrook
Copy link

geth is a statically linked binary so does not involve dynamic linker, this
may be the difference?

On Wed, Nov 25, 2015 at 12:39 AM, Bob Summerwill [email protected]
wrote:

Especially based on you seeing that read and then it exiting:

read(3, "A0\0\0\0aeabi\0\1&\0\0\0\5ARM10TDMI\0\6\3\10\1\t"..., 49) = 49


Reply to this email directly or view it on GitHub
#21 (comment)
.

@bobsummerwill
Copy link
Member

@bobsummerwill
Copy link
Member

What geth working on Sailfish hints at to me, though, is that armel binaries CAN be used on armhf platforms.

There is obviously a bunch of tweakiness in there, but is it NOT as black-and-white as armel vs armhf binaries and never the twain shall meet.

@bobsummerwill
Copy link
Member

@bobsummerwill
Copy link
Member

@bobsummerwill
Copy link
Member

BTW - Just realizing that all of this is in a bug for GETH, where most of it is build issues for ETH, but never mind :-) I'll tidy up the bugs later when we actually get an ETH binary to iterate on :-)

@bobsummerwill bobsummerwill changed the title Get to a working eth ARM binary for Sailfish OS Get to a working eth binary for Sailfish OS Nov 25, 2015
@bobsummerwill bobsummerwill added eth and removed geth labels Nov 25, 2015
@bobsummerwill
Copy link
Member

DONE!

@bobsummerwill bobsummerwill removed the eth label Nov 28, 2015
@bobsummerwill bobsummerwill changed the title Get to a working eth binary for Sailfish OS Support Sailfish OS Nov 29, 2015
@martinbrook
Copy link

#10 (comment)

@bobsummerwill bobsummerwill added bug and removed feature labels Nov 30, 2015
@martinbrook
Copy link

cinemast/libjson-rpc-cpp#143 helps with catch dependency

@phonikg
Copy link
Contributor

phonikg commented Nov 30, 2015

OK yes. I'll try compiling with

-DCOMPILE_TESTS=NO

@martinbrook
Copy link

For the record my lab notes and patches to upstream umbrella

install gcc, gcc-g++, make, cmake (OBS) (3.0.2), git
install boost (OBS) (1.55)
install gmp
install jsoncpp (OBS)
install leveldb (OBS)
install snappy (OBS)
install cryptopp (OBS)
install miniupnpc (OBS)
install libmicrohttpd (OBS)
install libjson-rpc-cpp (OBS)
install snappy (OBS)

https://github.com/ethereum/webthree-umbrella/wiki/Linux--Generic-Building
    cd webthree-umbrella
    patches below 
    mkdir build
    cd build
    cmake .. -DEVMJIT=0 -DETHASHCL=0 -DGUI=0 -DSOLIDITY=0 -DTESTS=0 -DTOOLS=0 -DETH_JSON_RPC_STUB=OFF
    make 

PATCHES

[nemo@Jolla webthree-umbrella]$ cd webthree-helpers/
[nemo@Jolla webthree-helpers]$ git diff
diff --git a/cmake/EthCompilerSettings.cmake b/cmake/EthCompilerSettings.cmake
index 8128e0e..59b9585 100644
--- a/cmake/EthCompilerSettings.cmake
+++ b/cmake/EthCompilerSettings.cmake
@@ -3,7 +3,7 @@
 # C++11 check and activation
 if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")

-       set(CMAKE_CXX_FLAGS "-std=c++11 -Wall -Wno-unknown-pragmas -Wextra -Werror -pedantic -DSHAREDLIB -fPIC ${CMAKE_CXX_FLAGS}")
+       set(CMAKE_CXX_FLAGS "-std=c++11 -Wall -Wno-unknown-pragmas -Wextra -pedantic -DSHAREDLIB -fPIC ${CMAKE_CXX_FLAGS}")
        if (GCC_VERSION VERSION_GREATER 4.9 OR GCC_VERSION VERSION_EQUAL 4.9)
                set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstack-protector-strong -Wstack-protector")
        endif()
diff --git a/cmake/FindEth.cmake b/cmake/FindEth.cmake
index 31a07f2..03fd1d8 100644
--- a/cmake/FindEth.cmake
+++ b/cmake/FindEth.cmake
@@ -8,7 +8,7 @@
 #  TODO: ETH_INCLUDE_DIRS

 include(EthUtils)
-set(LIBS ethashseal;ethereum;evm;ethcore;lll;evmasm;evmcore;ethash-cl;ethash;natspec;jsengine;jsconsole;evmjit;solidity;testutils)
+set(LIBS ethashseal;ethereum;evm;ethcore;lll;evmasm;evmcore;ethash-cl;ethash;natspec;evmjit;solidity;testutils)

 set(Eth_INCLUDE_DIRS "${ETH_DIR}")

diff --git a/cmake/UseWeb3.cmake b/cmake/UseWeb3.cmake
index 96a6d82..861b715 100644
--- a/cmake/UseWeb3.cmake
+++ b/cmake/UseWeb3.cmake
@@ -27,14 +27,14 @@ function(eth_apply TARGET REQUIRED SUBMODULE)
        endif()

        if (${SUBMODULE} STREQUAL "jsengine")
-               eth_use(${TARGET} ${REQUIRED} V8)
-               target_link_libraries(${TARGET} ${Web3_JSENGINE_LIBRARIES})
+               #eth_use(${TARGET} ${REQUIRED} V8)
+               #target_link_libraries(${TARGET} ${Web3_JSENGINE_LIBRARIES})
        endif()

        if (${SUBMODULE} STREQUAL "jsconsole")
-               eth_use(${EXECUTABLE} ${REQUIRED} Web3::jsengine Dev::devcore JsonRpc::Server JsonRpc::Client)
-               eth_use(${EXECUTABLE} OPTIONAL Readline)
-               target_link_libraries(${TARGET} ${Web3_JSCONSOLE_LIBRARIES})
+               #eth_use(${EXECUTABLE} ${REQUIRED} Web3::jsengine Dev::devcore JsonRpc::Server JsonRpc::Client)
+               #eth_use(${EXECUTABLE} OPTIONAL Readline)
+               #target_link_libraries(${TARGET} ${Web3_JSCONSOLE_LIBRARIES})
        endif()


[nemo@Jolla webthree-umbrella]$ cd webthree
[nemo@Jolla webthree]$ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6f37a07..7c13e54 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,7 +3,7 @@ cmake_minimum_required(VERSION 2.8.12)
 set(ETH_CMAKE_DIR   "${CMAKE_CURRENT_LIST_DIR}/../webthree-helpers/cmake"   CACHE PATH "The the path to the cmake directory")

 list(APPEND CMAKE_MODULE_PATH ${ETH_CMAKE_DIR})
-set(JSCONSOLE 1)
+#set(JSCONSOLE 1)

 # Set cmake_policies
 include(EthPolicy)
@@ -33,13 +33,13 @@ add_subdirectory(libweb3jsonrpc)
 add_subdirectory(libwhisper)

 # other libs
-add_subdirectory(libjsengine)
-add_subdirectory(libjsconsole)
+#add_subdirectory(libjsengine)
+#add_subdirectory(libjsconsole)

 # executables
 add_subdirectory(eth)
 add_subdirectory(exp)
-add_subdirectory(flu)
+#add_subdirectory(flu)

 # test stuff
 add_subdirectory(test)
diff --git a/eth/main.cpp b/eth/main.cpp
index 3f456bf..da7f658 100644
--- a/eth/main.cpp
+++ b/eth/main.cpp
@@ -884,11 +884,11 @@ int main(int argc, char** argv)

        if (mode == OperationMode::Attach)
        {
-               JSRemoteConsole console(remoteURL);
-               if (!remoteSessionKey.empty())
-                       console.eval("web3.admin.setSessionKey('" + remoteSessionKey + "')");
-               while (true)
-                       console.readAndEval();
+               //JSRemoteConsole console(remoteURL);
+               //if (!remoteSessionKey.empty())
+               //      console.eval("web3.admin.setSessionKey('" + remoteSessionKey + "')");
+               //while (true)
+               //      console.readAndEval();
                return 0;
        }

diff --git a/libweb3jsonrpc/CMakeLists.txt b/libweb3jsonrpc/CMakeLists.txt
index d81c1f6..91a34c4 100644
--- a/libweb3jsonrpc/CMakeLists.txt
+++ b/libweb3jsonrpc/CMakeLists.txt
@@ -7,7 +7,7 @@ file(GLOB HEADERS "*.h")
 add_library(${EXECUTABLE} ${SRC_LIST} ${HEADERS})
[nemo@Jolla webthree]$ 
[nemo@Jolla webthree]$

@martinbrook
Copy link

webthree-umbrella was built on device after installing dependencies from OBS https://build.merproject.org/project/show/home:vgrade:ethereum

TODO :

  1. Package webthree-umbrella for OBS
  2. Introduce V8 to build - already packaged on OBS
  3. Introduce llvm to build - already packaged on OBS
  4. Resolve patches with upstream
  5. Resolve Boost conflict on device
  6. Run tests

@bobsummerwill
Copy link
Member

Awesome! Thanks so much, @martinbrook.

See also #11

@bobsummerwill
Copy link
Member

Pull request to address unconditional use of JSRemoteConsole in main.cpp of eth:
ethereum/webthree#89

@bobsummerwill
Copy link
Member

Hey @martinbrook!

Just looking at your lab notes, I'd like to try to summarize back to you what I think still needs upstreaming or resolving. Please could you confirm/deny my understanding?

  1. Various hacks for removing jsconsole and jsengine, which we had to do for cross-builds too. I imagine the build scripts are just missing some element of parameterization to support cleanly snipping this stuff out, as was clearly intentioned within the code.
  2. Not building flu. We're doing that too, but I wonder why. I'll log an issue on our side to try to cross-build flu as well. I don't see why that should be hard.
  3. Addition of stack-protector-strong and stack-protector GNU settings. I don't see any issue with those. Are those required in Sailfish? Or were you seeing warnings/errors? Or are those just settings which you normally use? Just wondering if this was needed or just desirable.
  4. Removing of warnings-as-errors. Obviously that isn't upstreamable. How many warnings are you seeing? Could we just try to fix them? That would be better, eh, now you have something which links.
  5. Please could you explain the diff in libweb3jsonrpc? Thanks!

@bobsummerwill
Copy link
Member

Cross-building of flu: #55

@martinbrook
Copy link

  1. Removing of warnings-as-errors. Obviously that isn't upstreamable. How many warnings are you seeing? Could we just try to fix them? That would be better, eh, now you have something which links.

Seeing this warning ;-

'''
[ 53%] Building CXX object libethereum/libevmasm/CMakeFiles/evmasm.dir/ConstantOptimiser.cpp.o
In file included from /home/nemo/upstream-umbrella/webthree-umbrella/libweb3core/libdevcore/CommonData.h:32:0,
from /home/nemo/upstream-umbrella/webthree-umbrella/libethereum/libevmasm/ConstantOptimiser.h:25,
from /home/nemo/upstream-umbrella/webthree-umbrella/libethereum/libevmasm/ConstantOptimiser.cpp:22:
/home/nemo/upstream-umbrella/webthree-umbrella/libweb3core/libdevcore/Common.h:85:2: warning: unused parameter ‘_c’ [-Wunused-parameter]
secure_vector(secure_vector const& _c) = default;
^
'''

Warnings should be disabled due to this pragma

ethereum/libweb3core@f7d34a5#diff-3b6e039ebcc0dec0512d4901f968a952R41

But I'm seeing this bug on earlier than 4.9 gcc's which sailfish may be tripping up on

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47347

https://forum.ethereum.org/discussion/2873/eth-fails-to-build-on-gentoo-linux-with-commonio-cpp-error also refers to same compilation warning

@martinbrook
Copy link

  1. Addition of stack-protector-strong and stack-protector GNU settings. I don't see any issue with those. Are those required in Sailfish? Or were you seeing warnings/errors? Or are those just settings which you normally use? Just wondering if this was needed or just desirable.

I'm using the same as upstream here so not sure of the question

@martinbrook
Copy link

  1. Odd it looks empty will look further

@bobsummerwill
Copy link
Member

@martinbrook RE: Those stack-protector ones. I was just looking at the diff wrong, and read the unmodified context BELOW your removal of -Werror as newly added code. Ignore me!

@bobsummerwill
Copy link
Member

@martinbrook Please could you explain the libweb3jsonrpc diff? Thanks!

I got a bunch of PRs merged in the week before heading off for vacation. Indeed, merging of our changes appears to be about the only change to the C++ code base since the start of December.

I would imagine we can get everything in, both from your changes here, and fixes to address our hacks for the cross-builds.

@bobsummerwill
Copy link
Member

Check it out, @martinbrook, @anthony-cros :-)

https://twitter.com/doublethink_co/status/677670129384165376

Crash shortly after is ...

Error initializing key manager: Dynamic exception type: std::runtime_error
std::exception::what: locale::facet::_S_create_c_locale name not valid

⚡ 17:57:15.102|eth Stop worker 13986 ms
... 17:57:15.175|eth Closing state DB
... 17:57:15.177|eth Closing blockchain DB
⚡ 17:57:15.229|eth Worker stopping 126 ms
*** Error in `./eth': double free or corruption (fasttop): 0x00f7ae98 ***
Aborted

@bobsummerwill
Copy link
Member

Hey @martinbrook !
What is the speed like on your native Sailfish OS binary for eth on Jolla Phone?
The cross-built one I am working on debugging is just AWFUL.
Can be like 10 mins before it gets to the MASTER password prompt.
Then it's just sitting there. Is it doing something? Maybe.
My SSH connection has died a few times, so maybe it will start block downloads in a bit.
Something is obviously very, very wrong with stalls or locks or something.
Just wondering what your experience was like with your native binaries?

Please could you share the Sailfish binaries you DID get working? I would like to compare-and-contrast on my device. You built the executable on-device, right? And the libs with OBS. How can I get all the bits easily? Thanks!

@bobsummerwill
Copy link
Member

OK - We have working Sailfish cross-builds.
There are further issues tracking testing for specific devices.
TODO - Testing native builds on Jolla Phone work #61 . Testing cross-built binaries work on Nexus 5 #60 .
And Jolla Tablet. #59

@bobsummerwill
Copy link
Member

See @martinbrook. I got the root of the warning which you needed to suppress here for your native SailfishOS build. I was getting the same issue with the installed GCC cross-tools, which must be a newer GCC version than in the crosstool-NG.

I've submitted a PR for it: ethereum/libweb3core#44

@bobsummerwill
Copy link
Member

Hey @martinbrook! Happy New Year.
Looking through these notes again, the only thing I'm missing in understanding your native build is what that diff in libweb3jsonrpc is doing, and for? I'm afraid I don't understand that diff format. Is it adding a line? Looks like that file is fine in Github, from what I can see. What exactly where you patching there? All the best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants