A modern programming language that makes developers happier.

kotlinlang

Is the following scenario unsupported? I have
• An `external.so` shared library
• A `base` kotlin module with cinterop bindings to `baseHeader.h` (external.so) 
• A `derived` kotlin module with cinterop bindings to `derivedHeader.h` (external.so). This module depends on the `base` module.
What happens is that `derived:commonizeCInterop` fails:
&gt; Unresolved classifier: some/symbol/from/baseHeader.h

Is the cinterop .def for `derived` configured so it has access to `baseHeader.h`?

I don't have this exact setup but I have a similar one with various related libraries and modules that stack on top of each other where the higher level libraries re-use types from the lower level ones. And haven't had this problem.

If you have a repro repository available somewhere I could have a look. I'm still trying to figure out some of the details around these kinds of scenarios for my own understanding.

It is but it doesn’t matter, the `derived` error references the kotlin package name which I chose inside `base` . Something like

```// base.def
package = platform.example.base
headerFilter = media/**
headers = media/baseHeader.h 

// derived.def
package = platform.example.derived
headerFilter = media/**
headers = media/derivedHeader.h```
Now, base:commonizeCInterop works fine, but derived:commonizeCInterop gives:

&gt; Unresolved classifier: platform/example/*base*/Foo
This suggests that `derived` def is OK and `base` def is not being processed correctly (yet base:commonizeCInterop works and the other doesn’t)…

I cannot say anything more about it unfortunately, but please let us know if you find the issue.

I've seen that issue before. I created a module that lightly abstracted over the C library, then used that in other modules.

Thanks for you answers guys, I’ll add more info when I have them. I don’t even understand why `derived:commonizeCInterop` would care about base cinterop.

Seems to be fixed in 1.8.21, possibly in earlier patch versions too.