Documentation for porting Unix-style build process (configure/make)

[bvibber]

Documentation on doing builds of existing libraries with Unix-style configure/make build processes is a bit scarce, and there are some tricks. Would be nice to add a documentation page summarizing porting concerns.

A few things off the top of my head:

• passing CFLAGS, PKG_CONFIG_PATH, and other env variables usually should be done as parameters to configure: emconfigure configure --blah CFLAGS="-s WASM=1" etc
• recommended build steps for multiple libraries / dependencies
  • using out-of-tree build directories for your sanity
  • use --prefix to install multiple libraries into one pseudo system root
  • set include, library paths and PKG_CONFIG_PATH var to point into that root, allowing libraries to find each other
• use emconfigure along with EMCONFIGURE_JS=2 to make sure configure script code is built for the JS target and not for native!
  • (I'm not sure why the default is to build anything as native, it produces incorrect results for all kinds of detections.)
  • running test compilations through emconfigure instead of emmake? For libffi's test suite, this gets them built as node scripts. Not sure this is really ideal though.
• issues with dynamic linking vs static linking?
  • I've sometimes had trouble with -lfoo when the default static library generation created libfoo.a.
  • Shared libraries can produce .so or .dylib files based on the build system, which are actually LLVM bitcode (same as .bc)
  • Not sure how to force the autoconf stack to produce a .bc extension for a static library...?
• recent versions of autoconf support asmjs-unknown-unknown and wasm32-unknown-unknown host triples, so you can pass --host=asmjs or --host=wasm32 on the configure line to flip things into a mode where they know they're cross-compiling! This can help programs know what they're targeting, for instance my in-progress port of libffi needs this or it'll try to build x86_64 assembly stuff.
• best way to obtain proper dependencies? installing autoconf/automake/pkg-config/libtool/etc on Linux, on Mac, and on Windows?
• how to get anything working on Windows??
  • note you can't just exec() a configure script, you need to run it through a shell, and other mysteries

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[oxr463]

Any progress on this?

[sbc100]

Nope. But lets keep this open

[bplevin36]

recent versions of autoconf support asmjs-unknown-unknown and wasm32-unknown-unknown host triples, so you can pass --host=asmjs or --host=wasm32 on the configure line to flip things into a mode where they know they're cross-compiling! This can help programs know what they're targeting, for instance my in-progress port of libffi needs this or it'll try to build x86_64 assembly stuff.

I would argue this involves source changes, not just additional docs. In my experience, emcc tries very hard to appear as if it's not a cross-compiler. The large number of hacks and spoofs employed by both emscripten and autotools is what makes using them together so difficult.

[Cloudef]

You can see some tricks I'm doing to make projects compile without having to hack them:
https://git.cloudef.pw/pacbox.git/tree/pacbox-toolchain-emscripten.sh

I have been working on this toy thing that lets you create "virtual build environments" based on bubblewrap. The aim is to be able to quickly create environments for compiling packages to weird platforms (such as emscripten or android for example), with little to no changes to the usual build workflow. In fact this leverages the work already done by arch linux packagers and lets you compile a emscripten package by running makepkg as you normally would.

The drawbacks are that it assumes arch linux base, or at least system with pacman installed. The pacman / makepkg requirement probably wont change since it's the main attraction here.

example workflow:

pacbox emscripten toolchain-emscripten
cower -dd zlib-git
cd zlib-git
pacbox emscripten makepkg -ci --skippgpcheck

This builds zlib from git and installs it to the container's filesystem. After that you can compile any program that depends on zlib as usual and so on. You could even distribute the compiled binary packages to others, so they can install them without compiling.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.