Skip to content
This repository has been archived by the owner on Feb 14, 2021. It is now read-only.

Fix for issue #82 - duplicate symbol error: memset, memcpy, memove an… #83

Merged
merged 2 commits into from
Feb 6, 2019

Conversation

dforsten
Copy link
Contributor

@dforsten dforsten commented Feb 5, 2019

Fix for issue #82

Multiplying two U256 values in a pwasm contract caused duplicate symbol link errors as a conflict between compiler_builtins and rlibc.

@parity-cla-bot
Copy link

It looks like @dforsten signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@NikVolf
Copy link
Collaborator

NikVolf commented Feb 5, 2019

Does it actually help with the issue?

ext_memset(dest, c, n)
}
} else {
extern crate rlibc;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think only this line should be removed, we'd better keep external memory ops for libc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried it locally and that single-line change alone fixes the link issue as well.
Should I make a new PR, or commit a revert?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, you can update this PR since it's not merged :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.
I think it would make sense to move this code into the top-level crate also (as a separate mod, but not a crate). I don't see any reason in the current granularity. Have a separated pwasm-libc crate for the purpose it serves currently has not too much sense to me.

Copy link
Contributor

@pepyakin pepyakin Feb 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yeah, it is a special feature, then we can probably comment this line indeed.

However, I'm having a hard time to understand/remember why would we need this feature in the first place. Substrate doesn't use these, nor these ext_* functions are provided by the pwasm runtime.

(That said, I don't have any objections from merging this as is)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change committed and passed the tests!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussions about refactoring the code should probably be done outside of this immediate bug fix PR. Right now I am just very eager to start multiplying U256 values in my pwasm contracts 😜.

@dforsten
Copy link
Contributor Author

dforsten commented Feb 5, 2019

Does it actually help with the issue?

Yes, it did fix the link errors described in issue #82 for me.

@dforsten
Copy link
Contributor Author

dforsten commented Feb 5, 2019

Is there anything I can do to get this PR over the finish line?

@pepyakin pepyakin merged commit ebed28c into openethereum:master Feb 6, 2019
@pepyakin
Copy link
Contributor

pepyakin commented Feb 6, 2019

Thank you!

@dforsten
Copy link
Contributor Author

dforsten commented Feb 6, 2019

Thank you!

Awesome, thanks for merging! :-)

@dforsten
Copy link
Contributor Author

dforsten commented Feb 6, 2019

Is there an estimate when this fix will be available on crates.io?
No pressure, I just would like to know if I should just wait, or work with forks for now.

I understand it would require version bumps to pwasm-abi and pwasm-ethereum as well, so I am fine with using forks for now if that is not planned at this point.

@NikVolf
Copy link
Collaborator

NikVolf commented Feb 6, 2019

Is there an estimate when this fix will be available on crates.io?
No pressure, I just would like to know if I should just wait, or work with forks for now.

I understand it would require version bumps to pwasm-abi and pwasm-ethereum as well, so I am fine with using forks for now if that is not planned at this point.

i did a minor update of pwasm-libc, so you can do cargo update -p pwasm-libc to apply changes

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants