It looks like some compiler things have changed since it was written (https://github.com/roc-lang/roc/pull/5120/files), and now the bridge.c
is referencing undefined symbols.
The symbols it's looking for are
roc__programForHost_1__InterpolateString_caller
roc__programForHost_1__MulArrByScalar_caller
roc__programForHost_1__Factorial_caller
but the ones that show up in the impl.o
are
0000000000003948 T _roc__programForHost_0_caller
0000000000003978 T _roc__programForHost_0_result_size
0000000000003988 T _roc__programForHost_0_size
0000000000003990 T _roc__programForHost_1_caller
0000000000003888 T _roc__programForHost_1_exposed
0000000000003878 T _roc__programForHost_1_exposed_generic
0000000000003898 T _roc__programForHost_1_exposed_size
00000000000039d8 T _roc__programForHost_1_result_size
00000000000039e8 T _roc__programForHost_1_size
00000000000039f0 T _roc__programForHost_2_caller
0000000000003a30 T _roc__programForHost_2_result_size
0000000000003a40 T _roc__programForHost_2_size
Is there a compiler flag I'm missing to get the function names added to the linker symbols?
Yeah....I think names were lost at some point. Not sure why.
Also, not sure if we have a bug filed for it or not
@Folkert de Vries I assume it was a glue related change that caused this. Any ideas?
No. I guess we updated all other platforms to not rely on the names?
So do I just use 0_caller, 1_caller, and 2_caller for the three functions that get exported? (I tried that, and got ILLEGAL INSTRUCTION
when trying to execute)
they could be in an arbitrary order
:grimacing: oh that's exciting. Any tips on how to proceed?
Is exporting multiple functions just not well supported anymore?
it never was really, I'm not really sure why this was attempted here. so, one thing you can do is look at teh LLVM IR and guess. or the info should be available in the compiler somewhere, I'm looking
Yeah, we really need to get rid of this record of closures thing and allow exporting multiple functions.
so we have this function
fn build_closure_caller<'a, 'ctx>(
env: &Env<'a, 'ctx, '_>,
layout_interner: &STLayoutInterner<'a>,
def_name: &str,
evaluator: FunctionValue<'ctx>,
alias_symbol: Symbol,
arguments: &[InLayout<'a>],
return_layout: InLayout<'a>,
lambda_set: LambdaSet<'a>,
result: InLayout<'a>,
) {
I suspect the alias_symbol
is the name of the alias?
Was broken during this PR: https://github.com/roc-lang/roc/pull/5093
Sadly didn't manage to narrow to a specific commit. Instead have about 10:
Updated how I was testing for bisect to avoid a different error. Now I have a first failing commit:
https://github.com/roc-lang/roc/commit/769a4c415b04a12f88e75cefdea7b135c9dbbb5f
Oh yeah, literally just pulled out the feature: https://github.com/roc-lang/roc/commit/769a4c415b04a12f88e75cefdea7b135c9dbbb5f#diff-cdbf72af96e45146eca8f0477d9181a0ca3d64f2d134a3ecb7503af3352b1a17L5211-L5236
yeah the thing is that these names need to link up with what glue generates/expects
that is hard because in general we don't have a name for that thing. Especially now that we've dropped the as Fx
syntax that symbol name is actually not guaranteed to be meaningful
Especially now that we've dropped the as Fx syntax
The syntax still is valid and parses. Maybe that is the root of the confusion?
We probably should fully remove it if it is no longer supported
no, it's a way to define inline aliases, so the alias still works
it's just no longer meaningful for generating names
Oh, so that can be used to work around our recursive type bug? You can use a inline alias instead of trying to define to mutually recursive aliases?
I guess I never realized that feature was used for more. I thought it was just for the glue naming
not sure what you mean? you can write
x : [ Cons a (ConsList a), Nil ] as ConsList a
x = Nil
Why is that a feature? It is just to skip this line?
ConsList a : [ Cons a (ConsList a), Nil ]
Also, I was mentioning that currently it can be used to work around this bug:
Program : List Term
Term : [Quote Program]
── CYCLIC ALIAS ──────────────────────────────────────────────── /tmp/impl.roc ─
The Program alias is self-recursive in an invalid way:
6│ Program : List Term
^^^^^^^
Recursion in aliases is only allowed if recursion happens behind a
tagged union, at least one variant of which is not recursive.
────────────────────────────────────────────────────────────────────────────────
Cause this works:
Term : [Quote ((List Term) as Program)]
That said, I don't think that is really a reason for the feature to exist. It is just a case where it can happen to work around a compiler bug.
well the general idea is that you should be able to type any value without resorting to an alias defined outside of the type itself
if an alias is an alias, we should always be able to inline the alias,right
ah
That makes sense
Just feels weird to have two ways to do the same thing kinda. But I get the use now.
Is there a tutorial anywhere about platform glue?
Not really. Glue currently can only autogenerate for rust (and to a more limited extent zig).
So currently, it is mostly bespoke knowledge and learned by asking question.
It is currently an actively moving target with some larger changes planned, which is why it hasn't really be documented currently.
Fabian Schmalzried has marked this topic as resolved.
Fabian Schmalzried has marked this topic as unresolved.
Last updated: Jul 06 2025 at 12:14 UTC