This repository has been archived by the owner on Feb 14, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 16
duplicate symbol error: memset, memcpy, memove and memcmp #82
Comments
Hm I think we don't need to either use rlibc nor define our own. I removing this declaration and corresponding |
Indeed! Could that fix be applied to the main branch, or are there some dependencies which would break upon removal? |
I would glad to merge that PR : ) |
I would be glad too if it were merged :-) |
Nope, feel free! |
On it! |
dforsten
added a commit
to lab10-coop/pwasm-std
that referenced
this issue
Feb 5, 2019
…y, memove and memcmp
Pull Request submitted! |
pepyakin
added a commit
that referenced
this issue
Feb 6, 2019
Fix for issue #82 - duplicate symbol error: memset, memcpy, memove an…
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
To finish the pwasm ERC777 implementation at https://github.com/lab10-coop/pwasm-erc777 I need to check for granularity, involving multiplications of U256 values.
Attempting to multiply U256 values in pwasm contracts currently causes link conflicts between rlibc and compiler_builtins.
It is easy to reproduce the errors with the pwasm-tutorials "step-5" example by just adding a multiplication with 3 to the "total_supply" function:
The reported errors:
Multiplying with 1, 2 and 4 do not reproduce the link error interestingly, neither does multiplication in the "step-0" project, unless a contract is added with at least one function with at least one return type (can be as simple as a bool) - so it may be triggered by using the pwasm-abi library.
Optimizations in the release builds make the issue appear and disappear depending on the setup, but removing the "--release" option reproduces the link error immediately, even in a build of the unmodified "step-0" pwasm-tutorial example.
I would like to help with tracing this issue down, it currently keeps me from finishing the erc777 implementation, but also from implementing a number of internal, math-heavy contracts in the pwasm environment.
The text was updated successfully, but these errors were encountered: