Stream: platform development

Topic: Trouble linking roc_realloc and friends

Isaac Van Doren (Mar 09 2024 at 05:14):

I am working on a platform where I compile the Roc code into a shared library and then build the final executable using cargo. Right now I can correctly access Roc functions defined in Roc, but functions like roc_realloc are not being linked properly:

nm libapp.so.1
...
000000000000c380 T roc__mainForHost_1_exposed_size
                 U roc_panic
                 U roc_realloc
000000000000f8d0 t Str_concat_7a93171d29c34145ace0bed7f158bc6f747d259f21a8119f90767f874eb48b94
...

Does anyone have ideas about what I might be doing wrong?

Isaac Van Doren (Mar 09 2024 at 05:29):

Here's the source

Brendan Hansknecht (Mar 09 2024 at 05:46):

Is the entire platform a shared library or just the roc code?

Isaac Van Doren (Mar 09 2024 at 05:48):

Just the roc code

Brendan Hansknecht (Mar 09 2024 at 06:01):

So roc_alloc and friends should be provided by the host binary that loads the shared library

Brendan Hansknecht (Mar 09 2024 at 06:01):

This is where passing in an explicit allocator would make this easier. Then you just pass it in instead of dealing with linking

Brendan Hansknecht (Mar 09 2024 at 06:02):

In this case, you need to make sure your rust app exposes those dynamic symbols for roc to depend on.

Hristo (Mar 09 2024 at 10:54):

I'm still a Roc beginner, but my conceptual understanding of the use-case here is that (i) the actual platform that's being used to compile the Roc code into a shared library and (ii) the final executable (i.e., a "host" in a way), could be both viewed as platform instances conforming to the same minimal interface which includes roc_realloc et al.

I imagine, if the implementations of roc_realloc et al differ semantically (in obvious - or not so much - ways) between the two platforms, this could lead to some unexpected behaviour down the line.

Isaac Van Doren (Mar 09 2024 at 15:30):

In this case, you need to make sure your rust app exposes those dynamic symbols for roc to depend on.

I’ll look into this, thanks!

Isaac Van Doren (Mar 09 2024 at 15:31):

This is where passing in an explicit allocator would make this easier. Then you just pass it in instead of dealing with linking

I’m not sure I understand this. How would this help/where would the allocator be passed?

Isaac Van Doren (Mar 09 2024 at 15:33):

I imagine, if the implementations of roc_realloc et al differ semantically (in obvious - or not so much - ways) between the two platforms, this could lead to some unexpected behaviour down the line.

There is just one platform here so that won’t be an issue.

Brendan Hansknecht (Mar 09 2024 at 17:42):

Instead of dealing with this linking stuff. roc__mainForHost... would just take a struct of function pointers as an argument.

Isaac Van Doren (Mar 09 2024 at 17:53):

Ah yeah that would be cool!

Isaac Van Doren (Mar 09 2024 at 17:54):

Adding RUSTFLAGS="-C link-args=-rdynamic" did the trick! :smiley:

Brendan Hansknecht (Mar 09 2024 at 19:25):

As a note, that will limit dead code elimination (IIRC). There are ways to specify specific symbols to expose that work better if that becomes an issue for you.

Isaac Van Doren (Mar 09 2024 at 20:52):

Good to know :check:

Last updated: Jul 26 2025 at 12:14 UTC