# This is the default path, but you can override it I chose to reuse the same sysroot for my dependencies too. That way, each library will both search for its dependencies in the specified sysroot during build, and it will also install itself in the same sysroot so that others can find it more easily.Įmscripten already has its own sysroot under (path to emscripten cache)/sysroot, which it uses for its system libraries, Emscripten ports, and tools like CMake and pkg-config.
Instead, an easier approach is to create a separate folder as a custom system root (often shortened to "sysroot") and point all the involved build systems to it. I also found some bugs where build systems weren't actually prepared for their dependencies to live in non-standard paths. However, when the dependency graph becomes complex, the list of path overrides for each library's dependencies becomes verbose and error-prone.
Most configure-based build systems, including the ones used in these libraries, allow overriding paths for dependencies via various flags, so that's what I tried to do first. Here's an approximate dependency diagram (dashed lines denote dynamic linking): Instead, I needed my application to use my custom fork of libgphoto2, while that fork of libgphoto2 had to use my custom fork of libusb.Īdditionally, libgphoto2 uses libtool for loading dynamic plugins, and even though I didn't have to fork libtool like the other two libraries, I still had to build it to WebAssembly, and point libgphoto2 to that custom build instead of the system package. Since I was targeting WebAssembly, I couldn't use the libusb and libgphoto2 provided by the system distributions.
In this post I'll go deeper into the technical details behind the gPhoto2 port. I also showed a demo built with gPhoto2 that can control DSLR and mirrorless cameras over USB from a web application. In the previous post I showed how the libusb library was ported to run on the web with WebAssembly / Emscripten, Asyncify, and WebUSB.
0 kommentar(er)
