Thanks for taking a look. I must be doing something incorrectly. Here is 
the article I am trying to follow. Note this section "What about C?" 
https://developers.google.com/web/updates/2018/08/embind#what_about_c

*embind was written for C++ and can only be used in C++ files, but that 
doesn't mean that you can't link against C files! To mix C and C++, you 
only need to separate your input files into two groups: One for C and one 
for C++ files and augment the CLI flags for emcc as follows:*
*$ emcc --bind -O3 --std=c++11 a_c_file.c another_c_file.c -x c++ 
your_cpp_file.cpp*

I tried doing similar in my case where I replace the ".c" files with the 
library I'm trying to bind, and I replace the ".cpp" file with my own 
bindings file.

Perhaps the included command is wrong?

Cheers
Ben

On Tuesday, July 6, 2021 at 6:46:57 AM UTC-4 Floh wrote:

> This is weird because it looks the .c file is compiled as C++ (not 
> requiring a cast for malloc() is perfectly fine C code, but not valid C++ 
> code).
>
> I would start looking into the build system instead of trying to "C++-ify" 
> the C sources. Somehow the build system seems to treat .c files as C++ 
> (maybe it always calls em++ instead of emcc? emcc should select the right 
> language mode based on the file extension, while em++ forces C++ mode even 
> for .c files.
>
> As a "hack" you can also force compilation in C mode with the "-x c" 
> command line option, for instance:
>
> em++ bla.c -o bla -x c
>
> On Monday, 5 July 2021 at 02:18:37 UTC+2 [email protected] wrote:
>
>> Apologies if this is less of an embind question and more of a "how does 
>> interop work with C and C++" question. I"m a bit inexperienced using them 
>> together but in my case I'm trying to use embind, which requires bindings 
>> written in C++, and the library I want to link is written in C. When I try 
>> to link this library (https://github.com/korginc/volcasample) I get an 
>> error about implicit pointer type conversion:
>>
>> ../volcasample/syro/korg_syro_volcasample.c:713:23: error: assigning to 
>> 'uint8_t *' (aka 'unsigned char *') from incompatible type 'void *'
>>                         psms[i].comp_buf = malloc(comp_dest_size + 
>> comp_ofs);
>>                                            ^
>>
>> I suppose I could convert the library to valid C++ with correct casting 
>> but I'm hoping to avoid having to patch the source library in order to link 
>> it. Is there another way? A compiler flag to allow implicit pointer type 
>> casting or something like that?
>>
>> Thanks
>> Ben
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/2373b6a7-a017-4cef-8bc4-313d0c0bdcd4n%40googlegroups.com.

Reply via email to