plaurent / gnustep-build

Scripts for building the latest possible GNUstep on your system

gnustep-build

This repository contains scripts for building the latest GNUstep from source under your favorite distributions. Tested features include blocks and ARC.

See demo.sh and demo-gui.sh for barebones examples.

Build Status

Platform specific build status via Github Actions (on fresh installs of the distribution using Docker):

Distribution	objc runtime	supports ARC	supports Blocks	installs clang	CI Status
Ubuntu 20.04	2.0	yes	yes	10.0
Debian 10	2.0	yes	yes	8.0

gnustep-build's Issues

Is this a bad error:

Drop Ubuntu 19.04

Apparently Ubuntu 19.04 is “no longer supported” so we should drop support for it here as well.

Debian 10 clang 8 : failed to install clang

First run of GNUstep-20-buildon-debian10.sh on a fresh buster system. Install failed because apt.llvm.org pubkey isn't installed.
One need to run first the following command
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key|sudo apt-key add -

Fingerprint: 6084 F3CF 814B 57C1 CF12 EFD5 15CF 4D18 AF4F 7421

Add NSURLSession to pinephone and other builds

As per https://github.com/plaurent/gnustep-build/pull/31/files

• add apt install libcurl4-gnutls-dev
• and then build libs-corebase

# Build GNUstep corebase (CoreFoundation)
 echo -e "\n\n"
 echo -e "${GREEN}Building GNUstep-corebase...${NC}"
 cd ../libs-corebase/
 ./configure
 make -j8
 sudo -E make install

Alpine Linux

Hello, Could you guide me How to install on Alpine Linux also?

Thank you so much.

Issue Linking when Swift is Installed.

If Swift development tools are installed in the default location - /usr - then some headers that involve ICU (that GNUstep also uses) are overwritten with Swift specific headers and they contain references to fields in Swift specific libraries. The end result is that the GNUstep GUI library will fail to link because of references to missing symbols. The work around for now is to not install Swift (at least not in the default location) or figure out which libraries GNUstep needs to also link against.

Add support for Letterus' Debian build, with testing

Using Travis' "matrix" testing mode to validate a docker build of @Letterus Debian script as per https://stackoverflow.com/a/47557724

Restore set -e so script halts on error (but make clean || true)

These scripts used to have set -e, but this was removed because an early call to make clean fails (I think this failure is because GNUstep make is not yet installed by that point.)

If we add || true after the make clean command, we can restore set -e at the top and have the script stop on more meaningful errors.

I receive the following when compiling a hello world program

Compiling and running hello.
NSAutoreleasePool does not support ARC correctly (implements retain)
GSPlaceholderString does not support ARC correctly (implements retain)
GSMutableString does not support ARC correctly (implements retain)
NSConstantString does not support ARC correctly (implements retain)
GSTinyString does not support ARC correctly (implements retain)
GSPlaceholderValue does not support ARC correctly (implements retain)
GSMutableArray does not support ARC correctly (implements retain)
GSPlaceholderArray does not support ARC correctly (implements retain)
GSPlaceholderTimeZone does not support ARC correctly (implements retain)
NSLocalTimeZone does not support ARC correctly (implements retain)
_NSConcreteProcessInfo does not support ARC correctly (implements retain)
NSSmallInt does not support ARC correctly (implements retain)
NSBundle does not support ARC correctly (implements release)
NSNull does not support ARC correctly (implements retain)
2020-05-24 23:26:25.110 hello[32983:32983] Hello, World!

I've created a Gist so you can see what I'm running.
https://gist.github.com/Adobe-Android/e0ac8d85d5eb277c50d56545d6165c48
I get the same message whether I run arc_hello.m or non_arc_hello.m with compile.sh.
I'm running on Ubuntu 20.04 and I used this repo to setup everything.

Fix under Clang 11

Under clang 11 the Swift libdispatch fails to build:

GNUstep-build/swift-corelibs-libdispatch/tests/dispatch_timer_short.c:58:74: error: implicit conversion from 'unsigned long long' to 'double' may lose precision [-Werror,-Wimplicit-int-float-conversion]
        test_long_less_than("Frequency", 1, (long)ceil((double)delay/(finalCount*interval)));
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
/home/mobian/gnustep-build/pinephone-mobian-debian-12-clang-9.0/GNUstep-build/swift-corelibs-libdispatch/tests/bsdtests.h:135:90: note: expanded from macro 'test_long_less_than'
#define test_long_less_than(a,b,c) _test_long_less_than(__SOURCE_FILE__, __LINE__, a, b, c)
                                                                                         ^
1 error generated.
make[2]: *** [tests/CMakeFiles/dispatch_timer_short.dir/build.make:76: tests/CMakeFiles/dispatch_timer_short.dir/dispatch_timer_short.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:593: tests/CMakeFiles/dispatch_timer_short.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 71%] Linking C executable dispatch_timer_timeout
[ 72%] Linking C executable dispatch_sema
[ 72%] Built target dispatch_timer
[ 72%] Built target dispatch_timer_timeout
[ 72%] Built target dispatch_sema
make: *** [Makefile:146: all] Error 2

Find some way to fix it.