How to build command-line third-party (open source) libraries

Is there some kind of page describing details on how to build third-party open source libraries? In the platforms state of the union, it showed there were quite a few libraries already ported - is there some documentation on how to get access to build instructions for those (i.e. boost)?

Alternatively, is there some kind of documentation as to how to modify a "standard" ./configure && make && make install workflow to just attempt at building an ARM64 build (I can do lipo after the fact to create the universal binary).

Accepted Reply

For cmake based projects, you'll need to be sure you're using the latest release candidate build of cmake (3.18 rc) due to some issues in cmake itself.

For projects that use glibtool (most autoconf based projects and some others), you'll need a patched version of libtool (available in MacPorts right now) and you'll need to update the project to use the new version (eg: glibtoolize, autoreconf, etc).

You can then configure and build as normal:

CFLAGS="-target arm64e-apple-macos11.0" ./configure && make

Note that you may run into multiple porting issues, including errors with the configure script itself. I suggest checking config.log for "Wimplicit-function-declaration" as those lines may indicate a test that is incorrectly failing because of a bug in the test itself (usually because stdlib.h, string.h, unistd.h or similar is not #included).


Replies

For cmake based projects, you'll need to be sure you're using the latest release candidate build of cmake (3.18 rc) due to some issues in cmake itself.

For projects that use glibtool (most autoconf based projects and some others), you'll need a patched version of libtool (available in MacPorts right now) and you'll need to update the project to use the new version (eg: glibtoolize, autoreconf, etc).

You can then configure and build as normal:

CFLAGS="-target arm64e-apple-macos11.0" ./configure && make

Note that you may run into multiple porting issues, including errors with the configure script itself. I suggest checking config.log for "Wimplicit-function-declaration" as those lines may indicate a test that is incorrectly failing because of a bug in the test itself (usually because stdlib.h, string.h, unistd.h or similar is not #included).


Thank you! This is excellent information and gives me a great place to start.