I'm writing a smart contract and want to know which external crates will work and which won't. I don't want to go through the trouble of importing them into my contracts and checking if everything compiles properly every time I want to use a crate.
As an example, say I wanted to use the rand crate but then found out it wasn't compatible. How could I check this beforehand?
As a general rule of thumb, anything that supports wasm32-unknown-unknown will be compatible with your smart contract. An easy way to check this is by going to crates.io and checking there. In your example, when going to the rand page and doing a quick find all for wasm32, you can see at the bottom that wasm32-unknown-unknown is not "automatically supported":
This is a good rule to follow, but there are edge cases where a crate might compile to wasm32 but fail at runtime for incompatible functionality.
Related
It's trivial to call c from rust normally, is there a way to do so from a substrate project? I can't find anything online saying it's possible or it's not possible.
I have a c library I'd like to use as part of a substrate project and I was wondering if it would be possible to use it without rewriting it.
Many FFI libraries are no_std compliant, this is the only hard requirement for being used in substrate runtimes. Checkout the list here and look for that tag for options to move forward:
https://lib.rs/development-tools/ffi
If you are using this library outside the runtime, you should be able to use any rust library.
I've introduced Boost.Container into my project which uses jemalloc as default allocator, looks like Boots.Container uses custom allocator which is dlmalloc and of course when linking I'm failing on "multiple definition" linkage error since two "XXXalloc" were introduced into object files. Turning the 'jemalloc' off is not an option but I cant find if it is possible to turn off the dlmalloc usage. Any idea how to solve this problem?
In reality, Boost Container is 99% header-only.
The documentation lists the DLMalloc extension as an extension: https://www.boost.org/doc/libs/1_73_0/doc/html/container/extended_allocators.html
This means you have apparently opted in to the extended allocator. If that's not what you wanted, you know what to remove.
A good hint is when you don't need to link Boost Container, as a quick inspection of the symbols exported didn't show me anything I recognize except allocator stuff.
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
I wish to sell Go application. I will provide serial number to my clients. Is there ways to make it a bit more complex to crack app?
I say it is complex to crack C app and it is easy to crack Java app. Is there tools that will make Go app cracking job as hard as cracking C app? or some tutorial? At least something I could do to protect my project a bit. I do not ask about super heavy protection.
Once you have the binary itself, obfuscation is pretty difficult. People have tried stripping the symbols out of Go binaries before, but it usually leads to instability and unpredictable behavior, since symbols are required for certain reflection operations.
While you can't necessarily obfuscate the libraries you're statically linking against, you can certainly obfuscate your /own/ code by changing variable, type, and function names prior to compilation to names that are meaningless. If you want to go one step further, you can try obtaining the source code for the libraries you're using (the source code for the standard libraries is available and is included in most Go installations), and applying this obfuscation to the library source code as well.
As for post-compilation binary modification, as I mentioned before, it's probably best to stay away from it.
To add on joshlf13's answer: while stripping Go binaries is not recommended, there's a flag you can pass to the linker to omit the debugging symbols all along:
Pass the '-s' flag to the linker to omit the debug information (for example, go build -ldflags "-s" prog.go).
(Debugging Go Code with GDB)
This should at least be a better way, since I haven't seen any warnings for this like the ones about stripping symbols post-compilation.
Another option, with Go 1.16+ (Feb. 2021:
burrowers/garble
Produce a binary that works as well as a regular build, but that has as little information about the original source code as possible.
The tool is designed to be:
Coupled with cmd/go, to support modules and build caching
Deterministic and reproducible, given the same initial source code
Reversible given the original source, to de-obfuscate panic stack traces
That might not be obfuscated enough for your need, but it is a good start.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.