-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
https://github.com/doublethinkco/webthree-umbrella-cross/releases/tag/eth.151123231644.tgz Libs don't look compatible. [root@Jolla bin]# strace ./eth console |
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! |
These are the system calls, but how is this path, for example, being constructed? /home/nemo/eth/lib/tls/neon/libmicrohttpd.so.10 |
Hmm. Path issue perhaps? |
|
Why is it looking in /home/nemo/eth/lib/tls/neon/, though? Again, please excuse my ignorance of what the loader/linker behaviour is at this point, and talk to me like an undergrad! |
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? |
So is that sequence of errors just ld.so trying its set of built-in LD paths? |
Would dumping all the SOs in the same directory as the executable make a difference? |
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 not sure about the tls/neon/ bits. On Tue, Nov 24, 2015 at 10:13 PM, Bob Summerwill [email protected]
|
Could this be as simple as the armel vs armhf? |
sailfish libcurl Attribute Section: aeabi docker built libcurl Attribute Section: aeabi So docker toolchain is nowhere near On Tue, Nov 24, 2015 at 10:48 PM, Bob Summerwill [email protected]
|
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? |
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. |
Agree strange it does not give any warning but last thing it does is read 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.
|
Now I have a top level view of the codebase I"ll try a native build using Welcome to ARM
|
Thank you!
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. |
geth is whirring away on the nexus 5 sailfish now so that looks like a good Its also a static executable so no dynamic linking to complicate. [nemo@Jolla ~]$ readelf -A geth On Wed, Nov 25, 2015 at 12:26 AM, Bob Summerwill [email protected]
|
So very, very similar to the Docker eth one, eh? Just Tag_CPU_name different, is probably the "breaker". Also, geth has: |
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 |
geth is a statically linked binary so does not involve dynamic linker, this On Wed, Nov 25, 2015 at 12:39 AM, Bob Summerwill [email protected]
|
Could be! Found this too - http://stackoverflow.com/questions/12963209/why-does-arm-linux-gnueabi-g-4-4-always-build-a-7-a-binary |
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. |
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 :-) |
DONE! |
cinemast/libjson-rpc-cpp#143 helps with catch dependency |
OK yes. I'll try compiling with -DCOMPILE_TESTS=NO |
For the record my lab notes and patches to upstream umbrella
|
webthree-umbrella was built on device after installing dependencies from OBS https://build.merproject.org/project/show/home:vgrade:ethereum TODO :
|
Awesome! Thanks so much, @martinbrook. See also #11 |
Pull request to address unconditional use of JSRemoteConsole in main.cpp of eth: |
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?
|
Cross-building of flu: #55 |
Seeing this warning ;- ''' 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 |
I'm using the same as upstream here so not sure of the question |
|
@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! |
@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. |
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 ⚡ 17:57:15.102|eth Stop worker 13986 ms |
Hey @martinbrook ! 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! |
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 |
Hey @martinbrook! Happy New Year. |
No description provided.
The text was updated successfully, but these errors were encountered: