Re: libobjc2 build issue

[Andreas Fink]

Great. Yes I noticed the ICU version numer change. These things are usually easy to spot and fix.

Which cmake version did you use to get it built as the one coming with Debian10 is too old.

On 27 Nov 2019, at 06:55, Patryk Laurent <plaurent@me.com> wrote:

Hi Andreas,

I have just updated the script at 

https://github.com/plaurent/gnustep-build/blob/master/debian-10-clang-8.0/GNUstep-20-buildon-debian10.sh

and verified that it builds fully under Debian 10 (buster) by testing it under a fresh Docker installation.  It also builds the apps (like Gorm).

That script was failing to apt-get some dependencies because libicu's version (name) changed.  Also it was not doing the libobjc2 git submodule init.

That script now correctly does both of those.

Best,

Patryk

On Nov 26, 2019, at 5:57 PM, Andreas Fink <afink@list.fink.org> wrote:

yes I did. the checkout is fine.

I just found a way to work around 

after cmake .. ...

I edit CMakeFiles/objc.dir/link.txt and remove the word "pthread" in it. I can't figure out where it comes from. I have to leave this to the Cmake experts..

cmake also complains about some project() missing but that seems to be just a warning.

Maybe this might be triggered by a new cmake. I downloaded the cmake 3.16 today from cmake.com. The stock debian cmake (3.13.4) is not good enough for libobjc2 apparently.

Now I can compile gnustep-base

The following tests are failing:

base/NSArray/blocks.m:

Failed test:       blocks.m:31 ... Can forward enumerate array concurrently using a block

base/NSRunLoop/dispatch.m:

Skipped set:       dispatch.m 118 ... No libdispatch, no blocks support or no runloop integration hooks in libdispatch

and  one more about an empty plist file.

The dispatch one puzzles me a bit because libdispatch was explicitly installed and 

export OBJCFLAGS="-fblocks" was set

Not sure if I should worry about that. Personally I don't use "GrandCentralDispatch" aka libdispatch but I usually want to build the base libraries so someone could use it.

gnustep-gui complains about

configure: WARNING: The International Components for Unicode (ICU) development headers and libraries do not appear to be available on this system.

despite libicu63  and libicu-dev packages being installed

./configure --disable-icu-config 

fixes that (apparentyl theres no pkg-config file for libicu)

a few warnings about depreciated stuff in CUPS,  I have a gnustep-gui

    724 Passed tests

     15 Skipped sets

      1 Dashed hope

I also noted that gnustep-base is version 0.27.0 and gui and back are 0.28.0. Intentionally?

On 27 Nov 2019, at 02:35, Patryk Laurent <plaurent@me.com> wrote:

Hi Andreas,

Have you had a look at this build script by Johannes?  I believe it is in working order, although it may need the new git submodule init and sync commands in the libobjc2 checkout. 

https://github.com/plaurent/gnustep-build/blob/master/debian-10-clang-8.0/GNUstep-20-buildon-debian10.sh

Regards,

Patryk

On Nov 26, 2019, at 16:25, Andreas Fink <afink@list.fink.org> wrote:

thanks but this only helps partially.

It seems to be the build tools for GNUStep are again broken. This is the thing which drives every newcommer mad and was driving me mad initially too. All the readme's and hints you find on the internet are already obsolete.

Now I get this error:


[  7%] Built target objc-static
[  7%] Linking C shared library libobjc.so
clang: error: no such file or directory: 'pthread'; did you mean '-pthread'?
make[2]: *** [CMakeFiles/objc.dir/build.make:518: libobjc.so.4.6] Error 1
make[1]: *** [CMakeFiles/Makefile2:476: CMakeFiles/objc.dir/all] Error 2
make: *** [Makefile:163: all] Error 2


This is now under Debian10 with clang-10 from the llvm repo.
cmake is very cryptic here to tell us where it breaks. so go figure....