undefined | Better HN

0 pointspilif5y ago0 comments

Those things are very much worth simplifying: as more and more packages are starting to rely on pkgconfig, getting the headers recognized that ship with whatever SDK you are currently using (Xcode, command line tools) is very tricky and sometimes requires patching the build tools.

Homebrew is the perfect glue between the traditional Unix world and the somewhat unexpected Unix environment that macOS is providing these days (mostly a consequence of Xcode wanting to be a self-contained .app and /usr being read-only while still honoring the tradition of leaving /usr/local alone for you as a user)

0 comments

2 comments · 1 top-level

mlindner5y ago· 1 in thread

This actually simply isn't true. Firstly, pkgconfig works perfectly well on MacOS and always has. It sounds like you more have issues with Xcode than you do with anything else. I've not heard of a commonly used package requiring any sort of patches to get it to compile on MacOS. MacOS is a first class citizen of the open source world and things generally work perfectly for it.

Yes you need to spend a bit of work to find out what dependencies you need, but the configure scripts will tell you that when they fail.

> Homebrew is the perfect glue between the traditional Unix world and the somewhat unexpected Unix environment that macOS is providing these days (mostly a consequence of Xcode wanting to be a self-contained .app and /usr being read-only while still honoring the tradition of leaving /usr/local alone for you as a user)

On Mac packages have always naturally installed into /usr/local and not /usr.

pilifOP5y ago

The problem is that the macOS SDK doesn’t ship pkgconfig files for the libraries included with macOS.

Unless you go the extra length, the “easy fix” is to compile your own version of those libraries which is fine until you need to be linked against a binary shipped with the OS (say you are trying to compile an Apache module).

At that point you will have conflicting symbol names between the binary that shipped with the OS and depends on its libraries and your binary that depends on the self-compiled libraries which might or might not have matching versions and/or custom patches.

Libedit, libxml2 and many others are samples of this. Their binaries are in-fact installed in read-only /usr as shipped by apple, but the matching include files live in the Developer folder of either the command line developer tools or Xcode.

No open source package will be able to link to the system libraries by default with this split and when all they support is pkgconfig, you’re SOL without additional manual work

j / k navigate · click thread line to collapse