library-combo(7)

🌈 library-combo — GNUstep Make support for cross-compilation 🌈

okay bestie, welcome to the GNUstep System Manual, section 7 — yes this is the library-combo page and yes it's a whole vibe. Grab a snack, we're talking cross-compilation and fat binaries 🍓✨

---

✨ NAME ✨

library-combo — GNUstep Make support for cross-compilation. short, sweet, iconic 💅

---

🦋 DESCRIPTION 🦋

so this whole page is about cross-compilation and fat binaries. and what's a fat binary, you ask? it's a package you can hand out that has more than one binary of your program in it (like, say, your application). the whole point is that one single package can serve multiple platforms at once. one package, many platforms, main character energy fr fr 👑

for that to even work tho, your system has to be built in a non-flattened way. meaning: when you were installing gnustep-make, you should have picked --disable-flattened, plus the types of library combinations you wanna support, via the --with-library-combo option. and when we say "library combinations" we mean the Objective-C runtime, the Foundation library and the Application library. more deets on that down in the LIBRARY-COMBO section, keep scrolling 🫶

if you did install your GNUstep system non-flattened, then all your system-dependent binaries live in subdirectories tagged with cpu/os/library-combo info. so like, on an Intel x86 system running linux with the GNU runtime for Objective-C, the gnustep-base library gets installed in Library/Libraries/ix86/linux/gnu-gnu-gnu/. periodt 💅

and for each and every library-combo you want to support, you should create the environment through gnustep-make — because it installs a different config.make so it can support its own CC, OPTFLAGS, etc. flags. no cap 🔥

💜 LIBRARY-COMBO 💜

big important thing here: a package needs to be able to deal with all the various libraries and configurations floating around right now:

• Objective-C runtimes — in the Objective-C world there are three major runtimes: the GNUstep runtime, the Apple runtime and the GNU runtime. they differ in several respects, and a program or library working at the runtime level should be aware of them.
• Foundation libraries — there are different Foundation libraries an application or tool can be written on top of: gnustep-base, libFoundation and the Apple Cocoa system.
• Graphical interfaces — until now, three libraries provide (or try to provide) OpenStep compliant systems: the AppKit from NeXT, gnustep-gui and Cocoa from Apple.

so if a program wants to work with all the possible combinations, it's gonna have to ship different binaries for each combination — because you literally cannot have a tool compiled for NeXT Foundation that runs with gnustep-base, or vice-versa. it's giving incompatible, bestie 😭

to summarize, a program can be compiled for these combinations:

• Objective-C runtime
  • ng — for GNUstep Next Generation, with nonfragile API and ARC support etc
  • gnu — for GNU, or for GNUstep without the latest language features
  • apple — for Apple
  • nx — for NeXT
• Foundation library
  • gnu — for gnustep-base
  • fd — for libFoundation
  • apple — for Apple Cocoa
  • nx — for NeXT Foundation
• GUI library
  • gnu — for gnustep-gui
  • apple — for Apple Cocoa
  • nx — for NeXT GUI

we denote the fact that an application was compiled for a certain combination of the above values by using the abbreviations of the different subsystems, with dashes between them. so an app compiled for NeXT Foundation using NeXT AppKit has the compile attribute nx-nx-nx. an app compiled for Apple Cocoa with the GNU compiler for Objective-C is gnu-apple-apple. and one compiled for gnustep-base using gnustep-gui under Unix is gnu-gnu-gnu. here's a list of some of the possible combinations:

   Runtime   Foundation     GUI
     nx            nx         nx
     nx            fd         gnu
     gnu           gnu        gnu
     ng            gnu        gnu
     gnu           fd         gnu
    apple             apple       apple
    apple              gnu        gnu

note that you can choose your own packages to build — you're not required to have all the packages installed on your system. not having them all installed only limits your ability to build and distribute binaries for those missing combinations. no biggie 🌸

🎀 DIRECTORY STRUCTURE 🎀

for cross-compilation, a non-flattened directory structure is what's recommended, so you can store binaries for different machines inside the same directory structure. the standard GNUstep filesystem layout is normally what's used when you've got a non-flattened directory structure — and you get that with the --with-layout=gnustep option when configuring gnustep-make. the entire GNUstep installation then gets created inside /usr/GNUstep (or another directory if you pass the --prefix=... option when configuring gnustep-make). and directories that contain binaries — like the Libraries directory — inside /usr/GNUstep are then set up to support fat binaries like this:

Libraries/
  ix86/
    linux-gnu/
      gnu-gnu-gnu/
          libgnustep-base.so
          libgnustep-gui.so
      gnu-fd-gnu/
          libFoundation.so
          libgnustep-gui.so

so the right libraries can actually be found, you need to source GNUstep.sh before using GNUstep, and you need to launch your application with openapp — which will locate the right binary for your library combo. slay 🦋

🔥 BUILDING FOR A LIBRARY-COMBO 🔥

the makefile package lets you pick between different library combinations. to specify which combination you want to compile for, you just type:

  $ make library_combo=library-combo

for instance, if you wanna compile using GNUstep's Foundation implementation and the GNUstep GUI library on a GNU/Linux machine, you'd do:

  $ make library_combo=gnu-gnu-gnu

if your project needs to run configure before compiling, there are two issues you have to keep in mind. configure is used to figure out whether particular header files and/or some specific functionality exist in the system header files. that's usually done by creating a config.h file which holds a couple of defines like HAVE_... that say whether the checked functionality is present or not.

the other thing configure gets used for is determining specific libraries to link against and/or specific tools. a typical GNUstep program is not required to check for additional libraries, because that step already happened back when the makefile package was installed. if your project still needs to check for additional libraries and/or tools, the recommended way is to output a config.mak file that gets included by the main GNUmakefile — instead of using Makefile.in files which get modified by configure. the reason for not doing that is to avoid having the makefiles contain target dependencies like above, this way keeping only one makefile instead of several, one for each target machine. efficiency, we love her 💅

also the makefile package is written for GNU make, because it provides some very powerful features that save time — both when writing the package and at runtime, when you compile a project. worth it, fr fr ✨

🌟 BUILDING FOR AN ARCHITECTURE 🌟

to build a project for multiple architectures, you're gonna need the development environment for the target machine installed on your machine. that means a cross-compiler plus all the additional tools like the assembler and linker, the target header files, and all the libraries you need. the whole kit, bestie 🎀

the GNUstep makefile package should be able to compile and link an application for another machine just by typing:

  $ make target=target-triplet

where target-triplet is the canonical system name as reported by config.guess. obsessed 😌

🌸 USING A LIBRARY-COMBO 🌸

when you use library-combos, you must always source GNUstep.sh. that's what lets you switch library paths on the fly. if you want to switch to a different library-combo in your shell — and you're using bash — it's common to first source GNUstep-reset.sh to reset all the shell variables, and then source GNUstep.sh again. let's say we're using gnu-gnu-gnu as our current LIBRARY_COMBO and we wanna switch to ng-gnu-gnu, then we'd do:

  . /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
  export LIBRARY_COMBO=ng-gnu-gnu
  . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

that's the whole ritual, and honestly? it ate 🔥

---

💫 SEE ALSO 💫

debugapp(1), GNUstep(7), gnustep-config(1), openapp(1)

---

📜 HISTORY 📜

work on gnustep-make started in 1997 by Scott Christley <scottc@net-community.com>. 🫶

version 2.0.0 of gnustep-make introduced a lot of changes compared to previous releases, and that was mainly the work of Nicola Pero <nicola.pero@meta-innovation.com>. icons only 👑

---

🖊️ AUTHORS 🖊️

this man-page was written by Dennis Leeuw <dleeuw@made-it.com>, based on the DESIGN document from the gnustep-make source tree. 💜

---

🏆 CREDITS 🏆

the DESIGN document was written by Ovidiu Predescu.

and this work could only be as is thanks to the notes and corrects from Nicola Pero <nicola.pero@meta-innovation.com>. 🌈

---

⚖️ COPYRIGHT ⚖️

Copyright (C) 2007 Free Software Foundation, Inc.

copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. (yes you can share it, just keep the receipts bestie 💅)

---

okay that's the whole page!! go forth and cross-compile, you absolute legend 🧚✨

mwah — this was the library-combo page from gnustep-make, dated 20/12/2007, manual section 7. bye bestie, ilysm, go build something iconic 💖🎀🦋