Compile solc for the JVM/Java

[axic]

See ethereum/EIPs#209 (comment).

(Low priority.)

[axic]

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

[roadriverrail]

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> .

[axic]

If someone picks up the task, yes 😉

[roadriverrail]

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> .

[federicobond]

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 solc executable and read it's standard JSON output (perhaps with a thin Java wrapper to make things nice) it should be fine.

I mention this because those platform-dependent Maven builds may be easier to create and maintain than a full JNI bridge.

[axic]

Note, GCC-Bridge above is like Emscripten, it compiles C/C++ (actually compiles GCC's Gimple IR) to Java bytecode. It wouldn't be JNI or executing an application, rather native code.

There are two steps to this:

• build a GCC-Bridge docker and tie it into a Travis build step
• ensure the jsonCompiler API (at least compileStandard) is exported in Java and works (this might need a tiny wrapper to convert between native types of Java, such as String)

[roadriverrail]

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 NameAndTypeResolver.cpp , RPCSession.cpp and AsmPrinter.cpp. The NameAndTypeResolver.cpp and RPCSession.cpp breaks are probably a simple fix, but the AsmPrinter.cpp break appears to actually be caused by using a copy of boost that wants gcc > 4.7.

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.

[roadriverrail]

@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&)’:
/home/rhett/solidity/build/deps/jsoncpp/src/jsoncpp-project/src/lib_json/json_value.cpp:273:78: error: conversion to ‘unsigned char:2’ from ‘unsigned int’ may alter its value [-Werror=conversion]
/home/rhett/solidity/build/deps/jsoncpp/src/jsoncpp-project/src/lib_json/json_value.cpp: In constructor ‘Json::Value::Value(Json::ValueType)’:
/home/rhett/solidity/build/deps/jsoncpp/src/jsoncpp-project/src/lib_json/json_value.cpp:346:27: warning: declaration of ‘empty’ shadows a member of 'this' [-Wshadow]
cc1plus: some warnings being treated as errors
src/lib_json/CMakeFiles/jsoncpp_lib_static.dir/build.make:86: recipe for target 'src/lib_json/CMakeFiles/jsoncpp_lib_static.dir/json_value.cpp.o' failed
make[5]: *** [src/lib_json/CMakeFiles/jsoncpp_lib_static.dir/json_value.cpp.o] Error 1

[axic]

@roadriverrail that's weird because we only use a fixed version of jsoncpp, which hasn't changed in a while.

[roadriverrail]

@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> .

[axic]

There weren't many asks for such a feature over the years, so I think it is safe to close it.