-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Compile solc for the JVM/Java #2309
Comments
It suggests using GCC-Bridge to compile C/C++ to Java: |
The goal here is to make it possible to compile solidity from Java?
…On Tue, Aug 1, 2017, 17:26 Alex Beregszaszi ***@***.***> wrote:
It suggests using GCC-Bridge to compile C/C++ to Java:
- https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge
- http://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html
- https://github.com/bedatadriven/gcc-bridge-example
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2309 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlhYGCLoIm74bswNwbRNQ0E59nY2O-zks5sT5gVgaJpZM4Nl0At>
.
|
If someone picks up the task, yes 😉 |
Well, I do have some good jvm and jni chops...
…On Tue, Aug 1, 2017, 21:01 Alex Beregszaszi ***@***.***> wrote:
If someone picks up the task, yes 😉
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2309 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlhYHZamcdXx3yTzbSUsZrKz9UeEDKpks5sT8p6gaJpZM4Nl0At>
.
|
The issue discussed in the original thread was being able to compile Solidity contracts from a JVM toolchain as easily as you currently can from Node.js, right? So perhaps there is no need to provide a full JNI interface to the C++ API. As long as a JVM app can fork to a native I mention this because those platform-dependent Maven builds may be easier to create and maintain than a full JNI bridge. |
Note, There are two steps to this:
|
Did a little bit of a feasibility study on this tonight. I cloned Renjin and built it to get a copy of gcc-bridge. gcc-bridge appears to work in two steps. The first step transforms GCC intermediate language into JSON via a GCC plugin. The second step takes the JSON files and attempts to generate Java classes that have equivalent semantics. I modified the CXX_FLAGS to load the plugin. Unforunately, the plugin only works for gcc 4.7 (and I think gcc 4.6). gcc 4.7 is older than gcc's full C++11 support. We can't build jsoncpp on that. Even after I modified the build system to use my usual gcc (5.4) for jsoncpp, it's not enough. We have build breaks in Even if we elected to fix these breaks, we'd basically be forcing ourselves to stay pre-C++11 in order to keep up gcc-bridge. Unless, of course, gcc-bridge were to support newer compilers. |
@axic asked for more detail of the errors. I guess since then there was something that changed in our json-cpp dependency, since it no longer compiles under gcc-4.7: /home/rhett/solidity/build/deps/jsoncpp/src/jsoncpp-project/src/lib_json/json_value.cpp: In copy constructor ‘Json::Value::CZString::CZString(const Json::Value::CZString&)’: |
@roadriverrail that's weird because we only use a fixed version of jsoncpp, which hasn't changed in a while. |
@axic it may have been that I somehow didn't previously clean up my build
cruft or had shoehorned in gcc use. This is somewhat consistent with my
prior experience with json-cpp, though, because I recently did a port of it
for my day job, and it expected full C++11, including gcc >= 4.9.
…On Tue, Aug 15, 2017 at 11:21 PM Alex Beregszaszi ***@***.***> wrote:
@roadriverrail <https://github.com/roadriverrail> that's weird because we
only use a fixed version of jsoncpp, which hasn't changed in a while.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2309 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlhYIgY9k4jTxeiUOLb60F2T55unLZFks5sYigHgaJpZM4Nl0At>
.
|
There weren't many asks for such a feature over the years, so I think it is safe to close it. |
See ethereum/EIPs#209 (comment).
(Low priority.)
The text was updated successfully, but these errors were encountered: