Linking in prebuilt libraries

[formatc2013]

Hi @bugra9 !
Thanks for this awesome tool.

I am struggling to link in libraries to the Cloudflare sample project,(proof of concept at our company to leverage a large C++20 code base) built outside of the cppjs build environment, with emscipten.

I tried a few things, but in a few words I used the sample cmake sample, and I tried to call:
target_link_libraries(cppjs_internal_lib XYZ path/to/some/other/lib)
Basically link together the sample cmake lib with a library build with emscripten, fails to work, with undefined symbol linker errors.

I tried to use the same libraries, only with pure emscripten, and I could successfully link it together and use/load it in the node terminal.

If I build the dependency lib with add_subdirectory(), inside the cppjs build system it works okay.
If add sources (generated by emscripten/conan ) to a target as object files or llvm bitcode it also works.
Only linking fails.
I checked and if not mistaken cppjs uses clang18, and I verified my binaries are also build by clang18.
(checked by: strings yourbinary.a | grep clang).
Verified symbols with emnm xyz.a | grep somefunction; symbols present with T.

What are the specific compiler/linker flags, that I must use in order to be able to link into cppjs build libraries?
Does it have to happen in the cppjs docker image?
Would you be able to provide a minimal example how to build a linkable external library?
Or an example with conan?

I also tried to integrate parts of our build system into cppjs, but has a lots of dependencies and uses other tools than cmake, so consuming prebuilt libs/headers would be preferred.

Much appreciated

PS: Can prepare a repro if needed

[bugra9]

Hi @formatc2013,

Thanks so much for your feedback and the kind words about Cpp.js.

Cpp.js first compiles packages into static libraries, then passes these packages as parameters to emcc to convert them to WebAssembly. When resolving packages to be passed to emcc, I've implemented two steps:

• Resolve from the dependencies section in cppjs.config.js (for cpp.js packages)
• Look in .cppjs/.../Source-Release/Emscripten-x86_64/dependencies/**/*.a

I had never tried adding another package with target_link_libraries before. When compiled this way, I believe I can detect where the library is created and provide it to emcc. This should solve your problem.

Additionally, integration with package managers like Conan hadn't occurred to me before - this expands my vision. I'll be working on this integration this week.

Independent of these solutions, I tried an experiment. I first compiled the project https://github.com/bugra9/cpp.js/tree/main/packages/cppjs-sample-lib-prebuilt-matrix with cpp.js.
Then I compiled the same project with Conan2 (conan create . --profile=emscripten)

# .conan2/profiles/emscripten
[settings]
os=Emscripten
arch=wasm
compiler=clang
compiler.version=18
compiler.libcxx=libc++
build_type=Release
[tool_requires]
emsdk/3.1.73

I replaced the static library generated by cpp.js with the one created by Conan2.
I tested this library with https://github.com/bugra9/cpp.js/tree/main/packages/cppjs-sample-web-vue-vite project and it worked.
Direct integration with Conan would be excellent.

Thanks again for all the great input!

[formatc2013]

Thanks @bugra9

Copying the libraries (compiled with the emscripten conan profile) under dependencies did the trick!

Regarding swig bindings, I have a small problem:
I modified the build*.js scripts, because I'd like to use custom *.i files, instead of the ones generated by
createInterface.js
for example:

#ifndef _SOMETHING_I
#define _SOMETHING_I

%module SOMETHING
%include "something.i"
%{
#include "something.h"
%}

%feature("shared_ptr");
%feature("polymorphic_shared_ptr");

%extend some::name::space::something {
    sometype somefunction(const std::string& name)
    {
        auto ret = self->doSomething<sometype>();
        return ret;
    }
}

namespace some::name::space
{
    %nodefaultctor Something
    struct Something
    {
          std::string getName();
          sometype getSomeThing();
    }
}  

#endif

This will generate code in *.i.cpp:

SWIGINTERN sometype some_name_space_somefunction(some::name::space::Something *self){
        return ....;
    }

which does not compile with npm run build.

/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/wire.h:116:19: error: static assertion failed due to requirement '!std::is_pointer<hxdm::fnd::HxGuid *>::value': Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>
because self is passed as a pointer.
It does work if change it to a ref (....Something & self){...}
This requires to change *.i.cpp after swig generation.

I wonder if having to edit generated *.i.cpp files is avoidable, when using %extend keyword.