[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Building the openssl egg on MacOS

From: Lassi Kortela
Subject: Re: [Chicken-users] Building the openssl egg on MacOS
Date: Tue, 16 Jul 2019 00:03:52 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

I maintain the openssl egg these days.

Very nice, thanks for your efforts!

Ugh.  I've always had the impression macOS gets worse with each release,
but this is ridiculous, almost as if they expect everyone to use XCode
for development...

I find that the usability gets better with each release (still dreading the inevitable downfall) but from a programmer's point of view it does indeed get worse. Mojave locked down some files so even with sudo you can't touch them, deprecated other stuf, and retroactively made it so you need the App Store login to install the full XCode.

The easiest workaround is to install a copy of OpenSSL or LibreSSL from the
popular Homebrew package manager and build the egg using that copy:

This is what I recommend to everyone who has to work on that kind of
system.  It's sad, but the least painful way of getting work done.

Cool, I didn't know that.

Homebrew is actually really nice to use, but your point stands about the state of MacOS itself.

I hereby reiterate my point that doing development on macOS involves
much sadness, such as creating a developer account to do development.
I'm afraid there isn't much else you can do, unless you somehow get gcc
and the rest of the toolchain working without that.

The command-line compilers (clang, swiftc) are available without an App Store login as before ("sudo xcode-select --install"). But the XCode IDE is apparently not. As for the OpenSSL headers, I don't know whether they are intentionally gone for good or only available from the App Store (and can't tell which is worse :)

would it make sense to add MacOS-specific checks to the build-openssl script?

Before you do that, there is some work I've done on a few more eggs I
maintain, I got fed up with writing user-unfriendly shell scripts that I
rewrote the non-Windows version to use a Scheme program instead

That sounds like a wise move. And for us who maintain Scheme-related infrastructure, it's nice to get the chance to actually write some Scheme code every now and then :) It so often happens that the C/shell parts take the most time.

basic version detection, falling back to environment variables and
finally bailing out with an error.  You can find the latest version of
it at the breadline repository [1].  Please let me know if that fulfills
your wishes and if not, whether it can be made to do so.  If yes, then
I'd be willing to migrate the openssl egg towards such a script as well.
The reason I haven't done so is because unlike the other eggs I maintain
it's something I'd rather not touch unnecessarily, breakages to it will
be far more annoying to handle than anything else.  And honestly
speaking, OpenSSL isn't nice to deal with either :>

Thank you for inviting feedback! I'll definitely help work things out.

I was thinking, even without considering OpenSSL at all, dealing with pkg-config by itself is complicated enough that it might be worth baking special pkg-config support into chicken-install (or whatever the right internal module is that chicken-install uses).

Some of the BSD's re-implemented the original glib-based pkg-config as "pkgconf". Luckily, pkgconf installs a pkg-config command as a compatibility wrapper and it seems quite feature-complete (in the same way that libressl is with openssl, or clang is with gcc). I haven't had any problems with pkgconf.

But several OSes don't ship with pkg-config by default, so users have to install it. In order to be user-friendly, it'd be nice if Chicken advised them on how to do it. (If Chicken has all the pkg-config business in one place, instead of separately in each egg, then it's a very modest amount of code to provide a user-friendly experience.)

I would tentatively recommend supporting pkg-config as the only way to specify compiler and linker flags for C libraries. I've always thought that users should have the option to give flags manually instead of relying on pkg-config. But today I realized that pkg-config .pc files are basically simple .ini files that contain little more than those same flags. So if users want manual overrides, we could just ask them to write their own .pc file and set PKG_CONFIG_PATH to find it.

Also .pc files specify the library version. E.g. the openssl egg requires openssl 1.0.2 or later, which it can check from the .pc file. (It's not reliable to check using the "openssl" shell command, since that may be a different version.) With user-supplied CFLAGS and LDFLAGS we can't easily make this version check. The .pc file is unlikely to have the wrong version number unless the user deliberately messes it up or makes up an arbitrary version number.

But is stuff detailed enough that it should be discussed on the "hackers" mailing list?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]