GNUstep Base Library: an Objective-C Foundation layer without the GUI

The half of Foundation that has no pixels in it

The GNUstep Base Library is a library of general-purpose, non-graphical Objective-C objects, and that phrase is the whole scope statement. It exists to implement the non-graphical portion of Apple's Cocoa frameworks, the Foundation library, which came from the OpenStep standard. The audience is a developer who wants Objective-C source that behaves like Cocoa code, or who is building the layer underneath a graphical GNUstep application and needs strings, collections and event handling to exist first. The repository is written in Objective-C, and the topics tag it with foundation and base-library, which is how the project positions itself in the ecosystem. Note what is absent from the description. There is no window, no view, no drawing and no event dispatch to a screen. Anything that needs a display server is deliberately not here, so a team looking for a drop-in AppKit replacement will not find it in this repository. What you do get is the layer that Cocoa code below the view layer depends on, which is exactly the layer that has to be portable if the code above it is to be portable.

What the class list actually covers

The README names the categories the library implements, and the list is more informative than the usual claim of Foundation parity. There are classes for strings, object collections, byte streams, typed coders, invocations, notifications, notification dispatchers, moments in time, network ports, remote object messaging support for distributed objects, and event loops. Read as a set, that describes a data layer and a concurrency layer, not a user interface layer. Typed coders are the archive mechanism that turns objects into serialized form, which is what makes a value survive a write to disk or a message over a network port. Invocations are the packaged message form: a target, a selector and its arguments, which is the machinery behind both notification dispatchers and the remote object messaging support. Network ports and the event loops are the two ends of that story, one for talking to another process, one for running a main loop. The repository layout matches the split, with Source/ and Headers/ for the implementation and interface, NSCharacterSets/ and NSTimeZones/ holding data resources, Resources/ holding the rest of the bundle, and Tests/, Tools/, Examples/ and Documentation/ around it. A directory named NSTimeZones tells you timezone data is bundled rather than read from the operating system, and the size of that dataset is a real consideration when you consider embedding the library.

Distributed objects depend on ffcall, and that is the sharp edge

The one dependency the README names directly is ffcall, and the project is unusually blunt about it: with GNUstep-Base, the use of the ffcall libraries is strongly recommended, because ffcall provides stack frame handling for NSInvocation and NSConnection. That is the mechanism behind the remote object messaging support. For an in-process call you can push a stack frame yourself, but for NSConnection to marshal a message to another process and have it dispatched on the other side, the callee has to synthesise a stack frame in a way the runtime can walk. ffcall is what makes that possible, and the alternative is implementing the same trick yourself, which is why the recommendation exists. The licensing note on ffcall is quoted in the README and deserves attention. Ffcall is under the GNU GPL, with a special exception stating that if used in GNUstep or in derivative works of GNUstep, the included parts of ffcall are under the GNU LGPL. The text is the author's own wording, and the point for an engineer is that a GPL library can still be linked inside a GNUstep-shaped product, but the exception is scoped to GNUstep and its derivatives, so a project that reshapes the library beyond that scope needs its own reading. This is a licensing note, not legal advice, and the COPYING.LIB file is the place to check.

Building it: GNU make, a configure script and a top-level Makefile that refuses to work

The repository is a GNU autoconf style tree with the usual scaffolding, and one trap that catches people immediately. At the top level there are configure, GNUmakefile, Makefile, Makefile.postamble, base.make.in, config.mak.in, aclocal.m4, standalone.conf and cross.config, along with an install.sh script and a set of spec files for packaging. The old top-level Makefile is explicitly labelled deprecated, and its default target does nothing but tell you what to do instead. The verbatim contents of that target are:

all:
	@echo You need to use GNU make to compile the GNUstep Base Library

Running make with that file produces that one message and stops. The build entry points you actually use are the ones listed above, and the file list also shows the shape of the build system: configure generates the configuration, base.make.in and config.mak.in are the templates, and GNUmakefile is what drives the compile. The README does not reproduce the step by step procedure. It points to two places: the INSTALL file in the repository, and the GNUstep-HOWTO document on the project website, linked from the README as gnustep-howto.pdf. The README also points to the NEWS file for the library feature history, which is the fastest way to see what changed between versions.

One library, two licences, and a directory list that spells it out

GNUstep splits its own code by purpose and says so at directory level, which makes the licence question concrete rather than abstract. The GNUstep libraries and library resources are covered under the GNU Lesser Public License, which means you can use these libraries in any program, even non-free programs, and if you distribute the libraries along with your program you must make the improvements you have made to the libraries freely available. The files in Source, Headers, NSCharacterSets, NSTimeZones and Resources are the ones covered under the LGPL. The tools, test programs and other files are covered under the GNU Public License, which means if you make changes to these programs you cannot charge a fee, other than distribution fees, for others to use the program. The files in Documentation, Examples, Tools, config and macosx fall under the GPL. The repository root carries COPYING, COPYING.LIB and COPYINGv3, so the three texts are present and you can read the terms that actually apply to the file you are touching rather than guessing from the project as a whole. A downstream team should note that the licensing story changes if it modifies the library itself, since improvements to the LGPL part must be published, while linking a non-free program against the library is the case the LGPL is designed to permit.

Where libs-base stops, and what it leaves to the rest of the stack

The boundary of this library is the practical limitation that matters most. It is non-graphical by definition, so a Cocoa application that draws anything needs a separate GUI layer, and the GNUstep stack beyond this repository is where that lives. The same boundary applies to the runtime. The library provides Objective-C objects, but the language runtime, garbage collection or reference counting behaviour, and the messaging machinery that dispatches a selector to a method, come from the compiler and runtime you build against, not from Source/ and Headers/ here. A second limitation is documentation depth. The project's own reading list is short: NEWS for feature history, INSTALL for installation steps, and the GNUstep-HOWTO PDF for the wider how-to. There is no per-class reference in the repository, and the Examples directory shows what usage looks like in practice, with files such as dictionary.m, diningPhilosophers.m, custom-zone.m and a trio of NSConnection programs named nsconnection.m, nsconnection_client.m and nsconnection_server.m. That set is a decent map of the interesting corners, including the distributed objects path, but it is example code rather than a specification. If your work depends on exact behaviour of a particular Foundation class, expect to read headers and the NEWS history rather than a manual.

The branch moves faster than the release tags

The repository is not archived, and the last push was on 2026-10-19. The release tags tell a slower story. The three most recent are base-1_31_1 dated 2025-02-28, base-1_31_0 dated 2025-02-10 and base-1_30_0 dated 2024-05-29, and the naming follows the base-1_31_1 style used by the library's own versioning scheme. So the default branch is receiving commits while the published release line is well over a year behind it. That gap is normal for a project of this kind, where the development branch carries fixes ahead of a release, but it has a practical consequence for anyone pinning a version. Continuous integration is visible in the repository through GitHub Actions workflows, with separate badges for the main workflow, a NetBSD workflow and a gcc-4.9 workflow, which tells you the project checks builds on more than one compiler version and on a second Unix. If you need a reproducible dependency, pin a release tag rather than tracking master, and if you need a fix that has not been tagged yet, be aware you are taking an untagged commit. Bug reports go to the GitHub issues page, and the repository keeps both a ChangeLog and older ChangeLog.1 and ChangeLog.2 files alongside ANNOUNCE, so the history of a given change is recoverable from the tree itself.

Editorial conclusion

Adopt libs-base if you are targeting GNUstep, porting Cocoa code to non-Apple platforms, or need an Objective-C foundation layer with a documented licence split. Do not adopt it expecting a complete Objective-C toolchain: the runtime and the graphical layer live elsewhere, and the library covers non-graphical services only. Verify first that your build has GNU make and a working Objective-C compiler, that the ffcall dependency is available if you intend to use NSInvocation or NSConnection, and that the release tag you install matches the code you intend to patch, since the last push on 2026-10-19 is well ahead of the most recent tag.

Frequently asked questions

Official sources

1. gnustep/libs-base on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases