dank (Mar 15 2023 at 08:56): dank (Mar 15 2023 at 08:56):As it turns out, I can compile a platform file + app file (2 .roc only files) into a shared lib
but question is, with a package module (ig), could it be possible to have only the one roc file?
i tried and got parsing error on the packages {}
Anton (Mar 15 2023 at 08:58):No, I think there always has to be a platform
dank (Mar 15 2023 at 08:58):ik this sounds a bit silly and (maybe?) goes against the platform/app idea
just wondering
dank (Mar 15 2023 at 08:58):uh ok
dank (Mar 15 2023 at 09:40):roc build --lib should bundle the c file if it's called host.c into the shared object, no?
dank (Mar 15 2023 at 09:43):looking at the objdump of it, i don't see all the symbols i defined
dank (Mar 15 2023 at 09:58):ok yea this is funky
when compiling with --lib, no roc_alloc on the shared object
when compiling without it (as in to an executable), it's there
is this intended and im missing something or a bug?
Anton (Mar 15 2023 at 10:10):I'm not sure, could you make an issue for this: "[...] got parsing error on the packages {}"?
We should have a better error message there.
dank (Mar 15 2023 at 10:28):sure
Anton (Mar 15 2023 at 10:28):Thanks :)
dank (Mar 15 2023 at 10:29):i think i misinterpreted --lib
apparently the point is "host comes later"
while i thought "with this i could bundle up my roc app + platform into a shared object instead of executable"
dank (Mar 15 2023 at 10:30):in theory it would've made
clang \
-c -fPIC \
-I"$JAVA_HOME/include" \
-I"$JAVA_HOME/include/linux" \
-o bridge.o bridge.c
# build interop
clang -shared -o libinterop.so bridge.o -L. -lhello
these two build steps + two shared object (instead of one) obsolete (imagine bridge as host)
but uhh i get it
Brendan Hansknecht (Mar 15 2023 at 14:35):So outputs you can get from roc:
roc build main.roc -> roc will compile the platform and link to it. End result is an executable.roc build --lib main.roc -> roc will output a shared library of the roc part of the code. This can be loaded by another executable and is how runtime plugins work.roc build --no-link main.roc -> roc will output a regular object file of the roc part of the code. This can be used by any other build system or passed to a linker just like an object file you get from a c compiler. This is needed for targeting embedded devices or more complex builds where you want another system to ingest roc.In all of the cases. Even though you just pass main.roc to the compiler. It will be traversing all of the files imported by main.roc. All roc files from the platform, builtins, interfaces and packages will be compiled into the final binary. I am not fully sure what level of tree shaking we do vs llvm does, but it should not have extraneous functions that you don't use.
Brendan Hansknecht (Mar 15 2023 at 14:37):Roc can not add the platform to a shared library because the platform should be a full application with a main function. A main function doesn't make sense in a shared library.
dank (Mar 15 2023 at 14:37):Brendan Hansknecht said:
Roc can not add the platform to a shared library because the platform should be a full application with a main function. A main function doesn't make sense in a shared library.
yea exactly
dank (Mar 15 2023 at 14:38):Brendan Hansknecht said:
So outputs you can get from roc:
roc build main.roc-> roc will compile the platform and link to it. End result is an executable.roc build --lib main.roc-> roc will output a shared library of the roc part of the code. This can be loaded by another executable and is how runtime plugins work.roc build --no-link main.roc-> roc will output a regular object file of the roc part of the code. This can be used by any other build system or passed to a linker just like an object file you get from a c compiler. This is needed for targeting embedded devices or more complex builds where you want another system to ingest roc.In all of the cases. Even though you just pass
main.rocto the compiler. It will be traversing all of the files imported bymain.roc. All roc files from the platform, builtins, interfaces and packages will be compiled into the final binary. I am not fully sure what level of tree shaking we do vs llvm does, but it should not have extraneous functions that you don't use.
third one is super cool, didn't know about that
ill try to make use of it
Brendan Hansknecht (Mar 15 2023 at 14:38):I guess in your case you have a platform that is not a full application due to being for cffi and getting pulled into another language. Roc simply doesn't yet have a plan for that you case. We should be able to support it though. Not sure exactly the best way though.
dank (Mar 15 2023 at 14:39):after you mentioned --no-link i was thinking
compile the roc side into an object file
then just use clang to link the object file (+host.c) into the final shared object which the jvm would use
this eliminates the need for a secondary shared lib like i had til now
Brendan Hansknecht (Mar 15 2023 at 14:44):yep. should work
Last updated: Jul 06 2025 at 12:14 UTC