libobjc2 failure on ubuntu24 on arm

[Andreas Fink via Discussion list for the GNUstep programming environment]

Hello all

I try to build a gnustep app under Ubuntu24 on arm.
compiling and installing gnustep worked as normal but when I try to run my own 
code I get failures during ./configure phase

checking whether we are cross compiling... configure: error: in 
`/Users/afink/development/gitlab/ulibsctp':
configure: error: cannot run C compiled programs.

so I analyzed what it does there and it runs a simple test case I can reproduce

test.c:

int main(int argc,char **argv)
{
return 0;
}


# /usr/bin/clang -o conftest  -std=c99 -fPIC -DLINUX -D_XOPEN_SOURCE=700 
-D_POSIX_SOURCE -D_DEFAULT_SOURCE -DSCTP_IN_KERNEL=1 -Wno-trigraphs  
-Wno-missing-field-initializers -Wmissing-prototypes 
-Wno-implicit-atomic-properties -Wno-arc-repeated-use-of-weak 
-Wduplicate-method-match -Wno-missing-braces -Wparentheses -Wswitch 
-Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable 
-Wunused-value -Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow 
-Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion 
-Wbool-conversion -Wenum-conversion -Wpointer-sign -Wno-newline-eof 
-Wno-selector -Wno-strict-selector-match -Wundeclared-selector 
-Wno-deprecated-implementations -Wprotocol -Wdeprecated-declarations 
-Wno-sign-conversion  -fobjc-arc -I/usr/GNUstep/System/Library/Headers/ -MMD 
-MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
-D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions 
-fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -I /usr/include -fblocks -fobjc-runtime=gnustep-2.0 
-fblocks -fconstant-string-class=NSConstantString -I. 
-I/root/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers 
-I/usr/GNUstep/System/Library/Headers -I/usr/local/include 
-I/usr/GNUstep/System/Library/Headers/ -DHAVE_OPENSSL=1   -fuse-ld=gold 
-fuse-ld=gold -pthread -fexceptions -rdynamic -fobjc-runtime=gnustep-2.0 
-fblocks -L/root/GNUstep/Library/Libraries 
-L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries 
-lgnustep-base -lpthread -l:libobjc.so.4.6 -lm -lobjc -lavahi-client 
-lavahi-core -lavahi-common -lgnustep-base -ldl -lsctp -lbsd -luuid -lssl 
-lcrypto  test.c
clang: warning: argument unused during compilation: '-fobjc-exceptions' 
[-Wunused-command-line-argument]

]# ./conftest
Segmentation fault (core dumped)


# lldb conftest
(lldb) target create "conftest"
Current executable set to '/Users/afink/development/gitlab/ulibsctp/conftest' 
(aarch64).
(lldb) run
Process 1686 launched: '/Users/afink/development/gitlab/ulibsctp/conftest' 
(aarch64)
Process 1686 stopped
* thread #1, name = 'conftest', stop reason = signal SIGSEGV: address not 
mapped to object (fault address: 0x0)
frame #0: 0xf7f8f2d8 libobjc.so.4.6`selector_lookup(char const*, 
char const*) [inlined] 
tsl::rh::power_of_two_growth_policy<2ul>::bucket_for_hash(this=0x,
 hash=18399730721004063734) const at robin_growth_policy.h:115:19
(lldb)


Anyone having a clue whats going terriblly wrong here?

Re: Trouble getting libobjc2 2.x to build

[Andreas Fink via Discussion list for the GNUstep programming environment]

this is how I usually do it under ubuntu22


export CC="/usr/bin/clang"
export CXX="/usr/bin/clang++"
export PREFIX="/usr"
export 
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${PREFIX}/bin"
export PKG_CONFIG_PATH="/usr/lib/pkgconfig/:/usr/local/lib/pkgconfig/"
export RUNTIME_VERSION="gnustep-2.1"
export OBJCFLAGS="-fblocks"
export CFLAGS="-I ${PREFIX}/include"
export LDFLAGS="-fuse-ld=gold"
export GNUSTEP_INSTALLATION_DOMAIN="SYSTEM"


cd libobjc2
git submodule init
git submodule update
mkdir Build
cd Build
/usr/bin/cmake  .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DOLDABI_COMPAT=OFF 
-DBUILD_STATIC_LIBOBJC=1  -DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX} 
-DCMAKE_INSTALL_PREFIX=/usr  -DGNUSTEP_CONFIG:FILEPATH=GNUSTEP_CONFIG-NOTFOUND
OLDABI_COMPAT=OFF
make
make install



this is before gnustep-make is even installed



> On 2 May 2024, at 21:02, Larry Campbell  wrote:
> 
> This is on Ubuntu Focal. I have two stumbling blocks:
> 
> ANNOUNCE.2.1 says:
> 
>> The submodule is available from:
>> 
>> https://github.com/Tessil/robin-map/archive/757de82.zip
>> https://github.com/Tessil/robin-map/archive/757de82.tar.gz
>> 
>> This will extract as robin-map-757de829927489bee55ab02147484850c687b620.
>> You must move the contents of that directory into third_party/robin_map in 
>> the
>> libobjc2 tree.
>> 
> 
> 
> However, when I follow the instructions and say "cmake .." from the Build 
> directory, I get this warning:
> 
>> CMake Warning at CMakeLists.txt:118 (find_package):
>>  By not providing "Findtsl-robin-map.cmake" in CMAKE_MODULE_PATH this
>>  project has asked CMake to find a package configuration file provided by
>>  "tsl-robin-map", but CMake did not find one.
>> 
>>  Could not find a package configuration file provided by "tsl-robin-map"
>>  with any of the following names:
>> 
>>tsl-robin-mapConfig.cmake
>>tsl-robin-map-config.cmake
>> 
>>  Add the installation prefix of "tsl-robin-map" to CMAKE_PREFIX_PATH or set
>>  "tsl-robin-map_DIR" to a directory containing one of the above files.  If
>>  "tsl-robin-map" provides a separate development package or SDK, be sure it
>>  has been installed.
> 
> Am I missing a step?
> 
> The second problem is that I get this warning:
> 
>> CMake Warning at CMakeLists.txt:6 (message):
>>  WARNING: It is strongly recommended that you compile with clang
> 
> 
> The README.md file says:
> 
>> If you have gcc and clang both installed, then cmake currently defaults to
>> selecting gcc.  You should override this by adding `-DCMAKE_C_COMPILER=clang
>> -DCMAKE_CXX_COMPILER=clang++` to your Objective-C flags.
> 
> 
> But where do I put these flags? Somewhere in CMakeLists.txt? In one of the 
> numerous *.cmake files?
> 
> - lc
> 
> 

Re: Consider GtkCore as UI

[Andreas Fink]

> On 17 Dec 2023, at 17:38, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 17 Dec 2023, at 14:20, Andreas Fink  wrote:
>> 
> 
>> The only version which is not up to date on repo.gnustep.ch is currently 
>> Ubuntu22 on Intel as I run into a strange error with configure of 
>> gnustep-base as it does not want to detect my libiconv-1.17 version for some 
>> reason. The same version I compiled and used under Ubuntu22 on arm64 and on 
>> Debian worked just fine. (if anyone has a hint on how to convince 
>> ./configure to just use my libiconv I pass, let me know. 
>> --with-libiconv-library=/usr/local/lib/libiconv.a  was not enough).
> 
> I had a look at the documentation/comments in configure.ac
> They suggest you may need to use  --with-libiconv-include= as well as 
> --with-libiconv-library= if you have multiple versions of iconv with 
> conflicting headers
> If that fails, I guess you'd need to look at the config log to work out why.


I tried this but it didn't help.
I have reinstalled that ubuntu machine and this time it worked.

Re: Consider GtkCore as UI

[Andreas Fink]

Bruce,

GNUStep supports Ojbc2.0 with libobjc2.0 and clang but the versions packaged 
with Debian or Ubuntu are compiled with the old runtime.

https://repo.gnustep.ch/ can help you to install "gnustep2" which pulls in 
versions compiled with clang and libobjc2.
I use this combination since years under Debian and Ubuntu on x86_64 and arm64 
for my own applications as I need ARC for my peace of mind.

How to build from source I have documented here:

https://github.com/andreasfink/ulib/blob/master/doc/README-Debian12-bookworm.txt
https://github.com/andreasfink/ulib/blob/master/doc/README-Ubuntu-22.txt

However the graphical artefacts you stated are for sure not in relation to 
libobjc2 because this is gui stuff. And thats in gnustep-gui.
The only version which is not up to date on repo.gnustep.ch is currently 
Ubuntu22 on Intel as I run into a strange error with configure of gnustep-base 
as it does not want to detect my libiconv-1.17 version for some reason. The 
same version I compiled and used under Ubuntu22 on arm64 and on Debian worked 
just fine. (if anyone has a hint on how to convince ./configure to just use my 
libiconv I pass, let me know. --with-libiconv-library=/usr/local/lib/libiconv.a 
 was not enough).


> On 17 Dec 2023, at 14:43, bruce  wrote:
> 
> That's the version of Obj-C. Linux is stuck on 1.9. Obj-c 2.0 released in 
> 2006, as I'm sure you are aware.
> I can use this build https://github.com/plaurent/gnustep-build to create 2.1 
> on Linux. The FeeBSD is stuck at 2.0, as they no longer have a maintainer of 
> their gnustep port.
> 
> On Sun, Dec 17, 2023 at 1:15 PM Gregory Casamento  > wrote:
>> Bruce,
>> 
>> On Sun, Dec 17, 2023 at 7:57 AM bruce > > wrote:
>>> Something clicked (about 3 this morning) about version 1.9. I’ve assumed 
>>> this was the version in the Linux repos due to their typical bureaucracy. 
>>> But more research tells me that 2.1 cannot compile using gcc. I never 
>>> choose gcc myself. But the linux repo maintenance tools such as Launchpad 
>>> depend on it. So they are stuck on 1.9, which is generally referred to as 
>>> obsolete. It’s a reason people tell me they don’t use gnustep. So I 
>>> installed Ubuntu on my backup this morning, and instead of building 
>>> gnustep, I installed 1.9, and the artifact issue goes away.
>>> 
>> 
>> Where are you getting these version numbers from?   The current releases of 
>> gnustep libraries are as follows:
>> 
>> gnustep-base: 1.28.0
>> gnustep-gui: 0.30.0
>> gnustep-back: 0.30.0
>> gnustep-make: 2.9.1
>> 
>> I don't know what 1.9 and 2.1 are referring to.  If you could clarify that 
>> would be immensely helpful.
>> 
>>> Now I see the problem. 1.9 works, but few people use it. I’m not going to 
>>> base a new project on something that is old and deprecated past 
>>> obsolescence. FreeBSD uses a port of 2.0.
>>> 
>>> My renewed interest in gnustep is due to a conversation with @gcasa on 
>>> github. He was complaining that helloSystem didn’t consult with the gnustep 
>>> project. He has a point, helloSystem is a reworking of the osx style 
>>> desktop on freebsd. But I chimed in, and told him I didn’t think gnustep 
>>> was viable. He took that personally, and it was the passion of his response 
>>> that convinced me that gnustep was not dead. And I decided to either prove 
>>> he was right or wrong. Unfortunately, I still think he’s wrong.
>> 
>> It isn't, but you're going about this entirely the wrong way.  I still KNOW 
>> that you're wrong.  Again, you haven't consulted anyone, asked for ANY help 
>> on anything.  Made assumptions and gone off in the wrong direction.   So you 
>> have proved NOTHING.  Given GNUstep's use, as I have pointed out, both 
>> commercially and many other places absolutely proves you incorrect.
>> 
>>> Originally, I looked at ObjFw. It uses Gtk or Qt for gui. But now I 
>>> understand this:
>>> 
>> 
>> Again, if you're looking for the ability to build macOS apps, ObjFw is NOT 
>> the way.
>>  
>>> ‘It supports all modern Objective-C features when using Clang, but is also 
>>> compatible with GCC ≥ 4.6 to allow maximum portability.’
>> 
>> As is GNUstep.  We are a GNU project (it's in the name) we still support 
>> GCC.  Your failure to build with GCC is also something you never talked to 
>> anyone about.   You simply jumped to the conclusion that because you ran 
>> into an issue on your system, it MUST not work.  Please check on GitHub we 
>> have CI running for every commit.  It works fine with clang and gcc.  Clang 
>> is recommended since it fully supports ObjC2.0.  This is a compiler thing, 
>> not a framework thing.
>> 
>>> The main issue I have with ObjFw is lack of documentation. I have 
>>> complained about this with gnustep as well, but then I found old O’Reilly 
>>> books at the local thrift store that finally explained how that era of 
>>> Cocoa worked, and I was able to move forward on gnustep. Until I 

Re: Debian12 repository.

[Andreas Fink]

see http://repo.gnustep <http://gnustep/>.ch/

I am currently fighting with /usr/GNUstep/System/Tools/gnustep-config while 
compiling my own libraries

After changing the layout to gnustep

the tool is not found in the path. a symlink to /usr/bin/gnustep-config fixes 
this (or expanding the path)
However  gnustep-config  --objc-flags  does not include  a 
-I/usr/include/GNUStep  so  is not found

It's not strictly necessary for pure objc code but for gnustep-base code it is. 
There is however no --base-flags but only --base-libs.

I could simply add -I /usr/include/GNUStep   to my Makefiles. But then why have 
a config tool when it only does half of the work.

Suggestions?



> On 24 Nov 2023, at 13:39, H. Nikolaus Schaller  wrote:
> 
> Great!
> 
> a) what is the entry for /etc/apt/sources.list?
> 
> The I can test a little
> 
> b) a next logical step would be to add meta-packages for
> 
>   - gap-minimal
>   depending on gnustep2 package + subpackages for each GAP 
> application
>   - gap full (some more less essential packages)
>   depending on gap-minimal
>   - gsde
>   depdendent on gap-minimal and some X11 setup and other libs and 
> apps (e.g. window manager)
> 
> Then it becomes really user-friendly to install a full GNUstep desktop...
> 
> BR,
> Nikolaus
> 
> 
>> Am 24.11.2023 um 13:11 schrieb Andreas Fink > <mailto:af...@list.fink.org>>:
>> 
>> gnustep2 sounds logical as its a logical upgrade path from old non arc.
>> 
>> 
>> I have built it that way now on repo.gnustep.ch <http://repo.gnustep.ch/>
>> 
>> debian12 on intel and arm64
>> 
>> armhf (raspberry pi), ubuntu22 (intel, arm64) will follow
>> 
>> i also have built a metapackage named "gnustep2" if you install this, you 
>> basically get base, gui, back, corebase, libobjc2, libdispatch, libiconv
>> 
>> 
>>> On 24 Nov 2023, at 12:42, H. Nikolaus Schaller >> <mailto:h...@goldelico.com>> wrote:
>>> 
>>> It seems as if API incompatiblities in libraries are usually denoted by a 
>>> numerical suffix.
>>> 
>>> E.g. libfi6, libffi7, libffi8
>>> But there is also libjpeg62-turbo.
>>> 
>>> Here are some hints.
>>> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names
>>> 
>>> So although it is clear that it must differ in "package" name, I would say 
>>> it is a little arbitrary. But is a decision carved in stone for quite some 
>>> time.
>>> 
>>> Personally I would vote for gnustep2 (alluding to libobjc2).
>>> 
>>>> Am 24.11.2023 um 11:23 schrieb Andreas Fink >>> <mailto:af...@list.fink.org>>:
>>>> 
>>>> The question now is what naming to choose
>>>> 
>>>> gnustep2...?
>>>> gnustep-arc..?
>>>> gnustep-clang-... ?
>>>> 
>>>> 
>>>> 
>>>>> On 24 Nov 2023, at 11:04, Riccardo Mottola >>>> <mailto:riccardo.mott...@libero.it>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> let me try to explain a little the compatibility issue. I am not debating 
>>>>> if GCC is better or worse, but you want to provide an repository (would 
>>>>> be "overlay" in gentoo terms) to Debian or Ubuntu, which provides 
>>>>> differently configured packages. Runtime (in short, let's say ARC here) 
>>>>> is the major difference, but it could also be layout, root directory, etc.
>>>>> The issue is that debian and ubuntu already provide GS packages which are 
>>>>> configured differently from "yours" and you cannot control how Debian 
>>>>> names its packages, only "your".
>>>>> 
>>>>> I would configure these package e.g. with --with-layout=gnustep --prefix=/
>>>>> 
>>>>> This compatibility will remain even if in the future things will change. 
>>>>> GCC my acquire ARC and libobcj2, it will still be an issue for other 
>>>>> things. Debian might switch to clang, but you still have a different 
>>>>> layout...
>>>>> 
>>>>> Also the amount of packages offered by you might differ. I suppose they 
>>>>> easily can be "more" because you could provide anything GNUstep has, but 
>>>>> you might choose not.
>>>>> 
>>>>> You cannot control how debian names their packages right now you

Re: Debian12 repository.

[Andreas Fink]

gnustep2 sounds logical as its a logical upgrade path from old non arc.


I have built it that way now on repo.gnustep.ch <http://repo.gnustep.ch/>

debian12 on intel and arm64

armhf (raspberry pi), ubuntu22 (intel, arm64) will follow

i also have built a metapackage named "gnustep2" if you install this, you 
basically get base, gui, back, corebase, libobjc2, libdispatch, libiconv


> On 24 Nov 2023, at 12:42, H. Nikolaus Schaller  wrote:
> 
> It seems as if API incompatiblities in libraries are usually denoted by a 
> numerical suffix.
> 
> E.g. libfi6, libffi7, libffi8
> But there is also libjpeg62-turbo.
> 
> Here are some hints.
> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_package_file_names
> 
> So although it is clear that it must differ in "package" name, I would say it 
> is a little arbitrary. But is a decision carved in stone for quite some time.
> 
> Personally I would vote for gnustep2 (alluding to libobjc2).
> 
>> Am 24.11.2023 um 11:23 schrieb Andreas Fink :
>> 
>> The question now is what naming to choose
>> 
>> gnustep2...?
>> gnustep-arc..?
>> gnustep-clang-... ?
>> 
>> 
>> 
>>> On 24 Nov 2023, at 11:04, Riccardo Mottola  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> let me try to explain a little the compatibility issue. I am not debating 
>>> if GCC is better or worse, but you want to provide an repository (would be 
>>> "overlay" in gentoo terms) to Debian or Ubuntu, which provides differently 
>>> configured packages. Runtime (in short, let's say ARC here) is the major 
>>> difference, but it could also be layout, root directory, etc.
>>> The issue is that debian and ubuntu already provide GS packages which are 
>>> configured differently from "yours" and you cannot control how Debian names 
>>> its packages, only "your".
>>> 
>>> I would configure these package e.g. with --with-layout=gnustep --prefix=/
>>> 
>>> This compatibility will remain even if in the future things will change. 
>>> GCC my acquire ARC and libobcj2, it will still be an issue for other 
>>> things. Debian might switch to clang, but you still have a different 
>>> layout...
>>> 
>>> Also the amount of packages offered by you might differ. I suppose they 
>>> easily can be "more" because you could provide anything GNUstep has, but 
>>> you might choose not.
>>> 
>>> You cannot control how debian names their packages right now you can't just 
>>> call them legacy.
>>> 
>>> Andreas Fink wrote:
>>>> 
>>>>> base: 1.29
>>>>> gui: 0.30
>>>>> back: 0.30
>>>>> 
>>>>> Randomly checking some other apps shows they are op to release 
>>>>> (ProjectCenter, gorm, GNUMail)
>>>> Does that version support ARC?
>>> 
>>> It is irrelevant, those versions are current versions, that is what I 
>>> wanted to show. It depends on how they are compiled and they are compiled 
>>> with gcc, so without ARC.
>>> For all users which are not developers, they will not care, they install an 
>>> application and it works. Most applications we have do not require ARC.
>>> Those who notice are mostly developers now. Or in the future more apps will 
>>> be ARC-only, who nows.
>>> 
>>>> As far as I remember gcc simply doesn't support it. Sticking around with 
>>>> gcc is a dead end. It looks to me like gcc never will ever support 
>>>> objective-2.0 fully.
>>>> I never even considered the debian packages because ARC does not work with 
>>>> them and thats kind of mandatory now.
>>> 
>>> While it is up for debate if GCC is a dead-end or not, it was not my point. 
>>> You need to consider debian packages, since they exist and are in the 
>>> official repositories.
>>> While the libobjc2 runtime is "runtime" compatible with non-ARC code, it is 
>>> (no longer is?) binary compatible with it. So you have to cover e.g. these 
>>> two scenarios:
>>> 
>>> Debian repo first:
>>> 1) debian user installs some GNUstep user packages. E.g GWorkspace, 
>>> Terminal and PRICE. They pull in of course gnustep core libraries
>>> 2) user wants to develop, installs ProjectCenter, dev packages, ecc
>>> 3) user needs ARC, adds your repository
>>> 4) user needs to replace existing packages with "your" packages. All of 
>>> the

Re: Debian12 repository.

[Andreas Fink]

The question now is what naming to choose

gnustep2...?
gnustep-arc..?
gnustep-clang-... ?



> On 24 Nov 2023, at 11:04, Riccardo Mottola  wrote:
> 
> Hi,
> 
> let me try to explain a little the compatibility issue. I am not debating if 
> GCC is better or worse, but you want to provide an repository (would be 
> "overlay" in gentoo terms) to Debian or Ubuntu, which provides differently 
> configured packages. Runtime (in short, let's say ARC here) is the major 
> difference, but it could also be layout, root directory, etc.
> The issue is that debian and ubuntu already provide GS packages which are 
> configured differently from "yours" and you cannot control how Debian names 
> its packages, only "your".
> 
> I would configure these package e.g. with --with-layout=gnustep --prefix=/
> 
> This compatibility will remain even if in the future things will change. GCC 
> my acquire ARC and libobcj2, it will still be an issue for other things. 
> Debian might switch to clang, but you still have a different layout...
> 
> Also the amount of packages offered by you might differ. I suppose they 
> easily can be "more" because you could provide anything GNUstep has, but you 
> might choose not.
> 
> You cannot control how debian names their packages right now you can't just 
> call them legacy.
> 
> Andreas Fink wrote:
>> 
>>> base: 1.29
>>> gui: 0.30
>>> back: 0.30
>>> 
>>> Randomly checking some other apps shows they are op to release 
>>> (ProjectCenter, gorm, GNUMail)
>> Does that version support ARC?
> 
> It is irrelevant, those versions are current versions, that is what I wanted 
> to show. It depends on how they are compiled and they are compiled with gcc, 
> so without ARC.
> For all users which are not developers, they will not care, they install an 
> application and it works. Most applications we have do not require ARC.
> Those who notice are mostly developers now. Or in the future more apps will 
> be ARC-only, who nows.
> 
>> As far as I remember gcc simply doesn't support it. Sticking around with gcc 
>> is a dead end. It looks to me like gcc never will ever support objective-2.0 
>> fully.
>> I never even considered the debian packages because ARC does not work with 
>> them and thats kind of mandatory now.
> 
> While it is up for debate if GCC is a dead-end or not, it was not my point. 
> You need to consider debian packages, since they exist and are in the 
> official repositories.
> While the libobjc2 runtime is "runtime" compatible with non-ARC code, it is 
> (no longer is?) binary compatible with it. So you have to cover e.g. these 
> two scenarios:
> 
> Debian repo first:
> 1) debian user installs some GNUstep user packages. E.g GWorkspace, Terminal 
> and PRICE. They pull in of course gnustep core libraries
> 2) user wants to develop, installs ProjectCenter, dev packages, ecc
> 3) user needs ARC, adds your repository
> 4) user needs to replace existing packages with "your" packages. All of them! 
> Even if they have the same "version" number they need to be mutually exclusive
> 5) if a package is not provided by your package it needs to be removed. E.g. 
> you provide core, ProjectCenter and GWorkspace, but not Terminal and PRICE. 
> They need to me deleted because of unavailable dependency
> 
> GS repo first (happy flow)
> 1) debian user does not have any GS app or library installed
> 2) User adds your GS repos, install what it needs, e.g. Core, ProjectCenter 
> and GWorkspace
> 3) user attempts to add Terminal and PRICE which you do not provide, he needs 
> to fail to install the debian provided versions
> 
>> What incompatibilities do we end up having if we use the new runtime 2.0 
>> only?
>> non ARC written code can still be executed. What other clashes will we face?
> 
> To my knowledge and experience, in most code I am involved in there is no 
> end-user difference. I have two workstations, they run the "same" software 
> (all gnustep core tool & apps, all GAP apps + PRICE and some custom apps none 
> of which needs objc2) one on linux with GCC and one with FreeBSD and 
> clang/libobjc2 and they all compile and run the same. Provided you are on a 
> fully supported arch/OS combination, no issues.
> 
> Sure there are differences when you debug, compile and things. There may be 
> bugs, e.g. do that on NetBSD and with libobjc2 your exceptions won't work.
> 
> I wanted to stress the "package tree" incompatibility issue, where mixing is 
> impossible for many reasons, not just compiler and runtime.
> 
> Riccardo

Re: Debian12 repository.

[Andreas Fink]

its not only about converting your code. There is a gazillion of libraries 
which users use which had been developed by others. Converting everything 
backwards is a drawback.

Think of if you try to convert the linux kernel back to K C. Its doable but 
its a very bad idea.

My main app originally was in C. I moved to ObjectiveC due to its excellent 
memory mansgement. Never the less I managed to forget a few release calls 
eating up memory. ARC has severely simplified my life. Going back would mean 
changing 500'000 lines of code. Errors will sure be created.

--
Sent from Canary (https://canarymail.io)

> On Montag, Nov. 20, 2023 at 4:33 PM, H. Nikolaus Schaller  (mailto:h...@goldelico.com)> wrote:
>
>
> > Am 20.11.2023 um 16:10 schrieb Andreas Fink :
> >
> > Without support for ARC, the vast majority of code written in the past 15 
> > years will not work (or eat memory without ever freeing it up). Apple's 
> > reference guide to Objective C 2.0 which introduces ARC is from 2008!
>
> Well, if you know the alloc/retain/release/copy rules it is just some 
> diligent work to convert ARC to MRC code. Has to be done once and believe me, 
> I have done it several times. Wasn't difficult. Then also/still runs on macOS.
>
> But you are right, if ObjC 2.0 was introduced 15 years ago it is only us 
> "old-timers" who still know the MRC rules. Although Linux kernel programmers 
> should also be familiar with get/put calls for refcounting. And their devm 
> mimicks the ARP.
>
> BR,
> Nikolaus

Re: Debian12 repository.

[Andreas Fink]

On 20 Nov 2023, at 15:39, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Andreas Fink wrote:
>> As far as renaming goes, well the packages in debian are so far outdated and 
>> seem no longer maintained that we should try to get a newer version into 
>> debian at some point.  But im not sure on how that process works . It might 
>> fail due to non support of gcc and maybe some platforms (such as RiscV 
>> because even clang fails to install currently).
>> 
> 
> this is not correct. If you check the current debian unstable packages, they 
> are quite up-to-date.
> 
> https://packages.debian.org/search?keywords=gnustep=names=unstable=all
> 
> Gives us:
> 
> base: 1.29
> gui: 0.30
> back: 0.30
> 
> Randomly checking some other apps shows they are op to release 
> (ProjectCenter, gorm, GNUMail)

Does that version support ARC?

As far as I remember gcc simply doesn't support it. Sticking around with gcc is 
a dead end. It looks to me like gcc never will ever support objective-2.0 fully.
I never even considered the debian packages because ARC does not work with them 
and thats kind of mandatory now.

So if its compiled with gcc with the old runtime, we are in dead water for the 
future. clang is the only way for modern Objective-C which I think is mandatory 
to attract any decent Objc-developers to even consider GNUStep. One of the key 
targets of GNUStep is to be feature compatible (where possible) with MaOS which 
makes it a prime candidate for porting apps from MacOS to Linux and other Unix 
platforms. Without support for ARC, the vast majority of code written in the 
past 15 years will not work (or eat memory without ever freeing it up). Apple's 
reference guide to Objective C 2.0 which introduces ARC is from 2008!

In my eyes, the best would be to have ARC versions in a repo which are built 
with clang and will end up in debian stable at some time.
or have two version. gnustep and gnustep-legacy (non ARC). But I think it would 
not be compatible somehow to have both installed.

We can not avoid that we have to do a transition to clang.

So lets stick our heads together and decide on how we can make this as smooth 
as possible.

What incompatibilities do we end up having if we use the new runtime 2.0 only?
non ARC written code can still be executed. What other clashes will we face?

Repo for debian

[Andreas Fink]

Hello all

I'm working on setting up a debian repository wtih a up to date build of 
debian12 and ubuntu22 for amd64 and arm64 architectures.
My current repo installs all on /usr/local/ but for proper system wide use /usr 
should be used as prefix instead.

so I use

export PREFIX="/usr"

cmake ... -DCMAKE_INSTALL_PREFIX=${PREFIX} ...

and

./configure --prefix=${PREFIX}

gnustep-make also has
--with-layout=debian

when configuring the individual packages

this seem to do the trick but I fail with gnustep-gui somehow

This one seems to always install into /usr/local whatever I do. Nothing goes 
into /usr/lib or /usr/include

by looking at the config I only see these which should end up in /usr/local

# NB: $prefix will be added to all the MAKEFILES/SYSTEM/NETWORK/LOCAL
GNUSTEP_LOCAL_APPS=/local/lib/GNUstep/Applications
GNUSTEP_LOCAL_ADMIN_APPS=/local/lib/GNUstep/Applications
GNUSTEP_LOCAL_WEB_APPS=/local/lib/GNUstep/WebApplications
GNUSTEP_LOCAL_TOOLS=/local/bin
GNUSTEP_LOCAL_ADMIN_TOOLS=/local/sbin
GNUSTEP_LOCAL_LIBRARY=/local/lib/GNUstep
GNUSTEP_LOCAL_HEADERS=/local/include/GNUstep
GNUSTEP_LOCAL_LIBRARIES=/local/lib
GNUSTEP_LOCAL_DOC=/local/share/GNUstep/Documentation
GNUSTEP_LOCAL_DOC_MAN=/local/share/man
GNUSTEP_LOCAL_DOC_INFO=/local/share/info

So I'm kind of lost on where this is coming from

/bin/gnustep-config --installation-domain-for=SYSTEM
returns LOCAL

Any hints?

Andreas



signature.asc
Description: PGP signature

Re: Brutal review…

[Andreas Fink]

consensus on how official packages should be built. descriptions etc. and ill 
set aside a repo for it. it can also host apps etc but that has to be built by 
someone else

--
Sent from Canary (https://canarymail.io)

> On Mittwoch, Okt. 18, 2023 at 3:16 PM, Daniel Boyd  (mailto:danieljb...@icloud.com)> wrote:
> That’s awesome—let me know if I you can use any help
>
> Sent from my iPhone
>
> > On Oct 18, 2023, at 09:05, Andreas Fink  wrote:
> >
> > 
> >
> >
> > --
> > Sent from Canary (https://canarymail.io)
> >
> >
> > i do that already. I volunteer to host an official one. I run a ISP 
> > Backbone across Europe and Africa with multiple 100G links so Im ready for 
> > a lot of downloads :-).
> > I usually build into /usr/local for my own use. Im not sure how the old 
> > packages where built. But i would be ready to rebuild the "official way 
> > with clang /ARC support etc. My personal use is mainly gnustep-base for my 
> > ulib project as my apps dont need a desktop gui. But i usually build / 
> > package gui/back as well.
> >
> > Debian12 on amd64 and arm64 is what I build regularly. arm32bit for 
> > Raspberry Pi as well but thats on Debian 10 (and takes forever to build). 
> > Risc-V i tried but failed due to missing clang (would have to build that 
> > from source which takes forever). But hopefully we will get there 
> > eventually.
> >
> > So once we decide the parameters and build structure we want, we can make 
> > it happen.
> >
> >
> > > On Mittwoch, Okt. 18, 2023 at 2:35 PM, Daniel Boyd 
> > > mailto:danieljb...@icloud.com)> wrote:
> > > >
> > > >
> > > > I haven't followed all discussions but if there is someone who sets up 
> > > > a private debian repository for all gnustep related packages and 
> > > > maintains it, everyone could contribute. And it just needs an 
> > > > additional entry in /etc/apt/sources.list or a file in 
> > > > /etc/apt/sources.list.d
> > > >
> > > >

Re: Brutal review…

[Andreas Fink]

--
Sent from Canary (https://canarymail.io)

i do that already. I volunteer to host an official one. I run a ISP Backbone 
across Europe and Africa with multiple 100G links so Im ready for a lot of 
downloads :-).
I usually build into /usr/local for my own use. Im not sure how the old 
packages where built. But i would be ready to rebuild the "official way with 
clang /ARC support etc. My personal use is mainly gnustep-base for my ulib 
project as my apps dont need a desktop gui. But i usually build / package 
gui/back as well.

Debian12 on amd64 and arm64 is what I build regularly. arm32bit for Raspberry 
Pi as well but thats on Debian 10 (and takes forever to build). Risc-V i tried 
but failed due to missing clang (would have to build that from source which 
takes forever). But hopefully we will get there eventually.

So once we decide the parameters and build structure we want, we can make it 
happen.

> On Mittwoch, Okt. 18, 2023 at 2:35 PM, Daniel Boyd  (mailto:danieljb...@icloud.com)> wrote:
> >
> >
> > I haven't followed all discussions but if there is someone who sets up a 
> > private debian repository for all gnustep related packages and maintains 
> > it, everyone could contribute. And it just needs an additional entry in 
> > /etc/apt/sources.list or a file in /etc/apt/sources.list.d
> >
> >

Re: Brutal review…

[Andreas Fink]

thats something i totally agree. Im building my own gnustep packages since many 
years (since Debian 8) because without clang and objC 2.0 features such as ARC 
i can not get anything done. Clang version and specific linker dependencies 
dont help new users to succeed under Debian neither. Cross Platform development 
is important for me as i use the same codebase under MacOS and Linux and FreeBSD

--
Sent from Canary (https://canarymail.io)

> On Dienstag, Okt. 17, 2023 at 8:06 PM,  (mailto:kyle.card...@icloud.com)> wrote:
> One major problem I see is that distributions package a completely 
> unconfigured and outdated version. Part of the motive for my little Agora 
> project is to address that issue, by shipping a fully configured, up to date 
> GNUstep environment.
>
> > On Oct 17, 2023, at 9:18 AM, Gregory Casamento  
> > wrote:
> > This guy is misled about a lot of things but his experience reflects the 
> > experience a lot of people have. Let’s try to improve this. This literally 
> > upset me.
> >
> > https://www.youtube.com/live/z0unnqzaoLQ?si=J3FKCK7gGOyEmUCo
> > Yours, GC

Re: Is possible build latest gnustep from github rep on windows?

[Andreas Fink]

I remember having seen similar stuff in the past (but thats like 10 years ago) 
when I ported Mac code to Linux. The work around was to force initialisation 
for some stuff.
Unfortunately I can't remember what was my workaround for it but it might be 
stuff which NSApplication initializes which never gets called when you call 
NSLog from main directly.

> On 4 Jul 2023, at 09:28, Frederik Seiffert  wrote:
> 
> That exit code is STATUS_ACCESS_VIOLATION, I’m guessing it’s crashing 
> somewhere in the GNUstep initialization.
> https://www.magnumdb.com/search?q=1073741819
> 
> I think you won’t get any further without using a debugger to get a stack 
> trace of the crash. You should be able to use either Visual Studio or lldb 
> for that.
> 
>> Am 04.07.2023 um 03:02 schrieb bellabs :
>> 
>> Hello RK, first of all thank you for your reply and advice. I am currently 
>> using gnustep-tools-windows-msvc, but the program does not work properly 
>> using code that involves objects, such as the following code:
>> @interface HelloWorld : NSObject
>> - (void)sayHello;
>> @end
>> 
>> @implementation HelloWorld
>> - (void)sayHello {
>>  NSLog(@"Helo RK");
>> }
>> @end
>> 
>> int main() {
>>  printf("1\n");
>>  HelloWorld *hello = [[HelloWorld alloc] init];
>> printf("2\n");
>>  [hello sayHello];
>>  printf("3\n");
>> 
>>  return 0;
>> }
>> 
>> 
>> log
>> C:\demo>a.exe
>> 1
>> 
>> C:\demo>echo %errorlevel%
>> -1073741819
>> 
>> All the gnustep libraries and compilation commands I use are provided by 
>> https://github.com/gnustep/tools-windows-msvc.
>> This means that the program is terminated after only the first printf 
>> statement is executed. I have tested this code on linux and it is fully 
>> compiled and run properly. Do you know what is going on here? Thanks!
>> 
>> Best regards!
> 

Re: GNUstep runtime errors

[Andreas Fink]

I see you are trying on Debian 12.

Things to remember on Debian if you use llvm and ARC.

1. you must use the new runtime libobjc2

2. always use the gold linker and not the default "ld.bfd" linker or you will 
end up compiling but not working

easiest way to change this is by changing the symlink /usr/bin/ld to point to 
ld.gold (which is a symlink to x86_64-linux-gnu-ld.gold)

3. Choose carefully which clang version you use.  Prior to release 8 there 
where issues. On Debian 11 there where issues with too new versions. On Debian 
12, the standard clang 14.0.6 works fine for me.

 
here is how I build on Debian 12 and it works consistently.

https://github.com/andreasfink/ulib/blob/master/doc/README-Debian12-bookworm.txt


Note: I do not use the old runtime or gcc ever for GNUStep as my code all 
mandatory requires ARC. So libobjc2 and clang/llvm is the only way which I can 
get anything done.



> On 23 Jun 2023, at 13:29, bellabs  wrote:
> 
> Erorr: Version 2 Objective-C ABI may not be mixed with earlier versions. 
> Aborted
> I wasted almost a week in this problem, all kinds of methods have been tried 
> or not solved, I hope to get your help! I've already referred to 
> "https://github.com/gnustep/libobjc2/issues/196; and 
> "https://github.com/gnustep/libobjc2;, but I still don't understand what the 
> problem is. But I still don't understand where the problem is? How can I 
> solve it? I have even recompiled GNUstep, libobjc2 with the latest clang, but 
> the problem still exists. As long as -fobjc-runtime is set to gnustep-2.0 it 
> will not compile, it can only be set to 1.9. Can you tell me how to solve 
> this problem? What is the nature of this problem? 
> 
> Forgive me, I am really powerless to seek your help, google I only found a 
> piece of information about this problem is the above mentioned link, I also 
> asked the GPT but the answer is not the answer!
> Thanks! 
> 
> Best regards!
> 

Re: libobcj2 on GCC

[Andreas Fink]

The biggest problem with GCC is the lack of support of objective-C 2.0 patterns.
Especially ARC, which every ObjC application or library developed on the mac 
the last 10 years or so for sure uses.


> On 5 Apr 2023, at 10:05, Steven R. Baker  wrote:
> 
> Hiya,
> 
> Who here best knows what needs to be done to bring GCC's objc up to date?  Is 
> it as "simple" as porting libobjc2 to GCC?  I'd like to see GCC's 
> implementation as the "gold standard."
> 
> Is there someone on this list I can pay out of my own pocket to work on this 
> without absolutely breaking the bank?
> 
> I'd love to see it done, but I don't really have skills in compiler 
> development.  (Although I'd love to learn.)
> 
> Cheers!
> 
> -Steven
> 
> 

Re: Base 1.28.1 API/ABI break?

[Andreas Fink]

This is what I got while testing on the 4 main platforms. (ubuntu22 to follow 
soon)

Debian 11 amd64:OK

Debian 11 arm64 failed
Failed test: (2023-01-09 08:48:49.174 +0100) general.m:37 ... 
-classNamed returns the correct class
Failed test: (2023-01-09 08:48:49.175 +0100)   general.m:61 ... 
-principalClass returns TestClass for +bundleForClass:[TestClass class]

Debian 10 amd64 failed
Failed test: (2023-01-09 08:48:36.765 +0100) general.m:37 ... 
-classNamed returns the correct class
Failed test: (2023-01-09 08:48:36.765 +0100)   general.m:61 ... 
-principalClass returns TestClass for +bundleForClass:[TestClass class]

Debian 10 arm64 failed
Failed set:basic.m:9 ... problem in TLS support.
(this might be to build environment. Not sure what it could be. This one is 
built on a raspberry pi 4)

So it seems the  failed test for class names seems independent of architecture 
or Debian version which is rather puzzling...

> On 9 Jan 2023, at 08:28, Fred Kiefer  wrote:
> 
> 
> 
>> Am 09.01.2023 um 07:58 schrieb Andreas Fink :
>> 
>> I usually build packages for Debian 10 & 11 for amd64 and arm64
>> 
>> I have encountered make check returning an error on Debian11 arm64 but not 
>> on Debian 11 amd64
>> 
>> Built on Debian 11 intel:All OK!
>> Built on Debian 11 on arm64: 2 Failed tests
>> Failed test: (2023-01-09 07:39:12.574 +0100) general.m:37 ... 
>> -classNamed returns the correct class
>> Failed test: (2023-01-09 07:39:12.576 +0100)   general.m:61 ... 
>> -principalClass returns TestClass for +bundleForClass:[TestClass class]
>> 
>> I'm surprised as this stuff is not really architecture specific usually.
>> 
> 
> Which version of libobjc are you building against and is it the same for both 
> architectures?

Re: Base 1.28.1 API/ABI break?

[Andreas Fink]

I usually build packages for Debian 10 & 11 for amd64 and arm64

I have encountered make check returning an error on Debian11 arm64 but not on 
Debian 11 amd64

Built on Debian 11 intel:   All OK!
Built on Debian 11 on arm64:2 Failed tests
Failed test: (2023-01-09 07:39:12.574 +0100) general.m:37 ... 
-classNamed returns the correct class
Failed test: (2023-01-09 07:39:12.576 +0100)   general.m:61 ... 
-principalClass returns TestClass for +bundleForClass:[TestClass class]

I'm surprised as this stuff is not really architecture specific usually.


> On 8 Jan 2023, at 09:57, Richard Frith-Macdonald 
>  wrote:
> 
> 1 Announcement
> **
> 
> The GNUstep Base Library, version 1.29.0, is now available.
> 
> 1.1 What is the GNUstep Base Library?
> =
> 
> The GNUstep Base Library is a library of general-purpose, non-graphical
> Objective C objects.  For example, it includes classes for strings,
> object collections, byte streams, typed coders, invocations,
> notifications, notification dispatchers, moments in time, network ports,
> remote object messaging support (distributed objects), and event loops.
> 
>   It provides functionality that aims to implement the non-graphical
> portion of the OpenStep standard (the Foundation library).
> 
>   There is more information available at the GNUstep homepage at
> 'http://www.gnustep.org'.
> 
>   This is a bugfix release increasing the library version number to
> reflect ABI change that should have been included when the previous
> release was made.
> 
> 1.2 Noteworthy changes in version '1.29.0'
> ==
> 
>   * Library version changed from 1.28 to 1.29
> 
> 1.3 Where can you get it? How can you compile it?
> =
> 
> The gnustep-base-1.29.0.tar.gz distribution file has been placed at
> .
> 
>   It is accompanied by gnustep-base-1.29.0.tar.gz.sig, a PGP signature
> which you can validate by putting both files in the same directory and
> using:
> 
> gpg --verify gnustep-base-1.29.0.tar.gz.sig
> 
>   Signature has been created using the key with the following
> fingerprint:
> 
> 83AA E47C E829 A414 6EF8  3420 CA86 8D4C 9914 9679
> 
>   Read the INSTALL file or the GNUstep-HOWTO for installation
> instructions.
> 
> 1.4 Where do I send bug reports?
> 
> 
> Please log bug reports on the GNUstep project page
>  or send bug reports to
> .
> 
> 

Re: The State of Debian Packaging

[Andreas Fink]

The issue is that the debian packages are depending on gcc while most use clang 
with ARC for todays builds with the new runtime.
Thats still an open point. I personally build my own debian packages since a 
while for Debian 10 & 11 and now also Ubuntu 22.04LTS on x86_64 and arm64 so I 
can pull it from my own Repo for my own projects. I would like to use the 
standard repo versions but for me not having support for ARC and clang makes it 
impossible.

While I understand some folks still want to be backwards compatible with gcc 
installs, what about a separate tree with arc/clang support? does that work 
with debian standard repo or does it all still require to be workable with gcc?


I will look into gdp now... my builds are done with simple shell scripts...


> On 25 Dec 2021, at 13:14, Steven R. Baker  wrote:
> 
> Heya folks,
> 
> I've been following the other threads, but haven't been computering as 
> actively over the holidays, so I wanted to give an overview and "source of 
> truth" on the Debian packages of GNUstep.
> 
> Sorry for the long one, but I'm aiming to give a background on the "how and 
> why" of Debian packaging; the current state of things; how to get newer 
> version of things; and how to help.
> 
> I intend to make a README for GNUstep in Debian and publish it, and a lot of 
> what is here will go there.  But for now, you'll have to wade through this 
> email.
> 
> Background: Debian packages are often considered "wildly out of date," and 
> this is only true because of the way the Debian release process works.
> 
> Debian has three "current" distributions.  "stable", which is the current 
> released version.  "unstable" (called sid, which is a backronym now meaning 
> Still In Development) is where new package versions are uploaded.  Many 
> daily-drivers of Debian use "testing", which is unstable packages delayed by 
> a period of time (two weeks from memory) and only "promoted" to testing when 
> there aren't any release critical (RC) bugs reported against them.
> 
> The Debian packages are maintained by the Debian GNUstep packaging team, 
> which is sorely understaffed.
> 
> You can find the repos for the packaging efforts on Debian Salsa, which is 
> Debian's GitLab instance: https://salsa.debian.org/gnustep-team  Every 
> GNUstep related package that is in Debian (or will be RSN) is included there.
> 
> Let's use an example to demonstrate the current state of things, gnustep-base 
> which can be found here: https://salsa.debian.org/gnustep-team/gnustep-base
> 
> The `master` branch contains the release that is currently in sid.  In the 
> case of gnustep-base, that's 1.28.0.  But here's where it gets interesting.  
> Using the Debian watch program, the GNUstep FTP server is monitored for new 
> releases.  You can see the watch file here: 
> https://salsa.debian.org/gnustep-team/gnustep-base/-/blob/master/debian/watch
> 
> There are also branches called `stretch` and `buster` which is the source 
> from which the packages in those releases is built.
> 
> Debian Salsa should grab the latest release when it hits the FTP server and 
> create a new branch.
> 
> If you check out that repo and build the package (more details later, but try 
> `debuild -uc -us` to start) you should get a working package.  If you don't, 
> you need to look in `debian/patches` and see if the patches need to be 
> updated or removed to get it to build appropriately.
> 
> If you make changes, PLEASE submit a merge request so someone on the GNUstep 
> packaging team can review it and include it.
> 
> The tool for building packages from the GitLab sources is called `gbp` and is 
> in the `git-buildpackage` package.  You will have to do some setup, there is 
> documentation.
> 
> So, how can you help?
> 
>   1) Please learn about gbp and look at the repositories to see if 
> anything is missing a latest version.  If it is, we need to update the 
> CI/DevOps stuff in GitLab to do this automatically.
>   2) Build and test the latest versions of things.
>   3) Create new packages for things that don't exist.
> 
> My intention is to use these sources to build a new repository of up-to-date 
> packages, and add some missing things (libs-xcode, buildtool, and some apps.) 
>  I have made some progress on this, and intend to get back to it in the new 
> year afresh.
> 
> The best next-step for us is to maintain a repository (I am volunteering for 
> this in the new year) that contains good packages of the latest-released 
> stuff.  So people can simply add a new package repository and get latest 
> GNUstep bits.
> 
> If you have questions or concerns, please reply in thread.  It will really 
> help me finish outlining my documentation for this.
> 
> I hope this helps a bit.
> 
> Cheers!
> 
> -Steven
> 
> 

clang under debian broken when compiling libobjc2

[Andreas Fink]

FYI,

The current clang-16 in the debian 10 repository does not work when
compiling libobjc2
Compiling works but most of the tests segfault

Changing to clang-11 everything works
clang-9 also works.

What has changed in the compiler that it breas Objc?




signature.asc
Description: OpenPGP digital signature

Re: gnustep.org has been down for the past few days

[Andreas Fink]

why you dont use innodb as engine? much less troubles in case of crashes and 
reboots

> On Sonntag, Sept. 04, 2022 at 8:02 PM, Ivan Vučica  (mailto:i...@vucica.net)> wrote:
> Update:
> - I added wiki.gnustep.org to DNS as well -- it was an omission not to
> add it. Please REFRAIN FROM EDITS until further notice as YOUR EDITS
> WILL NOT BE MIGRATED.
> - I am still fighting MySQL/MariaDB:
> - the previous server has an unknown default character set/collation
> (latin1 and not utf8, likely, as I managed to import _gsweb with it)
> - aside from timezone precision of "14" not meaning what the authors
> of schemas meant, it's also deprecated (this was the quickest of the
> fixes, just replace timestamp(14) with new maximum timestamp(6)
> - second fastest fix was TYPE=MyISAM changing into ENGINE=MyISAM
> - the previous server has an unknown timezone configured, and even
> worse, it is unclear what timezone the dates in the dump are in
> - specifically, some of the dates are failing to be inserted as
> they appear to be happening during nonexistent hours during March
> timezone switches
> - entertaining thing: varchar(255) is fine as primary key fitting
> inside MyISAM's 1000 bytes maximum  as long as utf8mb4 is not the
> character set in use
> - 4 * 255 = 1020
> - even though I suspect the old default was latin1, I am using
> utf8 which still fits inside 1000 bytes
>
> Now, after a few hours of fighting this, I've only completed the first
> out of five databases (gnustep_gsweb.sql, which might not even be in
> use).
>
> The next one, gnustep_mediawiki, is already being painful.
>
> I am unlikely to be done today.
>
> On Tue, Aug 30, 2022 at 10:59 PM Marco Cawthorne  wrote:
> >
> > On 2022-08-30 14:28:54 -0700 Ivan Vučica  wrote:
> >
> > > I've spent some time today on playing with Ansible thinking it may be
> > > better to do it sooner rather than later. I'll leave that aside for
> > > now.
> > >
> > > By the time I got to look at restoring MySQL databases, it simply got
> > > late. Turns out that the database dumps need to be manually fixed
> > > before they can be imported: schemas have changed between the version
> > > on the old server and MariaDB 10.x that I have on the new one. It
> > > should be relatively easy, if possibly labor intensive.
> > >
> > > I'll leave it for tomorrow.
> >
> > Thank you for all the work you do and for keeping us updated.
> > And thanks to Gregory for the quick redirects. At last we can browse most 
> > of the documentation again.
> >
> > Marco Cawthorne
> >
>

Re: Detecting memory leaks

[Andreas Fink]

One thing to look for is if you are running in threads, that every
thread should have its own autorelease pool being set up before doing
anything.


Alan Third wrote on 27.04.22 22:08:
> I'm investigating some memory that have been reported in the GNUstep
> port of Emacs. The reporter says they're getting warnings in the
> console about objects being autoreleased when there is no autorelease
> pool.
>
> Now, I'm pretty sure I know what's causing that particular problem,
> but I don't see these warnings so I can't be sure. Even if I
> intentionally break our autorelease pools I get nothing and I can't
> work out what I need to do to enable these messages.
>
> I suspect the difference is that they're using gcc and I'm using
> clang. I built my own GNUstep install using some instructions I can't
> find now.
>
> Any pointers that would help me debug this would be appreciated.
>
> Thanks!

Re: libobjc2 on Windows with clang 13 (crash prior to main)

[Andreas Fink]

I had issues with clang-14 and went back to clang-11 which always worked.
if you run the tests in libobj2 and/or gnustep-base they fail with
clang-14 under Debian 10 & 11. And if I remember correctly, they fail
before main() as in your case.
So I can imagine you run into the same issue.

David Vernon wrote on 17.02.22 01:03:
>
> Hello all. I’m brand new to the list. I work for Keysight Technologies
> on Eggplant – a commercial project that uses gnustep for our Windows
> port. I’m having some issues, and Greg Casamento has recommended that
> raise them here.
>
>  
>
> We build on Windows using msys64 and clang. I am trying to upgrade
> clang to the current version (v13) and I’m pretty much stuck. I can
> get libobjc2 and lib-base to build, but when I run a very simple test
> app is crashes prior to main.
>
>  
>
> The test program:
>
> #import 
>
> #include "stdio.h"
>
>  
>
> #if 0
>
>  
>
> @interface Test : NSObject
>
> @end
>
>  
>
> @implementation Test
>
> @end
>
>  
>
> #endif
>
>  
>
> int main (void)
>
> {
>
>   fprintf( stderr, "Hello World\n");
>
>   return 0;
>
> }
>
>  
>
> Run it like this and all is good: it prints “Hello World”. Flip the
> #if 0 to #if 1, and it crashes prior to main.
>
>  
>
> Gdb shows this stack trace:
>
> #0  0x7ffe8b92a263 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #1  0x7ffe8b8ecd24 in ntdll!memset () from
> C:\Windows\SYSTEM32\ntdll.dll
>
> #2  0x7ffe8b929111 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #3  0x7ffe8b855cc1 in ntdll!RtlGetCurrentServiceSessionId ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #4  0x7ffe8b855b74 in ntdll!RtlGetCurrentServiceSessionId ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #5  0x7ffe8b8547b1 in ntdll!RtlFreeHeap ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #6  0x7ffe89a99c9c in msvcrt!free () from
> C:\Windows\System32\msvcrt.dll
>
> #7  0x7ffe41ec8068 in +[GSBlock load] (self=,
>
>     _cmd=) at GSBlocks.m:55
>
> #8  0x7ffe66e4281d in objc_send_load_message ()
>
>    from C:\msys64\mingw64\bin\libobjc.dll
>
> #9  0x7ffe66e4356b in objc_resolve_class ()
>
>    from C:\msys64\mingw64\bin\libobjc.dll
>
> #10 0x7ffe66e4366c in objc_resolve_class_links ()
>
>    from C:\msys64\mingw64\bin\libobjc.dll
>
> #11 0x7ffe66e47e47 in __objc_exec_class ()
>
>    from C:\msys64\mingw64\bin\libobjc.dll
>
> #12 0x7ffe41ec80d0 in objc_load_function ()
>
>    from C:\msys64\mingw64\GNUstep\System\Tools\gnustep-base-1_28.dll
>
> #13 0x7ffe4209b9d2 in __do_global_ctors ()
>
>     at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/gccmain.c:44
>
> #14 0x7ffe41ec1233 in __DllMainCRTStartup (hDllHandle=0x7ffe41ec,
>
>     dwReason=1, lpreserved=0x12f5ef750)
>
>     at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtdll.c:184
>
> #15 0x7ffe8b849a1d in ntdll!RtlActivateActivationContextUnsafeFast ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #16 0x7ffe8b89c1e7 in ntdll!LdrGetProcedureAddressEx ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #17 0x7ffe8b89bf7a in ntdll!LdrGetProcedureAddressEx ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #18 0x7ffe8b89c000 in ntdll!LdrGetProcedureAddressEx ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #19 0x7ffe8b903c2a in ntdll!LdrInitShimEngineDynamic ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #20 0x7ffe8b8a4cdb in ntdll!LdrInitializeThunk ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #21 0x7ffe8b8a4b63 in ntdll!LdrInitializeThunk ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #22 0x7ffe8b8a4b0e in ntdll!LdrInitializeThunk ()
>
>    from C:\Windows\SYSTEM32\ntdll.dll
>
> #23 0x in ?? ()
>
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
>  
>
> Any ideas as to how I might proceed would be graciously appreciated.
>
>  
>
> Dave Vernon
>
> Keysight Technologies
>

Re: Should we split the project into two branches?

[Andreas Fink]

Question:
is it time to start working on libobjc3 with Swift support and support
for all platforms we want to support?
(if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).

Apple will run away in a decade with Swift only. So if our goal is to
keep OS X compatibility, then we have to think long term on how we think
we want to continue

I would thus suggest to make a list of pro & cons of the current
situation. Especially I want to know

a) which platforms are supported today with gcc and the old runtime
b) which platforms are supported today with gcc and libobjc2
c) which platforms are supported today with clang and the old runtime
d) which platforms are supported today with clang and libobjc2
e) which platforms do we want to support in the future.

I personally have no problem to drop MIPS as I never used it. Others
might have a different view.
Having gnustep-base in embedded systems without GUI might be useful.
But do they need all the new features we plan to add? Might it be better
to move that part to a "classic" release for historic systems?
I would like to see support for RISC-V as I see a lot of future growth
there.

I think its time to do a reality check to figure out commonly on where
we do want to see GNUStep in the future. What should it accomplish and
what are the pro's and cons of each.
Only if such facts are on the table, one can decide on a roadmap.


Max Chan wrote on 15.02.22 00:28:
>
>> On Feb 14, 2022, at 6:06 PM, Riccardo Mottola  
>> wrote:
>>
>> I continue to think that a restriction into core libraries is
>> acceptable, if it leaves the freedom for your "app code" (or... other
>> code you need of course).
>>
> The problem is that our core libraries are dreadfully outdated. It is on par 
> with Mac OS X 10.6.8, which is a decade old now. This whole Next branch idea 
> is to remove the restriction on the new branch so people interested in or 
> need new features can chase the latest features, a big one being Swift 
> interoperability, and leave the tasks of restoring compatibility to the main 
> branch as an “afterthought.”
>
>> PS: indeed I think there is no servce in continuing to denigrate our own
>> project, including menacing splits or fork. It was my first thought too,
>> but I hope it can be avoided, by a single solution with options or
>> configurations.
>>
> IMO it can eventually be done especially after we bring in Swift support, as 
> that gives us two parallel build systems, one of which has a hard dependency 
> on the new features. For people needs legacy support they can still use 
> gnustep-make and the makefiles; while people using new features skip 
> gnustep-make entirely and use Swift Package Manager instead. SPM hard depends 
> on Swift, which is one of the new language features I consider worth breaking 
> compatibility for.

Re: Should we split the project into two branches?

[Andreas Fink]

Riccardo Mottola wrote on 15.02.22 00:06:
> Hi Frederik,
>
>
> Frederik Seiffert wrote:
>> I’d never write any new *app* code without ARC, and would definitely
>> recommend converting any existing apps if you can control the
>> environment where they are built, but IMO it’s fine that the GNUstep
>> libraries don’t use it – it definitely doesn’t keep me from
>> contributing. Most of the code works and is well tested over the
>> years/decades, and so I’m not sure what exactly would be gained by a
>> conversion in comparison to the downside of loosing GCC users.
>
> thank you. As a more recent contributor, your words confort me. True
> that sometimes we had to smooth out some of your commits, but I found
> them and you or other fixed them, to the gain of all.
>
> I continue to think that a restriction into core libraries is
> acceptable, if it leaves the freedom for your "app code" (or... other
> code you need of course).
>
> As if so many people voicing here their opinion are actually
> contributing to core and have difficulties to do that. Most people are
> "users" in the senses I explained in my other mail.
>
> As you write, the loss could be big, but something could be gained: more
> compact code, with possibly (debatable!) less errors.
>
> Riccardo
>
> PS: indeed I think there is no servce in continuing to denigrate our own
> project, including menacing splits or fork. It was my first thought too,
> but I hope it can be avoided, by a single solution with options or
> configurations.


I have written code with and without ARC.
And even if I have tree decades of experience in developing applications
in C and other languages, I still manage to shoot into my foot in memory
management sometimes. It takes a hell of a lot of discipline.
This is one of the reasons why I moved to ObjC in the first place.
retain/release made things much more predictable and use after free
issue basically dissapeared over night. However sometimes I still ended
up in memory leaks because you jump out of a method with an error and
forgot to release what you retained. These are typical errors you will
see in ObjC without ARC and I think you will agree that ALL ObjC
developers have made such mistakes in the past. ARC solves that issue
and makes the life of the developer much much easier.

Im totally aware you can still write code without ARC. I would not have
an issue doing so while contributing to gnustep-base.
What I'm trying to say is that our own experience is not being mirrored
by young developers who came to ObjC in the last 10 years. They might
never have seen retain/release in their life. If you want to attract
such developers to contribute, you have to admit that staying with Objc
1.0 feature set is going to make it much harder for them. Furthermore,
the code is going to be overloaded with much more complex statements
than in ObjC 2.0.

Things like

    myDict[@"somekey"] =@"somevalue";

 is much quicker to write than

    [myDict setObject:@"somevalue" forKey:@"somekey"];


If you have learned the new way, you don't want to go back to the "old" way.
If you learned ObjC in the last 10 year, it will raise a lot of eyebrows
if you have never seen the "old" way.

its like if you force everyone to write Kernigan / Richie C instead of
ANSI C. Sure you can, but whats the point if ANSI-C is todays "standard".
While ANSI-C aged a bit more than ObjC 2.0 since, i still strongly
believe the syntactic sugar of Objc2.0 are highly beneficial to make
code more readable , more understandable.

So by supporting ObjC 2.0 features in the language and the runtime, we
can bring more ObjC developers to GNUStep contribution
By having a version for OjbC 1.0 and a version for ObjC 2.0, you
basically end up having two versions.

In Debian for example, if you do apt-get install gnustep, you end up
with a ObjC 1.0 only version. You can not write any modern apps with
that. Totally wasted.
If you buld a version with Objc2.0 support with libobjc2, then you can
do all the modern stuff, but then you are not backward compatible.

Or put it in other words. We ALREADY have two "branches". Its just not
git branches but how you compile them. So what user A does with GNUSteo
can not be replicated with what user B does.

And that is the conflict which we should solve.

And given GCC doesnt want to learn Obj2.0 support, I believe its going
to be a hard time to keep it in the future. There's a reason why Apple
dropped gcc.

Re: Should we split the project into two branches?

[Andreas Fink]

Richard Frith-Macdonald wrote on 14.02.22 17:43:
>
>> On 14 Feb 2022, at 14:59, Max Chan  wrote:
>>
>>
>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald 
>>>  wrote:
>>>
>>>
>>>
 On 14 Feb 2022, at 11:43, Max Chan  wrote:

 Dear List,

 There are over and over again arguments on moving on to LLVM/clang for 
 latest language features versus maintaining compatibility with 
 old/uncommon platforms and GCC,
>>> Really this is simply not the case among GNUstep developers.
>>> Those of us who actually use the stuff just work with whatever we 
>>> prefer/need, because GNUstep already works with both toolchains.
>> The hard requirement of allowing building using GCC means we are restricted 
>> to language features equivalent of OS X 10.6.8 or iOS 4.3.5,
> Please don't spread such nonsense on the mailing lists.
>
> The fact that we have a huge base of code that builds with both GCC and clang 
> (and a small part that only functions when built with clang) in no way 
> restricts us in the way we write new code.
>
> Having highly portable code is a strong point, but that doesn't mean that 
> *all* features are equally portable or that contributors are required to 
> write perfect portable code.
>
> It does the project a huge disservice to tell developers they 'have to use an 
> ancient version of the language'. Please don't do it.

It does the project a huge reality check to tell developers they 'have to use 
an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO GNUSTEP*'.
That's says it all.

Re: Clang/LLVM migration roadmap

[Andreas Fink]

Daniel Boyd wrote on 14.02.22 08:54:
> Riccardo,
>
> Thanks for the response. I agree there is certainly a distinction between the 
> user types and I, as a developer myself, was referring to #2. However, I 
> disagree that catering to each group is equally important at this juncture 
> for two reasons: 
>
> 1) GNUstep doesn’t currently have enough quality apps to attract user #1. 
> That is not to say, of course, that it has none, but I think it would be 
> uncontroversial to say that it could benefit from having more—a lot more. 
>
> 2) GNUstep’s utility comes not only from its general purpose end-user apps, 
> but also from its facility as a framework for people writing narrow-purpose, 
> highly customized apps. This is what I use GNUstep for primarily. My apps 
> will only ever be used by a small number of people in my company because they 
> are highly specialized to address a specific process or function unique to 
> us. Indeed, going back to the early 90’s, this has always been a strength of 
> the NEXTStep/OpenStep/GNUstep/Cocoa framework.
>
> For these two reasons, I believe it is more
> important for GNUstep to focus on attracting developers. And if you attract 
> more developers—particularly developers writing quality, general purpose 
> apps—that will, in turn, attract more end users. 
>
> Lastly, to your point about people having freedom to choose which tools they 
> want to use, I don’t disagree at all. This is FOSS and freedom is what makes 
> FOSS great. However, in the long run, if we want users of any kind to be able 
> to choose GNUstep at all, we need to grow the project now and that means 
> attracting more developers, in my humble opinion. 
>
> Cheers,
> Daniel
>
> Sent from my iPhone
>

I can only double that. If I look at myself, I use GNUstep because I
need portable apps on MacOS and Linux and other Unixes. If I would be
constrained to not using ARC, then basically, GNUstep would not be an
option as it would mean rewriting millions of lines of code to not use
ARC anymore. The world has moved on and ARC is a huge benefit to ObjC
developers. The memory management of ObjC is the main reason I moved
from plain C to ObjC in the first place and ARC is putting this to a
next level.

So its safe to assume that the majority of developers for applications
running under GNUstep will want to use ARC.
As ARC simply never will exist in GCC, this means clang support is
mandatory.
In consequence, compiling GNUstep itself should work well with clang
because a typical GNUStep application developer is the first candidate
to contribute to GNUstep itself.
Having to move back to GCC and non-arc stuff would basically mean going
3 steps back and will distract developers/contributors.

In other words, time spent on making clang & linkers run more smooth
with GNUstep is definitively much better time spent than trying to fix GCC.

For my own development I use GNUstep as Daniel. Some highly custom
applications. I run them mainly on Debian Linux and I run into many
issues in the beginning. Notably having to use a -specific- linker and a
-specific- compiler version. For me what works well is clang11 and the
gold linker. clang14 however does not work anymore for some reason. Most
of the tests fail with it. Using the stock linker doesn't work neither,
nor did the LLVM linker ldd which I found rather surprising. So we are
in delicate areas here.

As far as portability goes, all the platforms I am targeting are
supported by clang. Some embedded platforms might not be supported by
clang which are by gcc. But frankly these platforms are rather tiny (not
in market size but in memory , cpu power etc) so running GNUstep on
these would be most likely useless anyway.  After all GNUstep is for the
destktop.

The most important platforms I consider these days  are
    x86_64
    arm64
    arm
    risc-V
    i386

There might be other useful platforms around to easily support (like
powerPC, MIPS, Tile) but at the end of the day you have to ask yourself
how much benefit is it to run GNUstep on these and how much effort does
it take.

Re: Clang/LLVM migration roadmap

[Andreas Fink]

What are the real issues of the runtime on other platforms?
I might have a personal interest to do some work on some platforms.

Gregory Casamento wrote on 10.02.22 03:31:
> Riccardo,
>
> I don't believe that GNUstep should hold back features to remain
> compatible with any given compiler.  Not implementing features that
> are widely used (not even particularly "modern" ones) because the less
> capable compiler (in this case the latest GCC) lacks support is not
> a healthy direction.
>
> Like you, I believe in choice.  I think that GNUstep should remain
> compatible with GCC so long as GCC is able to keep up with the
> features needed by the project.
>
> It's really simple math.  We are a team of limited man-power and,
> currently, there is no one on the time who has the time to do what
> needs to be done to implement the following in GCC:
>
> 1) Support for ARC properties (weak, strong, etc)
> 2) Syntactic sugar as I have specified in recent discussions
> 3) Internal compiler support for ARC (i.e. use the features in #1 to
> drive memory management)
> 4) Runtime changes to support the above
>
> In LLVM/clang the above features already exist.  What is missing is:
>
> 1) The ability of the runtime to work on a number of different
> platforms: (Windows, etc)
> (if you can think of anything else that's missing, I'm sure you can
> think of something)
>
> Who is going to write this code, you? (you already say your day job is
> taking over)  Mine is as well very taxing.   So the question remains,
> which one of the very few of us is going to take on these tasks.   The
> path to get clang working is likely much shorter than GCC.
>
> On Wed, Feb 9, 2022 at 6:56 PM Riccardo Mottola
> mailto:riccardo.mott...@libero.it>> wrote:
>
> Hi,
>
> sorry for being a little bit absent, day-job is overtaking, I skipped
> the meeting and had no energy to reply. Also, the words chosen
> irritated me and spoke to you guys separately.
> Let me start with a reply on the facts given which here are then
> mixed
> with judgments which are personal of you and some others. So I just
> chime in writing the other side of the medal.
> Also, as stated further in your newer thread "Clang migration" is
> misleading, because the real goal is better ObjC-2 support, which can
> be achieved in different ways.
>
>
> I ask again, who is going to have the time to do this?
>  
>
> > 1) GCC lacks support for many memory management features that are
> > commonly
> > used today
> > 2) GCC's objective-c support is lagging behind and doesn't include
> > support
> > for @[], @{}, @autorelease, etc etc etc
> > 3) Lack of bug fixes in GCC's implementation of ObjC
> > 4) GCC team does not consider ObjC release critical and will and HAS
> > released with broken support for building ObjC targets.
> > All of these things are UNACCEPTABLE
>
> The GCC team has improved a lot support and you cite very old things
> that happened years ago. 
>
>
> Okay, that's fine.  I don't see it in the list above though.  The fact
> remains that no one on the GCC team is willing or able to take the
> time to implement a single feature listed in either this list or the
> one above.
>  
>
> Amazingly, the  last several major releases
> of GCC up to gcc 11 have no issues. So while "legacy" the GCC
> setup is
> amazingly stable on all architectures I can test on (and I have many
> machines!). AlLso those bugs you cite do not show up
> Furthermore those "modern features" do not significantly limit
> development and do not (almost?) impede using then in any
> applications, so the issue is mostly limited to "core".
>
>
> Given that most of these modern features came out in 2006, I think
> it's time we stopped calling them "modern".  Also, when you have a
> codebase that has been written within the last 16 years that uses
> these features, it is a major impediment to have to re-engineer your
> code to use an ancient version of Objective-C.  The effort I am
> working on NOW in my day job is having to go through this very thing,
> and it's ridiculous in the extreme that this should have to be done.
>
> I would scale them in as inconveniences, maybe serious, but not
> unacceptable.
>
>
> They are more than inconveniences.
>  
>
> GCC has its runtime, so its build system tests both together!
>
>
> So what?  To most developers who want useful software and just want
> their stuff to work this is meaningless.
>
> > 1) Currently, libobjc2 does not support some architectures and also
> > does
> > not build easily on Windows under MSYS2.  While some older
> > architectures
> > are, perhaps, not as important, building on Windows under MSYS2 is
> > critical.
>
> The build setup of GCC is very consistent; the support is very vast
> and the runtime is essentially in C, supporting also architectures
> not
> explicitely tested or 

Re: Clang/LLVM migration roadmap

[Andreas Fink]

So to summarize up, we need to get libobjc2 properly working under MSYS2
and we can continue with clang.
What are the isuses with libobjc2 not working under MSYS2? From what I
know libobj2 should not have many dependencies on the operating system
itself (well memory management and multithreading but not much more I
believe) but more on the architecture. But thats a birds eye view...

Gregory Casamento wrote on 06.02.22 01:14:
> All,
>
> As promised in my reply to Wolfgang, I am starting the thread
> regarding this migration.
>
> There are a number of factors that are driving this:
> --
> 1) GCC lacks support for many memory management features that are
> commonly used today
> 2) GCC's objective-c support is lagging behind and doesn't include
> support for @[], @{}, @autorelease, etc etc etc
> 3) Lack of bug fixes in GCC's implementation of ObjC
> 4) GCC team does not consider ObjC release critical and will and HAS
> released with broken support for building ObjC targets.  
> All of these things are UNACCEPTABLE
>
> There are a number of reasons why we still use GCC:
> --
> 1) Currently, libobjc2 does not support some architectures and also
> does not build easily on Windows under MSYS2.  While some older
> architectures are, perhaps, not as important, building on Windows
> under MSYS2 is critical.
> 2) GNUstep is an FSF project, so there is a political component if we
> don't support GCC anymore.   This is not a show-stopper but is
> something to consider.
>
> Advantages of LLVM/Clang
> --
> 1) ARC
> 2) support for modern features in objc that are commonly used
> 3) more developers will be able to port their applications to GNUstep
>
> Disadvantages
> --
> 1) libobjc2 is currently, as stated above, unstable or unsupported on
> some architectures / operating systems.
>
> Approach
> --
> 1) make sure that libobjc2 is supported on as wide a range of
> platforms as possible.  
> 2) Fix issues with building on Windows/msys2
>
> We should make the transition as easy as possible for people who are
> currently using GCC to switch over to Clang/LLVM.
>
> Please feel free to discuss...
>
> Yours, GC
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: failed tests in gnustep-gui

[Andreas Fink]

I usually compile my code in a ssh session. So yes no X.
I started now in X (Remotix helps here as I'm far away) and tests now
run fine.
Now I will look why I never had GUI working on Debian 11.

Sergei Golovin wrote on 18.01.22 11:46:
> On 2022-01-18 14:32:32 +0400 Andreas Fink  wrote:
>
>> 2022-01-18 11:29:42.888 basic[12804:12804] Exception occurred while
>> loading model: Unable to retrieve list of screens from window server.
>>
>> Could it be that the tests fail because I call them from ssh without any
>> X11 active?
>
> Definitely you have no X server around so tests fail
>
> DISPLAY= make check
> ---
>     967 Passed tests
>   8 Failed sets
>   3 Failed tests
> ---
>

Re: failed tests in gnustep-gui

[Andreas Fink]

Running gui/NSNibLoading/basic.m...
Start set:   basic.m:26 ... NSNibLoading GNUstep basic
Passed test: (2022-01-18 11:29:42.884 +0100)   basic.m:44 ...
NSBundle was initialized
2022-01-18 11:29:42.888 basic[12804:12804] Exception occurred while
loading model: Unable to retrieve list of screens from window server.
2022-01-18 11:29:42.888 basic[12804:12804] Failed to load Gorm
Failed test: (2022-01-18 11:29:42.888 +0100)   basic.m:52 ... .gorm
file was loaded properly using loadNibNamed:owner:topLevelObjects:
2022-01-18 11:29:42.898 basic[12804:12804] Exception occurred while
loading model: Unable to retrieve list of screens from window server.
2022-01-18 11:29:42.898 basic[12804:12804] Failed to load Xib
Failed test: (2022-01-18 11:29:42.898 +0100)   basic.m:58 ... .xib
file was loaded properly using loadNibNamed:owner:topLevelObjects:
2022-01-18 11:29:42.939 basic[12804:12804] Exception occurred while
loading model: Unable to retrieve list of screens from window server.
2022-01-18 11:29:42.939 basic[12804:12804] Failed to load Nib
Failed test: (2022-01-18 11:29:42.950 +0100)   basic.m:64 ... .nib
file was loaded properly using loadNibNamed:owner:topLevelObjects:
End set: basic.m:72 ... NSNibLoading GNUstep basic
Completed file:  basic.m


Could it be that the tests fail because I call them from ssh without any
X11 active?

Richard Frith-Macdonald wrote on 18.01.22 09:33:
>
>> On 17 Jan 2022, at 21:15, Andreas Fink  wrote:
>>
>> I get these failures while running gnustep-gui tests:
>>
>> --
>> gui/NSView/NSView_convertRect.m:
>> Failed set:NSView_convertRect.m:100 ... problem in NView GNUstep
>> converRect.
>>
>> gui/NSView/NSView_frame_bounds.m:
>> Failed set:NSView_frame_bounds.m:57 ... problem in NView GNUstep
>> frame_bounds.
>>
>> gui/NSView/NSView_frame_rotation.m:
>> Failed set:NSView_frame_rotation.m:21 ... problem in NView
>> GNUstep frame_rotation.
>>
>> gui/NSView/scrollRectToVisible.m:
>> Failed set:scrollRectToVisible.m:33 ... problem in NView GNUstep
>> scrollRectToVisible.
>> --- Running tests in gui/TextSystem ---
>>
>> 967 Passed tests
>>   8 Failed sets
>>   3 Failed tests
>> 
>>
>>
>> They all fail in a line like this:
>>
>> START_SET("NView GNUstep bounds_scale")
>>
>> So in a macro somwhere.
>> Any idea what this macro does?
> You can just look in the header file (Testing.h) to see exactly what it does, 
> but the summary is that it starts a region of code with an autorelease pool 
> and exception handler and some bookkeeping to track things like the duration 
> of tests.
> Failed set generally means that an exception occurred somewhere in the region 
> betwen the start and the end.  The full log may tell you where/what the 
> exceptionb was.

failed tests in gnustep-gui

[Andreas Fink]

I get these failures while running gnustep-gui tests:

--
gui/NSView/NSView_convertRect.m:
Failed set:    NSView_convertRect.m:100 ... problem in NView GNUstep
converRect.

gui/NSView/NSView_frame_bounds.m:
Failed set:    NSView_frame_bounds.m:57 ... problem in NView GNUstep
frame_bounds.

gui/NSView/NSView_frame_rotation.m:
Failed set:    NSView_frame_rotation.m:21 ... problem in NView
GNUstep frame_rotation.

gui/NSView/scrollRectToVisible.m:
Failed set:    scrollRectToVisible.m:33 ... problem in NView GNUstep
scrollRectToVisible.
--- Running tests in gui/TextSystem ---

    967 Passed tests
  8 Failed sets
  3 Failed tests



They all fail in a line like this:

    START_SET("NView GNUstep bounds_scale")

So in a macro somwhere.
Any idea what this macro does?



signature.asc
Description: OpenPGP digital signature

libobjc2 fails with clang14 but not with clang11

[Andreas Fink]

under debian10 I get different behaviour with libobjc2 when I run make test
depending on the used compiler version:

Anyone an idea what is different in clang14 compared to clang11 which
could cause half of the tests to fail?


CLANG-14:

Running tests...
Test project /Users/afink/development/gnustep/libobjc2/BUILD
    Start   1: alias
  1/198 Test   #1: alias
.***Exception: SegFault 
0.00 sec
    Start   2: alias_optimised
  2/198 Test   #2: alias_optimised
...***Exception: SegFault  0.00 sec
    Start   3: alias_legacy
  3/198 Test   #3: alias_legacy ..  
Passed    0.00 sec
    Start   4: alias_legacy_optimised
  4/198 Test   #4: alias_legacy_optimised   
Passed    0.00 sec
    Start   5: alignTest
  5/198 Test   #5: alignTest
.***Exception: SegFault  0.00 sec
    Start   6: alignTest_optimised
  6/198 Test   #6: alignTest_optimised
...***Exception: SegFault  0.00 sec
    Start   7: alignTest_legacy
  7/198 Test   #7: alignTest_legacy ..  
Passed    0.00 sec
    Start   8: alignTest_legacy_optimised
  8/198 Test   #8: alignTest_legacy_optimised   
Passed    0.00 sec
    Start   9: AllocatePair
  9/198 Test   #9: AllocatePair
..***Exception: SegFault  0.00 sec
    Start  10: AllocatePair_optimised
 10/198 Test  #10: AllocatePair_optimised
***Exception: SegFault  0.00 sec
    Start  11: AllocatePair_legacy
 11/198 Test  #11: AllocatePair_legacy ...  
Passed    0.00 sec
    Start  12: AllocatePair_legacy_optimised
 12/198 Test  #12: AllocatePair_legacy_optimised .  
Passed    0.00 sec
    Start  13: ARCTest_arc
 13/198 Test  #13: ARCTest_arc
...***Exception: SegFault  0.00 sec
    Start  14: ARCTest_arc_optimised
 14/198 Test  #14: ARCTest_arc_optimised
.***Exception: SegFault  0.00 sec
    Start  15: ARCTest_arc_legacy
 15/198 Test  #15: ARCTest_arc_legacy   
Passed    0.00 sec
    Start  16: ARCTest_arc_legacy_optimised
 16/198 Test  #16: ARCTest_arc_legacy_optimised ..  
Passed    0.00 sec
    Start  17: AssociatedObject
 17/198 Test  #17: AssociatedObject
..***Exception: SegFault  0.00 sec
    Start  18: AssociatedObject_optimised
 18/198 Test  #18: AssociatedObject_optimised
***Exception: SegFault  0.00 sec
    Start  19: AssociatedObject_legacy
 19/198 Test  #19: AssociatedObject_legacy ...  
Passed    0.00 sec
    Start  20: AssociatedObject_legacy_optimised
 20/198 Test  #20: AssociatedObject_legacy_optimised .  
Passed    0.00 sec
    Start  21: AssociatedObject2
 21/198 Test  #21: AssociatedObject2
.***Exception: SegFault  0.00 sec
    Start  22: AssociatedObject2_optimised
 22/198 Test  #22: AssociatedObject2_optimised
...***Exception: SegFault  0.00 sec
    Start  23: AssociatedObject2_legacy
 23/198 Test  #23: AssociatedObject2_legacy ..  
Passed    0.00 sec
    Start  24: AssociatedObject2_legacy_optimised
 24/198 Test  #24: AssociatedObject2_legacy_optimised   
Passed    0.00 sec
    Start  25: BlockImpTest
 25/198 Test  #25: BlockImpTest
..***Exception: SegFault  0.00 sec
    Start  26: BlockImpTest_optimised
 26/198 Test  #26: BlockImpTest_optimised
***Exception: SegFault  0.00 sec
    Start  27: BlockImpTest_legacy
 27/198 Test  #27: BlockImpTest_legacy ...  
Passed    0.00 sec
    Start  28: BlockImpTest_legacy_optimised
 28/198 Test  #28: BlockImpTest_legacy_optimised .  
Passed    0.00 sec
    Start  29: BlockTest_arc
 29/198 Test  #29: BlockTest_arc .  
Passed    0.00 sec
    Start  30: BlockTest_arc_optimised
 30/198 Test  #30: BlockTest_arc_optimised ...  
Passed    0.00 sec
    Start  31: BlockTest_arc_legacy
 31/198 Test  #31: BlockTest_arc_legacy ..  
Passed    0.00 sec
    Start  32: BlockTest_arc_legacy_optimised
 32/198 Test  #32: BlockTest_arc_legacy_optimised   
Passed    0.00 sec
    Start  33: ConstantString
 33/198 Test  #33: ConstantString
***Exception: SegFault  0.00 sec
    Start  34: ConstantString_optimised
 34/198 Test  #34: ConstantString_optimised
..***Exception: SegFault  0.00 sec
    

Re: linking with mold

[Andreas Fink]

H. Nikolaus Schaller wrote on 23.12.21 09:33:
>
>> Am 22.12.2021 um 12:57 schrieb Andreas Fink :
>>
>> I'm happy in terms of functionality with gold linker but linking my
>> projects is quite slow. My projects has around five thousands source
>> files. All very small but still lots of them. So linking is taking most
>> of the time when I modify and run something.
> Hm.
>
> Couldn't you group those 5000 files into a hierarchy of libraries/frameworks?
They are already.  But I have two big libraries. ulibgsmmap (1046 .m
files) and ulibdiameter (654 .m files).
They can't be split further because underlying protocol standards they
implement.

> And re-link only a small modified portion of the full dependency tree?
to build the final binary it still has to link everything together.
Either at build time or at start time by the dynamic linker.
> Current Linux kernel has ca. 32911 .c files but links (not compiles) within
> seconds by such a hierarchy if I change a single source file.

Linux kernel is pure C and is mostly modules which are not recompiled if
you change a single source file

I'm not complaining about my current setup. I just think it could be
improved.

So far a full rebuilt on a Debian 10 vm on a 28 core MacPro takes 6
minutes. (on a M1 mac it takes 5minutes 40 sec). Most of the time I
don't need a full rebuilt but I can see the linking part taking a lot of
time. Having the option to use a linker which runs on many cores could
drastically improve that.
using "mold" would thus nice. But I wanted to be sure i don't run into
any issues like with ld or lld. Hence my question if anyone tried.

If not, I will investigate and test myself.

linking with mold

[Andreas Fink]

Hello,

in my development I learned the hard way that the only linker which
works with gnustep/libobjc2 seems to be the gold linker.
standard ld as well as lvm's lld had issues with libobjc2 either by not
doing stuff as it should or by optimizing things away it shouldnt.
At least on Debian9 where I failed miserably when I tested (things might
have changed since).

I'm happy in terms of functionality with gold linker but linking my
projects is quite slow. My projects has around five thousands source
files. All very small but still lots of them. So linking is taking most
of the time when I modify and run something.

Today I learned about the mold linker which is heavily paralelized
speeding up linking in some tests by a factor of 20x. That's quite an
achievement.
This is wonderful for turnaround times while developing. Now as libobjc2
has a few specialities I wonder if anyone has ever tested mold with it
and what the findings where.

Mold's Project page is https://github.com/rui314/mold


Andreas

Re: GNUstep on Hackernews

[Andreas Fink]

I can set up another repository server for it easily.
I have my own hosting service so hardware is not an issue.

The question is also how often new packages should be built and how the
releases should be streamlined.
This is more an organisational question than a technical one.

Best would be if this could be automated in nightly builds or so. But
this means writing a lot of scripts to catch any errors etc.
Anyone has experience with this?


H. Nikolaus Schaller wrote on 17.12.21 11:35:
>
>> Am 17.12.2021 um 11:19 schrieb Andreas Fink :
>>
>>
>>
>> H. Nikolaus Schaller wrote on 17.12.21 10:57:
>>>> Am 17.12.2021 um 10:33 schrieb Andreas Fink :
>>>>
>>>> packages in Debian are quite old and don't support objc2.0. So they are
>>>> not suitable for new development.
>>>> I always build my own packages due to that.
>>> That is why I propose the idea to provide a separate, maintained repository 
>>> outside of debian.org
>>> but compatible to it...
>>>
>>> People just
>>> 1. add some /etc/apt/sources.list.d/gnustep.conf to e.g. deb.gnustep.org 
>>> (see https://wiki.debian.org/DebianRepository)
>>> 2. download and install some GPG key
>>> 3. then apt-get update
>>> 4. and apt-get install gnustep
>>> 5. later apt-get upgrade
>>>
>>> Same can be done for Ubuntu.
>>>
>>> So if you already build your own packages, why not publish them in such a 
>>> repo? Incl. objc2.0?
>> it is public already. I use it heavily in my ulib library and all
>> libraries based on top of it (such as universalss7).
>>
>> Add the repo key:
>>
>> wget -4 -O - http://repo.universalss7.ch/debian/key.asc |apt-key add -
>> or
>> apt-key adv --recv-keys --keyserver keyserver.ubuntu.com
>> EE85CFC98EC405E3115EE86BD173212BFB27007D # UniversalSS7
>>
>> add the repository to your /etc/apt/sources.list
>>
>> Debian10
>> deb http://repo.universalss7.ch/debian/ buster universalss7
>>
>> Debian 11
>> deb http://repo.universalss7.ch/debian/ bullseye universalss7
>>  
>> I can built for Intel and arm64
>> I also built one for Ubuntu a while back.
>> Not much difference.
>>
>> The versions in my repo are built for my own use and thus are installed
>> in /usr/local/ to not interfer with anything installed from other sources.
> Good!
>
>> I can build a release version for debian 10 or 11 if I know how the
>> original packages where built.
>> (what config otions etc)
> That is nice!!!
>
> So we would just need some deb.gnustep.org forwarding so that the
> real repo location can be switched easily...
>
>>>> Btw who is the Debian maintainer for the gnustep builds?
>>> In my proposal it could be a member of the GNUstep community so we don't 
>>> have to wait
>>> for someone from Debian core...
>> I agree but "someone from Debian core" must be someone who built it
>> originally. The config of these builds is what interests me.
> Ok, that can be found out through e.g. (same scheme for all other packages):
>
> https://packages.debian.org/bullseye/gnustep-make
>
> There is a Maintainer list on the rightmost column.
> It mentions an e-mail address: pkg-gnustep-maintain...@lists.alioth.debian.org
>
> And you can also download the files gnustep-make_2.8.0-1.dsc etc. which 
> includes the config used for compilation.
>
> Or alternatively apt-get the source package and look inside how Debian would 
> build from source.
>
> BR,
> Nikolaus
>
>

Re: GNUstep on Hackernews

[Andreas Fink]

H. Nikolaus Schaller wrote on 17.12.21 10:57:
>
>> Am 17.12.2021 um 10:33 schrieb Andreas Fink :
>>
>> packages in Debian are quite old and don't support objc2.0. So they are
>> not suitable for new development.
>> I always build my own packages due to that.
> That is why I propose the idea to provide a separate, maintained repository 
> outside of debian.org
> but compatible to it...
>
> People just
> 1. add some /etc/apt/sources.list.d/gnustep.conf to e.g. deb.gnustep.org (see 
> https://wiki.debian.org/DebianRepository)
> 2. download and install some GPG key
> 3. then apt-get update
> 4. and apt-get install gnustep
> 5. later apt-get upgrade
>
> Same can be done for Ubuntu.
>
> So if you already build your own packages, why not publish them in such a 
> repo? Incl. objc2.0?

it is public already. I use it heavily in my ulib library and all
libraries based on top of it (such as universalss7).

Add the repo key:

    wget -4 -O - http://repo.universalss7.ch/debian/key.asc |apt-key add -
or
    apt-key adv --recv-keys --keyserver keyserver.ubuntu.com
EE85CFC98EC405E3115EE86BD173212BFB27007D # UniversalSS7

add the repository to your /etc/apt/sources.list

Debian10
    deb http://repo.universalss7.ch/debian/ buster universalss7

Debian 11
    deb http://repo.universalss7.ch/debian/ bullseye universalss7
 
I can built for Intel and arm64
I also built one for Ubuntu a while back.
Not much difference.

The versions in my repo are built for my own use and thus are installed
in /usr/local/ to not interfer with anything installed from other sources.
I can build a release version for debian 10 or 11 if I know how the
original packages where built.
(what config otions etc)

>
>> Btw who is the Debian maintainer for the gnustep builds?
> In my proposal it could be a member of the GNUstep community so we don't have 
> to wait
> for someone from Debian core...

I agree but "someone from Debian core" must be someone who built it
originally. The config of these builds is what interests me.

>
> BR,
> Nikolaus
>
>

Re: GNUstep on Hackernews

[Andreas Fink]

packages in Debian are quite old and don't support objc2.0. So they are
not suitable for new development.
I always build my own packages due to that.
Btw who is the Debian maintainer for the gnustep builds?

Svetlana Tkachenko wrote on 16.12.21 22:45:
> Hi Riccardo 
>
>>> 'gnustep live cd' is already a good reference distribution, is it not? 
>>> http://wiki.gnustep.org/index.php/GNUstep_Live_CD i am asking because in 
>>> some of the discussions above, it seems that there are some references to 
>>> that a reference distribution does not exist
>> To my knowledge it is outdated, last referenced version I see is 2017.
> How does it compare to the present situation with debian? Do debian users of 
> gnustep also get 2017 versions of packages?
>
> Svetlana
>

Re: strange exception occuring in gnustep-base

[Andreas Fink]

Can't do that easily unfortunately. its a background process started by
systemd and it might take days to occur.
My suspicion is that some other type of object is passed somewhere
instead of some NSString to some method which then in turn calls
getCharacters:range:

David Wetzel wrote on 16.12.21 18:15:
> Did you try to set a breakpoint and do a backtrace?
>
> Von meinem iPhone gesendet
>
>> Am 2021-12-16 um 12:10 schrieb Gregory Casamento
>> :
>>
>> 
>>
>> Would it be possible to get the code to the app or a minimal test
>> case?  More context would be helpful.  The exception you are
>> mentioning could be due to a memory issue someplace.
>>
>>
>> On Thu, Dec 16, 2021 at 9:42 AM Andreas Fink > <mailto:af...@list.fink.org>> wrote:
>>
>> Hello,
>>
>> My application fires an exception which is puzzling me:
>>
>> Uncaught exception NSInvalidArgumentException, reason:
>> GSCInlineString(instance) does not recognize getCharacters:range:
>>
>>
>> to me this means a NSString is being called with the method
>> getCharacters:range: which it doesnt have?
>> Does that error message make any sense to anyone?
>>
>>
>> Andreas
>>
>>
>>
>>
>>
>> -- 
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org - http://heronsperch.blogspot.com
>> https://www.patreon.com/bePatron?u=352392 - Become a Patron
>> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
>> https://teespring.com/stores/gnustep - Store

strange exception occuring in gnustep-base

[Andreas Fink]

Hello,

My application fires an exception which is puzzling me:

Uncaught exception NSInvalidArgumentException, reason:
GSCInlineString(instance) does not recognize getCharacters:range:


to me this means a NSString is being called with the method
getCharacters:range: which it doesnt have?
Does that error message make any sense to anyone?


Andreas

[GSAutoreleasedMemory length]

[Andreas Fink]

Does anyone have an idea in which scenario this exception is thrown:

Uncaught exception NSInvalidArgumentException, reason: Can not determine
type information for -[GSAutoreleasedMemory length]


Andreas

Re: Category Unknown ?

[Andreas Fink]

the list is not dead
To start:
 
a) which version of clang are you using?
b) which objc runtime are you using?
c) which linker are you using?
d) which Linux distribution/version are you using?

Andreas Buff wrote on 15.10.21 14:53:
> Hi,
>
> sorry for the bump.
>
> Is this list dead or is my question too stupid?
>
> :-/
>
> Am 07.10.21 um 10:30 schrieb Andreas Buff:
>> Hi!
>>
>> I am new to GNUstep.
>>
>> I am building an executable on Linux. Using include
>> `$(GNUSTEP_MAKEFILES)/tool.make`.
>>
>> It's linked to a static lib that has also be build with GNUstep. The lib
>> contains Categories.
>>
>> The executable builds fine but has errors at runtime not recognizing
>> methods defined in the static lib's Category:
>>
>> "Uncaught exception NSInvalidArgumentException, reason:
>> ClassNameOfClassTheCategoryExtends(instance) does not recognize
>> nameOfMethodInCategory"
>>
>> I am trying to fix that by passing `-ObjC` to the linker flags (also
>> tried `-all_load`) in the executable's GNUmakefile:
>>
>> `ADDITIONAL_LDFLAGS =  -ObjC -all_load`
>>
>> But that seems to be ignored by clang. Here is the relevant output of
>> `make install messages=yes debug=yes`
>>
>> ```
>> clang: warning: argument unused during compilation: '-ObjC'
>> [-Wunused-command-line-argument]
>> clang: warning: argument unused during compilation: '-all_load'
>> [-Wunused-command-line-argument]
>> ```
>>
>> Any help or hint is appreciated.
>>
>> 
>> Andreas
>>
>

Re: Debian 11/Clang 11 issues compiling...

[Andreas Fink]

actually my issue from earlier today waas something else (some improper
locking)

I did have issues on debian 11 with the latest clang  version. Going
with the one which comes with the box was ok but the one from llvm.org
repo gave me issues.
I remember I had to compile things twice. The first attempt failed
miserably. make check or make test will go nuts...
So its maybe a issue between libobjc2 and libdispatch and  gnustep-base.
that they circulalry depend on each other and fail when libobjc 1.0 is
first referred.
Or I simply didnt had my environment variables set properly on my first
attempt. I cant figure it out but I have seen similar issues with
Debian10 when built for the first time on  a empty machine.

Debian rule #1   is to ALWAY use the gold linker.
I usually do this by a symlink:

    cd /usr/bin
    mv ld ld.old
    ln -s  ld.gold ld
 
(ld originally points to x86_64-linux-gnu-ld instead of
x86_64-linux-gnu-ld.gold  )

Debian rule #2 is to always use clang (version 8 or newer)

If you dont use the gold version and/or clang version 7 or older. you
will see failures due to misaligned datastructures (it optimized things
away it shoudlnt)). Thats a quite late failure which will bite you very
hard and makes your head twist. Because it looks like it "kinda" works
but then does all kinds of strange arbitrary things. Properties return
data from other places than they shuld and you get rubbish data etc.


my debian11 binaries where built with Debian clang version 11.0.1-2
my debian 10 binaries where built with Debian clang version
10.0.1-++20210313014605+ef32c611aa21-1~exp1~20210313125208.190

these are the packages I have built for Debian11 (x86-64)
    gnustep-base-1.28.0_amd64.deb
    gnustep-corebase-0.2.1_amd64.deb
    gnustep-make-2.9.0_amd64.deb
    libdispatch-5.5.0_amd64.deb
    libiconv-1.16.0_amd64.deb
    libobjc2-2.1.0_amd64.deb

You can download them from:
   
http://repo.universalss7.com/debian/dists/bullseye/universalss7/binary-amd64/

the way I have built these is documented here:
   
https://github.com/andreasfink/ulib/blob/master/doc/README-Debian11-bullseye.txt


I didnt get to the gui & back part because I dont need them for my apps.
Generally if gnustep-base tests passes, then the rest is a piece of cake.
the GUI part originally gave me an issue in Debian 11. Can't remember
what it was.


Riccardo Mottola wrote on 14.09.21 00:19:
> Hi,
>
> Gregory Casamento wrote:
>>
>> I seem to be having an issue building GNUstep using clang-11 on
>> Debian 11.   I am attaching the debug files to this email...
>>
>> I am going to report this on the clang bugtracker as soon as they
>> give me access.
>
>
> base/gui/back compile with clang-12. Perhaps there is a bug fixed in
> later versions? Maybe they can backport it to 11.x
>
> Riccardo
>

Re: libobj2 changes

[Andreas Fink]

Yes I recompiled everything from scratch on a new empty VM.
I don't think its a bug in libobjc2 but more a changed behaviour which
has a side effect in my application.

I have been through the hell of incorrectly compiled libraries a couple
of times before (not compiling with right clang or gold linker etc) and
I know these pitfalls.
The make check's however all succeed (except the ones which always fail
in some date formatting area which are really edge cases which are not
really relevant).  So I doubt its a compilation issue. And in this case
its the same compiler I use all the time and the same operating system
version (Debian 10).

I don't get any crashes. Everything looks good from the outside. Just my
application (which does a lot of network communications via SCTP
sockets) starts to fail  by loosing communication links. And this stuff
is nothing really special. Its heavily multithreaded (with the matching
locks etc) and throws exception when it tries to send data and the
socket returns an error (link down, buffer full etc etc) which then are
catched further up. If a new kind of exception is thrown in such a case,
it could terminate the thread. Thats why I'm on the lookout for what has
changed exactly which could result in such a scenario. I'm pretty sure
it's super easy to fix but currently hard to find. Thats why I'm looking
for clues & hints on where to look more closely.


David Wetzel wrote on 31.05.21 17:04:
> Hi Andreas,
>
> Did you recompile everything? Are your binaries using the correct libraries?
>
> Dave
>
> Von meinem iPhone gesendet
>
>> Am 2021-05-31 um 10:56 schrieb Andreas Fink :
>>
>> Hello all,
>>
>> I upgraded my gnustep and libobjc libraries to the latest version and I
>> suddenly get strange effects in my app that internal communication is
>> lost and reestablished all the time. I suspect some new exceptions being
>> thrown I don't catch properly and thus threads are ending or the like.
>> The release notes to libobjc2  hint some changes in this area.
>>
>> I wonder what the easiest way would be to debug such an issue. I often
>> trow NSException in my communication processing code (if packets are
>> wrong, can not be decoded, sockets are closed and the like) and catch it
>> further up. But there must be some new exceptions out there which are
>> thrown which wherent before which I don't catch correctly and I wonder
>> what I could have missed.
>>
>> Note: the application is not crashing or quitting...
>>
>> If you have any good idea on how to diagnose such a problem, let me know.
>>
>> My working release of libobjc2 is 1.9
>> The new one is from the repo (2.1 currently)
>>
>>
>>
>>

libobj2 changes

[Andreas Fink]

Hello all,

I upgraded my gnustep and libobjc libraries to the latest version and I
suddenly get strange effects in my app that internal communication is
lost and reestablished all the time. I suspect some new exceptions being
thrown I don't catch properly and thus threads are ending or the like.
The release notes to libobjc2  hint some changes in this area.

I wonder what the easiest way would be to debug such an issue. I often
trow NSException in my communication processing code (if packets are
wrong, can not be decoded, sockets are closed and the like) and catch it
further up. But there must be some new exceptions out there which are
thrown which wherent before which I don't catch correctly and I wonder
what I could have missed.

Note: the application is not crashing or quitting...

If you have any good idea on how to diagnose such a problem, let me know.

My working release of libobjc2 is 1.9
The new one is from the repo (2.1 currently)

Re: Frameworks questions re layout and bundling

[Andreas Fink]

As far as I know, the clang compiler takes care of all this if you pass
--framework  to include/link a specific framework and -F to tell it
where the frameworks are.
Thats all it should take to link a framework in this style.


Philip George wrote on 07.05.21 20:10:
> Just to have something concrete to look at, I've included 2 tree
> diagrams of frameworks using Apple's layout /(minus modules and code
> signatures)/...
>
> *Development /(with headers)/*
>
> └ Quasi.framework
> ├ Quasi -> Versions/Current/Quasi
> ├ Headers -> Versions/Current/Headers
> ├ Resources -> Versions/Current/Resources
> └ Versions
> ├ A
> │     ├ Quasi
> │     ├ Headers
> │     │     ├ Quasi.h
> │     │     ├ QZThat.h
> │     │     └ QZThis.h
> │     └ Resources
> │           └ Info.plist
> └ Current -> A
>
>
> *Deployment /(without headers)/*
>
> └ Quasi.framework
> ├ Quasi -> Versions/Current/Quasi
> ├ Resources -> Versions/Current/Resources
> └ Versions
> ├─ A
> │     ├ Quasi
> │     └ Resources
> │           ├ Info.plist
> │           ├ that.png
> │           └ this.aif
> └ Current -> A
>
> On the *development* side, because I can tell clang to look for the
> headers/library in whatever directories I want, I don't think sharing
> the same layout with the macOS side will be a problem. I'll just need
> someone to talk about how umbrella headers are supposed to work in
> GNUstep.
>
> On the *deployment* side, I don't think layout will be a problem as
> long as:
>
> - it can be bundled
> - the entire app folder structure can be moved anywhere on the
> filesystem and still be able to find its frameworks /(optional, since
> the use-case isn't too common for linux)/
> - i understand what in the Info.plist file will need to be changed
> from the macOS version
>
> So hopefully I can get some clarification on those four things in this
> thread.
>
>
> Noel
>
>
>
>
>
> On Thu, May 6, 2021 at 10:34 AM blackstripe  > wrote:
> >
> > A few questions about frameworks in GNUstep...
> >
> > 1: Layout
> >
> > I know framework layout is unusual in gnustep, but I haven't seen a
> clear example of what it actually should look like — only discussion
> of it being different (in the wiki or faq i believe, but it provided
> no example).
> >
> > Is there any way to force macOS-style layout?
> >
> >
> > 2: Bundling
> >
> > Is is possible to bundle a framework such that (a) the framework
> stays with the surrounding app, and (b) can be moved anywhere on the
> file system (with the surrounding app)? (presumably some link
> references will have to be made relative using something like patchelf)
> >
> >
> > 3: Umbrella headers
> >
> > This project is shared with the macOS/Xcode side, so I would of
> course like the existing umbrella header to work as-is on the GNUstep
> side. Is this possible and how do I set that up?
> >
> >
> > 4: Clang
> >
> > What arguments need to be passed into clang to facilitate all of this?
> >
> >
> > - Noel
> >
> >

Re: [ML] Hosting of gnustep.org

[Andreas Fink]

if the question is if anyone wants to host it, I can raise my hand. I run some 
hosting service for some customers.
However, I don't have the time to administer it. So a VM for the project and 
internet connectivity through AS6775. Content is a different story.


> On 19 Jan 2021, at 13:54, Umberto Cerrato  wrote:
> 
> 
> 
>> Il giorno 19 gen 2021, alle ore 13:45, Gregory Casamento 
>>  ha scritto:
>> 
>> 
>> David,
>> 
>> On Tue, Jan 19, 2021 at 7:12 AM David Chisnall > > wrote:
>> Gregory,
>> 
>> On 19/01/2021 12:01, Gregory Casamento wrote:
>> > Mhm AWS...
>> > Not a fan of Amazon :P
>> >
>> >
>> > Don't care
>> 
>> You floated the idea of a CoC over Christmas and this is the kind of
>> exchange that makes me think that the project might need one.
>> 
>> You're right, I shouldn't have been so terse.  My sincere apologies.  I will 
>> explain why I was a little annoyed...
>> 
>> I understand that you don't want to derail the thread with long
>> discussions of the merits of different vendors but this kind of
>> confrontational and dismissive reply is not what I'd expect from a
>> leader of an inclusive free software or open source project.
>> 
>> My philosophy is to use what works.
> 
> I like that too. That’s why I didn’t reply.
> 
> I have just said my thought about Amazon services.
> I do not completely like them. Yes, that is an emotional thing.
> Just think like that: if you would ask “who wants to transfer all the stuff 
> to amazon computers?” I would be undecided of rising my hand.
> 
> (Then you could ask “why?”. – but now I do not want to write the answer. (I 
> am on the phone))
> 
>> I get a little upset when I hear people say "I don't want to use this or 
>> that" especially when the reason is non-technical.  I find, often, that 
>> people have an unreasoning EMOTIONAL attachments to certain things and it 
>> simply makes no sense to me when the entire idea is to accomplish something 
>> technical.
>> 
>> Cutting things out without explaining WHY using a reasonable and logical 
>> argument is not something I am a huge fan of.  I have found in 12 years of 
>> being "lead" that, sometimes, it means making decisions that are good for 
>> the project, but that are, sometimes, unpopular.
>> 
>> David
>> 
>> Yours, GC
>> --
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org  - 
>> http://heronsperch.blogspot.com 
>> https://www.patreon.com/bePatron?u=352392 
>>  - Become a Patron
>> https://gf.me/u/x8m3sx  - My GNUstep GoFundMe
>> https://teespring.com/stores/gnustep  
>> - Store
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Debian Package Repository...

[Andreas Fink]

I'm all for it. I build my own packages since years due to this.
clang >8.0  and gold linker are a must to get anything modern to work under 
Debian and the debian repo versions are not supporting any of this.


> On 15 Dec 2020, at 03:23, Patryk Laurent  wrote:
> 
> Hi Greg,
> 
> I’d be interested to know if there are any updates on this. One of the most 
> popular distributions on Pine64’s PinePhone is Mobian which is Debian with 
> mobile UI added on top.
> 
> I have a build script working for Mobian[1] but up-to-date packages would be 
> great as they’d be easier to specify as dependencies.
> 
> Best,
> Patryk
> 
> [1] 
> https://github.com/plaurent/gnustep-build/tree/master/pinephone-mobian-debian-11-clang-9.0
>  
> 
> 
> 
>> On Jul 29, 2020, at 08:02, Daniel Boyd > > wrote:
>> 
>> 
>> I’m not sure if I can help at all, but I’m super excited to see this project 
>> get off the ground. It will make managing my Linux boxes so much easier. I 
>> don’t have any particular expertise here, but am happy to help with testing 
>> or similar.
>> 
>> From: Discuss-gnustep 
>> > > On Behalf 
>> Of Gregory Casamento
>> Sent: Wednesday, July 29, 2020 9:52 AM
>> To: Discuss-gnustep Discuss > >
>> Subject: Debian Package Repository...
>> 
>> Hey guys,
>> 
>> One of the things we have struggled with in the past is the fact that the 
>> Debian packages are, necessarily, way behind.   I would like to set up a 
>> repo that contains the needed packages (at first for deb, but then for rpm 
>> based repositories as well) for users to get their packages directly from us 
>> IF they choose to do so.  I am in no way saying we should not create 
>> packages for Debian, but this would allow us to have more control and also 
>> would allow us to create packages that use clang instead of GCC for Linux.
>> 
>> I am going to set this up on an AWS server.  I will let you guys know about 
>> my progress.  If anyone would like to help or has any advice, let me know.
>> 
>> Thanks, GC
>> --
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org  - 
>> http://heronsperch.blogspot.com 
>> https://www.patreon.com/bePatron?u=352392 
>>  - Become a Patron
>> https://gf.me/u/x8m3sx  - My GNUstep GoFundMe



signature.asc
Description: Message signed with OpenPGP

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

[Andreas Fink]

I had no problems compiling gnustep9 on debian9-64bit on a raspberriy-pi.
However as always on debian, you must use the gold linker not the default one. 
Otherwise hell breaks loose.

And I didnt even try 32bit version (but it should work too from my experience 
in the past). The biggest problem for me under 32bit was to get a decent 
compiler version ( >= clang8) installed as the debian repo version has an issue 
which bites you with gnustep/libobjc2 badly. compiling clang from source under 
a Raspi is really no fun, especially if you dont have 8GB of RAM as the latest 
versions. 4GB might work but 2GB lets it constantly swap and being killed by 
OOM killer.

--
Sent from Canary (https://canarymail.io)

> On Friday, Jun 19, 2020 at 7:47 PM, Johannes Brakensiek 
> mailto:johan...@brakensiek.info)> wrote:
> On 18 Jun 2020, at 10:46, David Chisnall wrote:
>
> > I did. Five years ago. Note that there was a bug until 15 months ago
> > where the unwind info was not correctly set, so throwing an exception
> > out of +initialize would potentially corrupt some floating point
> > state.
>
> This runtime stuff really is higher arts for me, so I won’t be of much
> help debugging. But I ran into an issue that seems to be connected to
> something called „unwind“. ;)
>
> Looking into the git history it seems to be connected to lastest
> commit/PR.
>
> https://github.com/gnustep/libobjc2/issues/164
>
> It’s different to what Patrick reported, though. Running cmake with
> clang-8 worked without issues.
>
> Johannes
>

Re: catching exceptions

[Andreas Fink]

thanks thats what I was looking for
break set -S raise catches any call to [NSException raise]

> On 12 Jun 2020, at 13:36, David Chisnall  wrote:
> 
> On 12/06/2020 12:07, Andreas Fink wrote:
>> Does anyone know how I can catch these exceptions in lldb:
>> Throwing 0x7f2fa8004588, in flight exception: 0x7f2fa8004588
>> Exception caught by C++: 0
>> the usual
>> break set -S raise
> 
> I'm not sure what that does.  I set breakpoints on __cxa_throw and 
> objc_exception_throw to get the debugger to tell me where exceptions are 
> thrown.
> 
> David
> 
> 

catching exceptions

[Andreas Fink]

Does anyone know how I can catch these exceptions in lldb:

Throwing 0x7f2fa8004588, in flight exception: 0x7f2fa8004588
Exception caught by C++: 0

the usual

break set -S raise

doesnt catch it so it must be some other exception. I just cant find out where 
it gets thrown because the app already ended.

strange new errors

[Andreas Fink]

Hello all,

I recompiled the latest version of gnustep yesterday with clang-10 and now I 
see the following error messages at startup.


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)
GSDateSingle does not support ARC correctly (implements retain)
GSDateFuture 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)


all my code is compiled with ARC which shouldnt stop clang calling code which 
is non ARC.
why do we see these errors and whats the workaround?
And is there any memory management problem here really or can it be safely 
ignored.

cross platform question

[Andreas Fink]

If you want to write new apps running on MacOS X & GNUstep, what would you use 
to create the nib/xib/storyboard stuff which Xcode manages normally for you?
Handcoded source files? or is there an easier way.

NSCalendar bug (mktime related)

[Andreas Fink]

Hello all,

I have run into a very weird thing in conversion from NSStrings to NSDate. The 
result is we are always off by 1h under LInux.
Under MacOS X I have the same problem but only with mktime() not with 
NSCalendar.
I am suspecting Gnustep implementation probably uses mktime() in the back and 
thus inherits this issue also for NSCalendar.

What I try to do is to convert aNSString with a timestamp which is always in 
UTC into a date.
So the timestamp I supply has timezone GMT+0 and no daylight savings time.
If the current system currently experiences daylight savings time, the result 
by mktime is off by 1h even if I specify timezone to be UTC in struct tm.

Here is a test programm for this:


#define _BSD_SOURCE
#include 
#include 
#include 
time_t test(void)
{
   struct tm tm;
memset(,0, sizeof(tm));

int year = 1970;
int month = 1;
int day = 1;
int hour = 0;
int minute = 0;
int second = 0;
   
tm.tm_year = year -1900;
tm.tm_mon = month -1,
tm.tm_mday = day;
tm.tm_hour = hour;
tm.tm_min = minute;
tm.tm_sec = second;
tm.tm_zone = "UTC";
tm.tm_isdst = -1;
tm.tm_gmtoff = 0;

time_t t = mktime();
return t;
}


int main(int argc, const char * argv[])
{
time_t t;

setenv("TZ","UTC",1);
t = test();
printf("TZ=UTC:  t=%d\n",t);

setenv("TZ","CET",1);
t = test();
printf("TZ=CET:  t=%d\n",t);

setenv("TZ","CEST",1);
t = test();
printf("TZ=CEST:  t=%d\n",t);

setenv("TZ","Europe/Zurich",1);
t = test();
printf("TZ=Europe/Zurich:  t=%d\n",t);

}


So the timestamp I supply has timezone GMT+0 and no daylight savings time.
So the time_t value returned should always be 0 but its off by -1h if the 
envirnment has the timezone set to Europe/Zurich or CET. Interestingly CEST is 
correct (which is the current timezone in Zurich CET + Daylight savings time)

TZ=UTC:  t=0
TZ=CET:  t=-3600
TZ=CEST:  t=0
TZ=Europe/Zurich:  t=-3600

The output of this is indicating that the daylight savings yes/no  from the 
supplied timezone is ignore as well as the timezone. It always bases the date 
on the current environmental variable even though the current timezone might 
not be the one in effect at that date.
So it assumes that on 1.11970 we had daylight savings time (because TZ says we 
have now) despite being in January and despite it wasn't in use in that year 
even.

Now lets say this is a bug of mktime or maybe a wanted feature. Be is at it is.

The problem is NSCalendar fails for the same issue.


This piece of code works under MacOS X but fails under Linux.
Under NSCalendar I specify the timezone explicitly and TZ environment variable 
should not be relevant. But if NSCalendar implementation uses mktime, it 
inherits above strange behaviour.

NSDate *dateFromStringNSCalendar(NSString *str, const char *ctimezone_str) /* 
expects -MM-DD hh.mm.ss.SS TZ  timestamps */
{
int year;
int month;
int day;
int hour;
int minute;
int seconds;
double subsecond = 0;
const char *cdate_str;
const char *ctime_str;

NSArray *components = [str componentsSeparatedByString:@" "];
if(components.count >0)
{
NSString *s = components[0];
cdate_str = s.UTF8String;
}
if(components.count > 1)
{
NSString *s = components[1];
ctime_str = s.UTF8String;
}
if(components.count > 2)
{
NSMutableArray *arr =  [components mutableCopy];
[arr removeObjectsInRange:NSMakeRange(0,2)];
NSString *s = [arr componentsJoinedByString:@" "];
ctimezone_str = s.UTF8String;
}

/* parsing date */
sscanf(cdate_str,"%04d-%02d-%02d",
   ,
   ,
   );
if(strlen(ctime_str) ==8 ) /* HH:mm:ss.SS */
{
sscanf(ctime_str,"%02d:%02d:%02d",
   ,
   ,
   );
}
else if(strlen(ctime_str) >=9  ) /* HH:mm:ss.SS */
{
sscanf(ctime_str,"%02d:%02d:%lf",
   ,
   ,
   );
seconds = (int)subsecond;
subsecond = subsecond - (double)seconds;
}
else
{
return NULL;
}
NSDateComponents *dateComponents = [[NSDateComponents alloc] init];
dateComponents.day = day;
dateComponents.month = month;
dateComponents.year = year;
dateComponents.hour = hour;
dateComponents.minute = minute;
dateComponents.second = seconds;
#ifdef __APPLE__
dateComponents.nanosecond = subsecond * 10;
#endif
if(ctimezone_str!=NULL)
{
NSTimeZone *tz  = [NSTimeZone timeZoneWithName:@(ctimezone_str)];
dateComponents.timeZone = tz;
}
NSCalendar *gregorianCalendar = [[NSCalendar alloc] 
initWithCalendarIdentifier:NSCalendarIdentifierGregorian];
NSDate *date = [gregorianCalendar dateFromComponents:dateComponents];
return date;
}

NSData dataWithURL

[Andreas Fink]

Hello,

I have a strange behaviour in GNUStep. Before digging deeper, I wanted to know 
if anyone has a clue.

I have this piece of code:

- (BOOL)updateViaUrl:(NSString *)url /* returns YES on success */
  serial:(NSString *)serial
{
NSMutableString *full_url = [[NSMutableString alloc]init];
[full_url appendFormat:@"%@?serial=%@",url,[serial urlencode]];
NSURL *u = [[NSURL alloc]initWithString:full_url];
NSError *e= NULL;
@autoreleasepool
{
@try
{
#ifdef __APPLE__
NSData *data = [NSData dataWithContentsOfURL:u
 options:NSDataReadingUncached
   error:];
#else
NSData *data = [NSData dataWithContentsOfURL:u];
#endif
if((e==0) && (data.length > 0))
{
returnValue = YES;
}
}
@catch(NSException *e)
{
NSLog(@"Exception while pulling URL %@",full_url);
returnValue = NO;
}
}
return returnValue;
}


This gets called in a background thread in regular intervalls. Its updating a 
server with some statistic by pushing some data over https://..

Here's how the process is created:


- (void)runSelectorInBackground:(SEL)aSelector
 withObject:(id)anArgument
{
UMObjectThreadStarter *ts = [[UMObjectThreadStarter alloc]init];
ts.selector = aSelector;
ts.obj  = anArgument;
[NSThread detachNewThreadSelector:@selector(threadStarter:)
 toTarget:self
   withObject:ts];
}

(threadStarter: then calls above updateViaURL at some point)


What I have seen is that on gnustep it was producing a crash. This was caused 
by no autorelease pool being present as it was launched in a background thread.
@autoreleasepool {...}  fixed that crash. (On MacOS X it wasnt crashing).

Now I experience some busyloops in my application _sometimes_ and whenever I 
load it into the debugger I see that it is in dataWithContentsOfURL: call

To be noted is that the URL called could not be reachable intentionally  (no 
DNS, firewalls etc) or temporarely (no current coverage, routing issues)

For now I just disabled this code but I wondered if anyone has seen something 
similar and knows a quick workaround

Re: md5 hashing on GNUstep

[Andreas Fink]

Your approach might not give you the intended result if you have NSStrings 
containing Unicode characters which contains zero bytes. Your strlen() call 
would stop at that character and not go to the full length of a NSString. So a 
conversion to NSData and use its length would be better. For ASCII and Laltin1 
it wouldnt make a difference though.

so this would be better appraoch:

   NSData *d = [self dataUsingEncoding:NSUTF8StringEncoding];
   unsigned char result[CC_MD5_DIGEST_LENGTH];
   CC_MD5( d.bytes, (int)d.length, result );

> On 01 Apr 2020, at 20:19, Andreas Höschler  wrote:
> 
> Hi Nikolaus,
> 
>>> I have the following NSString category 
>>> 
>>> @implementation NSString (NSStringJsonExtension)
>>> 
>>> - (NSString *)md5
>>>   {
>>>#ifdef __APPLE__
>>>const char *cStr = [self UTF8String];
>>>unsigned char result[CC_MD5_DIGEST_LENGTH];
>>>CC_MD5( cStr, (int)strlen(cStr), result ); // This is the md5 call
>>>return [NSString stringWithFormat:
>>>@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x",
>>>result[0], result[1], result[2], result[3], 
>>>result[4], result[5], result[6], result[7],
>>>result[8], result[9], result[10], result[11],
>>>result[12], result[13], result[14], result[15]
>>>];  
>>>#else
>>>NSLog(@"md5 not yet supported on GNUstep. Please implement");
>> 
>> https://u10997244.ct.sendgrid.net/ls/click?upn=VVT4Fr0OoZzgz9hrDLZSJzJAAUzBaOKReTGxr-2Fx-2FWq8S8KGFYM7kdQTwqhxshnPa5cfe_tlKK9kH2hVBWbOLd8XAeSMwRALtWbXyaBq-2FNYuoUwQRR7ONi3bYz9ia6xyFyfNbfGhU69Si1801xDwBL5gLvDlSjhmIe2EpVgZRgSu-2Bjb2oNDnA0jfV-2F1YSTyfooUKnYA3nOLXTyorAnt-2FggoCWgkhOboZl-2B5oYqbI3ohAyJ6Xfv0SXaMI2yI3a3qDA3WZzjl-2BgpRcxxS4V6alTPKiv9uaYDw5JfdAc-2BzQ2sIRJZTq7tN73cGjsS3bQPZjOzy-2Fd5
>> 
>> maybe
>>  unsigned char *MD5(cStr, strlen(cStr), result);
>> 
>> You need to install openssl devel packages.
> 
> Thanks a lot! Your hint got me on the road. The following snippet 
> 
>  - (NSString *)md5
>{
> // we might have to do the following on Linux to get the code below 
> working
> // apt-get install libssl-dev
> // #include 
> // Link the framework with -lssl -lcrypto
> const char *cStr = [self UTF8String];
> unsigned char result[MD5_DIGEST_LENGTH]; 
> MD5((const unsigned char *)cStr, strlen(cStr), result); 
> return [NSString stringWithFormat:
> @"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x",
> result[0], result[1], result[2], result[3], 
> result[4], result[5], result[6], result[7],
> result[8], result[9], result[10], result[11],
> result[12], result[13], result[14], result[15]
> ];  
>}
> 
> works like a charm. :-)
> 
> Thanks,
> 
> Andreas
> 
> 

Re: libobjc2 build issues (missing files)

[Andreas Fink]

> On 5 Mar 2020, at 14:36, niels.gr...@halbordnung.de wrote:
> 
> (Re-adding the list since I foobared the last mail)
> 
> You could try forcing libobjc2 to be linked against libc++, if you’re not 
> reliant on EH interop with C++ (I don’t have the cmake flag for that present, 
> I‘m afraid). But you’re probably better off using libstdc++ for the time 
> being. 
> 
> N


adding -stdlib=libstdc++ to CFLAGS did the trick.
clang always complains about unused compiler options (probably when compiling c 
instead of c++) are filling the screen but at the end the binary works

Re: libobjc2 build issues (missing files)

[Andreas Fink]

ok the segfaults was just the wrong linker again.

export LDFLAGS="-fuse-ld=/usr/bin/ld.gold"

was missing.


Now everything compiles, the gnustep tests all pass (except some minor issues 
with date formats)
However if I build my applications, I get undefined references to   
cxa_guard_release. This is some C++ stufff. I dont use C++ or ObjC++ in my code 
anywhere. Never the less there are some linking against it from 3 libraries I 
have. These all have something in comon
Apparently libobjc2  has a reference to cxa_guard_release but I'm not sure why 
its not properly linked against if it needs it.

I'm compiling with clang-11 from the llvm repo and this uses libc++ not 
libstdc++ now I believe.
So probably a few cflags to be added. Any hint anyone?


> On 5 Mar 2020, at 12:04, Wolfgang Lux  wrote:
> 
> 
> 
>> Am 05.03.2020 um 11:21 schrieb Andreas Fink :
>> 
>> CMakeFiles/objc.dir/libstdcxx_current_primary_exception.cc.o
>> /Users/afink/development/gnustep/libobjc2/arc.mm:6:10: fatal error: 
>> 'third_party/robin-map/include/tsl/robin_map.h' file not found
>> #include "third_party/robin-map/include/tsl/robin_map.h"
>>^~~
>> 1 error generated.
>> make[2]: *** [CMakeFiles/objc.dir/build.make:411: 
>> CMakeFiles/objc.dir/arc.mm.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> [ 16%] Linking CXX static library libobjc.a
>> make[1]: *** [CMakeFiles/Makefile2:484: CMakeFiles/objc.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [ 16%] Built target objc-static
>> make: *** [Makefile:163: all] Error 2
>> 
>> 
>> Can anyone hint where this file should come from?
> 
> Those files are coming from a submodule. IIRC, you need to execute
>  git submodule init
> once in your clone.
> 
> Wolfgang
> 

Re: libobjc2 build issues (missing files)

[Andreas Fink]

actually 

git submodule init
git submodule update

did the trick.

now libobjc2 is installed but when compiling gnustep-base, all looks fine but 
make check returns all tests fail with a segfault...

Its probably something easy to fix but im not sure whats the easiest way to run 
such a test by hand with lldb



> On 5 Mar 2020, at 12:04, Wolfgang Lux  wrote:
> 
> 
> 
>> Am 05.03.2020 um 11:21 schrieb Andreas Fink :
>> 
>> CMakeFiles/objc.dir/libstdcxx_current_primary_exception.cc.o
>> /Users/afink/development/gnustep/libobjc2/arc.mm:6:10: fatal error: 
>> 'third_party/robin-map/include/tsl/robin_map.h' file not found
>> #include "third_party/robin-map/include/tsl/robin_map.h"
>>^~~
>> 1 error generated.
>> make[2]: *** [CMakeFiles/objc.dir/build.make:411: 
>> CMakeFiles/objc.dir/arc.mm.o] Error 1
>> make[2]: *** Waiting for unfinished jobs
>> [ 16%] Linking CXX static library libobjc.a
>> make[1]: *** [CMakeFiles/Makefile2:484: CMakeFiles/objc.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [ 16%] Built target objc-static
>> make: *** [Makefile:163: all] Error 2
>> 
>> 
>> Can anyone hint where this file should come from?
> 
> Those files are coming from a submodule. IIRC, you need to execute
>  git submodule init
> once in your clone.
> 
> Wolfgang
> 

libobjc2 build issues (missing files)

[Andreas Fink]

Hello

Today I tried to build libobjc2 + Gnustep packages under Debian 10 (Buster) and 
I did run into a new problem:



cmake  .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_STATIC_LIBOBJC=1  
-DCMAKE_C_COMPILER=/usr/bin/clan   -DCMAKE_CXX_COMPILER=/usr/bin/clang++

...
make -j8
...

[ 10%] Building C object CMakeFiles/objc.dir/hooks.c.o
[ 10%] Building C object CMakeFiles/objc.dir/ivar.c.o
[ 10%] Building C object CMakeFiles/objc.dir/loader.c.o
[ 11%] Building C object CMakeFiles/objc.dir/mutation.m.o
[ 11%] Building C object CMakeFiles/objc.dir/protocol.c.o
[ 11%] Building C object CMakeFiles/objc.dir/runtime.c.o
[ 11%] Building C object CMakeFiles/objc.dir/sarray2.c.o
[ 12%] Building C object CMakeFiles/objc.dir/selector_table.c.o
[ 12%] Building C object CMakeFiles/objc.dir/sendmsg2.c.o
[ 12%] Building C object CMakeFiles/objc.dir/eh_personality.c.o
[ 12%] Building C object CMakeFiles/objc.dir/legacy.c.o
[ 12%] Building C object CMakeFiles/objc.dir/abi_version.c.o
[ 13%] Building C object CMakeFiles/objc.dir/statics_loader.c.o
[ 13%] Building ASM object CMakeFiles/objc.dir/block_trampolines.S.o
[ 13%] Building ASM object CMakeFiles/objc.dir/objc_msgSend.S.o
[ 13%] Building C object CMakeFiles/objc.dir/NSBlocks.m.o
[ 13%] Building C object CMakeFiles/objc.dir/associate.m.o
[ 14%] Building C object CMakeFiles/objc.dir/Protocol2.m.o
[ 14%] Building C object CMakeFiles/objc.dir/blocks_runtime.m.o
[ 14%] Building C object CMakeFiles/objc.dir/properties.m.o
[ 15%] Building C object CMakeFiles/objc.dir/gc_none.c.o
[ 15%] Building CXX object CMakeFiles/objc.dir/arc.mm.o
[ 15%] Building CXX object CMakeFiles/objc.dir/objcxx_eh.cc.o
[ 15%] Building CXX object 
CMakeFiles/objc.dir/libstdcxx_current_primary_exception.cc.o
/Users/afink/development/gnustep/libobjc2/arc.mm:6:10: fatal error: 
'third_party/robin-map/include/tsl/robin_map.h' file not found
#include "third_party/robin-map/include/tsl/robin_map.h"
 ^~~
1 error generated.
make[2]: *** [CMakeFiles/objc.dir/build.make:411: CMakeFiles/objc.dir/arc.mm.o] 
Error 1
make[2]: *** Waiting for unfinished jobs
[ 16%] Linking CXX static library libobjc.a
make[1]: *** [CMakeFiles/Makefile2:484: CMakeFiles/objc.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 16%] Built target objc-static
make: *** [Makefile:163: all] Error 2


Can anyone hint where this file should come from?

Re: plmerge core dumps...

[Andreas Fink]

> On 13 Feb 2020, at 11:35, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 13 Feb 2020, at 09:44, Andreas Fink  wrote:
>> 
>> This is not a problem of gnustep but of objectiveC.
>> Yes its a pain that the standard linker doesnt work. But it is what it is. 
>> until someone fixes the standard linker we can't do much.
> 
> I'm not sure where the responsibility lies (maybe nobody knows and that's why 
> it exists):
> Is it a bug in the linker?

yes

> Is it a bug in clang for not invoking the linker correctly?

no 

> Is it a bug in gnustep-make for not passing some extra flag to clang to tell 
> it how to invoke the linker correctly?

no

> 
>> This is mainly given by the fact that modern ObjC support in gcc is still 
>> missing. clang does much better here but there where still some bugs in 
>> clang before version 8 which can get you into trouble.
>> 
>> So golden rule is clang >= 8.0 and linker = ld.gold and it will work.
> 
> Yes, that works for me to build base/gui and quite a lot of other stuff, but 
> not all my code by any means:  I find there are other libraries/tools that 
> fail to link using ld.gold
> Until I can figure out what to do about that, I can't migrate the codebase 
> where I work to use the latest runtime :-(

as far as other libraries  / tools go,  the requirement for ld.gold is only 
there for ObjectiveC code. If you link C code thats not an issue.

Re: plmerge core dumps...

[Andreas Fink]

This is not a problem of gnustep but of objectiveC.
Yes its a pain that the standard linker doesnt work. But it is what it is. 
until someone fixes the standard linker we can't do much.
This is mainly given by the fact that modern ObjC support in gcc is still 
missing. clang does much better here but there where still some bugs in clang 
before version 8 which can get you into trouble.

So golden rule is clang >= 8.0 and linker = ld.gold and it will work.



> On 13 Feb 2020, at 10:37, Gregory Casamento  wrote:
> 
> So, what we are, essentially, saying is that GNUstep can't work with the 
> standard Linux linker.   I'm wondering in whose mind this is acceptable.
> 
> GC
> 
> On Wed, Feb 12, 2020 at 9:32 AM Gregory Casamento  > wrote:
> Facepalm this is happening every time I rebuild.  Ugh!  I really can't delete 
> my whole installation every time.
> 
> On Tue, Feb 11, 2020 at 8:56 AM Richard Frith-Macdonald 
> mailto:rich...@frithmacdonald.me.uk>> wrote:
> 
> 
> > On 11 Feb 2020, at 13:47, David Chisnall  > > wrote:
> > 
> > On 11/02/2020 12:30, Richard Frith-Macdonald wrote:
> >> clang -v reported that the normal, system linker was being used
> > 
> > FYI: On most GNU/Linux platforms, BFD is the 'normal, system linker'. For 
> > example:
> > 
> > $ ld -v
> > GNU ld (GNU Binutils for Debian) 2.31.1
> > 
> > This is the BFD linker on a Debian system.
> > 
> > $ ld.gold -v
> > GNU gold (GNU Binutils for Debian 2.31.1) 1.16
> > 
> > This is gold on a Debian system.  It is installed by the binutils package, 
> > but is not installed as the system linker.
> > 
> > $ ld -v
> > LLD 8.0.1 (FreeBSD 366581-128) (compatible with GNU linkers)
> > 
> > This is LLD on a FreeBSD system.  It is the system linker.
> 
> Thanks.
> Mine was a CentOS-7 system with 'alternatives' set to use ld.gold
> I did have three toolchains installed (which may have confused thngs), but 
> all three were set to use ld.gold
> Only when I removed all copies of ld.bfd was I able to build gnustep-base to 
> use the new ABI and have it not crash immediately on startup.
> My best guess at an explanation is that I did something (in the distant past 
> so I don't remember) that confused/broke the 'alternatives' system.
> 
> Something else worth noting wrt the core dump is that it's quite commonplace, 
> when building/installing the core libraries, that if something is horribly 
> broken in base it will show up as soon as you try to build gui and that runs 
> plmerge: a plmerge segfault could have many causes, and I didn't mean to 
> blame it on using the new ABI or the bfd linker.
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org 
> 
>  - http://heronsperch.blogspot.com 
> 
> http://ind.ie/phoenix/ 
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org 
> 
>  - http://heronsperch.blogspot.com 
> 
> http://ind.ie/phoenix/ 
> 

Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)

[Andreas Fink]

> On 27 Nov 2019, at 19:02, Max Chan  wrote:
> 
> I wonder how Apple implemented their version though… I do have an 
> observation: if I force VESA graphics on my Hackintosh (this requires special 
> boot flags, so it is easier to do on Hackintosh than a real Mac,) the OS 
> interfaces are rendered very slowly. However if I allow accelerated graphics 
> (default behavior,) it operates smoothly but from time to time the GPU fan 
> would spin up even though there is no GPU-intensive tasks.
>  
> I think Apple went down the exclusive OpenGL/Metal route. That is, either get 
> accelerated graphics working at a kernel level, or tolerate slow CoreGraphics.


Given OSX 10.15 and above does require metal support graphics hardware, (a old 
MacPro (the big PC style towers, not the round ugly thing) could not be 
upgraded to 10.15 unless it had a metal capable video card, would confirm that.

Re: libobjc2 build issue

[Andreas Fink]

it was complaining that i need least 3.14.
Debian 10 comes with 3.13.4
but now I can't reproduce that. I have to investigate this...
I'll retest with a empty new VM
It happened to me on 2 separate machines

> On 27 Nov 2019, at 11:59, David Chisnall  wrote:
> 
> On 27/11/2019 10:49, Andreas Fink wrote:
>> Which cmake version did you use to get it built as the one coming with 
>> Debian10 is too old.
> 
> What error did you get?  The minimum required is 3.1[1], which is from some 
> time around 2014.  I would be shocked if Debian included something that old.
> 
> David
> 
> [1] 
> https://github.com/gnustep/libobjc2/blob/8249036318cc3be39e40e98cdf3e62b6f5aba36d/CMakeLists.txt#L1
> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 27 Nov 2019, at 10:48, Johannes Brakensiek  
> wrote:
> 
> On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
> 
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility? It seems
> some people think yes, and others think no. We're at a stalemate, where no
> progress can be expected to take place. For things to move forward, either
> one side has to give in, or both sides can compromise and agree to a middle
> ground.
> 
> You described the dilemma very well. (And I also want to thank David and Ivan 
> to their excellent contributions to this thread.) Some people are very 
> conservative in this group. But others have a bit too much wishful thinking. 
> I myself would not mind too much loosing gcc but loosing active developers 
> and packagers. Sadly for some this doesn’t seem to be an argument.
> 
> I think for those who have to do the decision (who’s that anyways, the active 
> contributors?) this probably will be good reason („argument“ ;)) as this is a 
> community of people working non-profit who seem to have strong feelings 
> regarding some options.
> 
> What I want to tell (being quite new to this community and not having these 
> strong bindings) is there are some reasons that are mainly considered outside 
> of this mailing list which should be important here as well, imho.
> 
> To name a few (just referring to what I’ve read, not meant as a personal 
> insult at all):
> 
> the GNUstep project is largely considered dead
> the only bigger free software project relying on GNUstep which seems to be of 
> greater relevance and extension is SOGo, which relies on Foundation and 
> GNUstep web, but not on AppKit (any of the devs active here?)
> German companies that used GNUstep told me they already switched to using 
> Foundation and GNUsteb web only as users did not accept the AppKit interface 
> anymore
> So, if people like the SOGo devs would say they need GCC because they are 
> relying on it and Foundation/GNUstep web, I’d say it would be a very 
> reasonable decision to keep Foundation and GNUstep web compatible to GCC.
> 
> But if there are no bigger projects depending on a GCC AppKit it should be a 
> first class aim of the project to develop it to a state that others would 
> consider picking it up and using it for their projects - imo. Yes, that’s 
> investing into future and it comes at the cost and risk of not being 
> successful, of course. But please bear in mind that probably there are a lot 
> more devs (here just being a few of them trying to give them a voice) that 
> evaluate which platform to use for their apps and probably pass by and choose 
> Qt or a web based platform.
> 
> I think that’s a pity as GNUstep AppKit could be highly attractive for Cocoa 
> ObjC devs wanting to port their apps to Linux and a free environment (and 
> maybe don’t want switch to Swift yet). If you don’t want that target audience 
> it’s your decision, but I’d be interested to know who’s your target audience 
> then? Of course you can do it just for yourself, but I think it’s unlikely 
> others will join then.
> 
> Johannes
> 

Thats a very good summary. For me  Foundation is what I use. But thats mainly 
because I do background server apps and tasks for Telecom Infrastructure. So I 
don't care about AppKit much right now. I care about a good and stable 
Objective-C development environment.

On the other hand I would _LOVE_ to see a OS X like desktop with AppKit and I 
would spend time working on it. Given the other desktops under Linux have not 
much success because of the way they do certain things, I think there is a big 
need. Something like what ElementaryOS does but with GNUStep and running on the 
major distributions (Debian/Ubuntu/Fedora/Redhat/Centos) could change the 
world. This is a long shot. But we have to ask ourselfs what is our strategy 
for the future.

Apple with Catalina is going in such a horrible direction that I'm moving away 
from it. My code can't run under Catalina because they have still not 
implemented SCTP protocol and its a mandatory for my work. And now the open 
source SCTP kernel driver can no longer work because they moved such stuff to 
userspace which kills a lot of mandatory features. So rewrite driver from 
scratch, just for MacOS whereas any other decent platform (Linux, FreeBSD) has 
it built in is an overkill.  And their Wallet garden approach is breaking lots 
of openSource apps etc. For example you can no logner write to /. So if your 
open source code uses /opt/something, youe dead as you can't create /opt etc 
etc. (but anyway, thats a rant for another day).

As far as Gnustep /App Kit goes, if the pillars below always fall apart, then 
its wasted time for any developer to work on it.  I think the key issues is 
that a lot of folks wanted to try GnuStep and fail because they could not get 
to some degree of success quickly. Everything is "old fashioned", doesnt 
compile 

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  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
>  
> <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  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 <http://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 >> <mailto:plaur...@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
>>>  
>>> <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 >>> <mailto:af...@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
>>>> 
>> 

Re: libobjc2 build issue

[Andreas Fink]

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 <http://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  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
>  
> <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  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
>> 

Re: libobjc2 build issue

[Andreas Fink]

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

libobjc2 build issue

[Andreas Fink]

Today I tried to build libobjc2 again as I  did many time before and I get this 
missing file:


gnustep/libobjc2/arc.mm:6:10: fatal error: 
'third_party/robin-map/include/tsl/robin_map.h' file not found


anyone having a clue what dependency this is?

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 26 Nov 2019, at 15:06, H. Nikolaus Schaller  wrote:
> 
> 
>> Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
>> 
>> I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 
> 
> just came to my mind: ClangSTEP?


what a tong breaker. FreeStep sounds better to me :)
Drop the "GNU" and break free.


> 
>> 
>> On Tue, 26 Nov 2019 04:55:43 -0500
>> Gregory Casamento  wrote:
>> 
>>> I'd really like some resolution on this topic.   There seem to be a lot of
>>> reasons for and against.
>>> 
>>> GC
>>> 
>>> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
>>> wrote:
>>> 
 On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> I am not sure that this is the only way to implement it.
> 
> First of all the callMethodOn returns some block which is a data
 structure knowing that it should take the parameter x and do some function.
> Let's call it NSBlock. NSBlock can be an ordinary object like any other
 so that it can follow the same memory management rules as used otherwise.
 
 That’s shifting the goalposts somewhat.  It is not news that objects and
 closures are equivalent.  Smalltalk implemented blocks as BlockClosure
 objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
 lambdas (which are just shorthand for C++ objects that implement
 `operator()`).  You can always express anything that uses blocks with
 objects.
 
 There are two issues:
 
 1. If you want to be compatible with existing APIs that use blocks, you
 need to be ABI compatible with blocks.
 2. The reason that most languages that have objects also have blocks is
 that the shorthand syntax is very convenient.
 
 The following are roughly equivalent:
 
 ```
 @interface Delegate : NSObject
 - (void)invoke;
 - (instancetype)initWithCapture: (id)someObject;
 @end
 
 @implementation Delegate
 {
   @private
   id obj;
 }
 - (instancetype)initWithCapture: (id)someObject
 {
   if ((self = [super init]) == nil) return nil;
   obj = [someObject retain];
   return self;
 }
 - (void)invoke
 {
   [obj doSomething];
 }
 - (void)dealloc
 {
   [obj release];
   [super dealloc];
 }
 @end
 
 // At construction site:
 
 [[Delegate alloc] initWithCapture: x];
 
 // At use site:
 
 [delegate invoke];
 ```
 
 And this, with blocks:
 
 ```
 // At construction site:
 
 ^() { [x doSomething]; };
 
 // At use site:
 
 delegate();
 ```
 
 At use, these are similar complexity for the programmer.  At the point of
 construction, one is one line of code (two or three if you put lambda
 bodies on their own lines), the other is 26.  As a programmer, I don’t want
 to write 26 lines of code for a one-line callback.
 
 In C++98 you could probably template that and provide a generic class that
 took a struct containing the captures and a C function, so you’d get a lot
 less boilerplate.  Assuming you had fudged ARC like this (as above, this
 code is typed into a mail client and probably doesn’t compile):
 
 ```
 template
 struct ObjCObjectWrapper
 {
   ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
   ObjCObjectWrapper(const ObjCObjectWrapper ) :
 obj(objc_retain(other.obj) {}
   ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
   {
   other.obj = nil;
   }
   ObjCObjectWrapper()
   {
   objc_release(obj);
   }
   operator=(T x)
   {
   objc_storeStrong(, x);
   }
   T operator()
   {
   return obj;
   }
   private:
   T obj;
 
 };
 ```
 
 You could then define a generic capture structure and invoke method like
 this:
 
 ```
 template
 struct BlockImpl
 {
   using invoke_t = Ret(*)(Capture &, Args...);
   void operator()(Args... args)
   {
   inv(capture, std::forward(args)…);
   }
   Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
   private:
   Capture capture;
   invoke_t inv;
 };
 ```
 
 This is then generic and you could use it as follows:
 
 ```
 struct CaptureOneObject
 {
   ObjCObjectWrapper o;
 };
 void invoke(CaptureOneObject )
 {
   [(id)c.o doSomething];
 }
 // At construction site:
 std::function block(BlockImpl({x},
 invoke));
 // At use site:
 block();
 ```
 
 I *think* you could get the same ABI as blocks if you worked on the
 generic templated boilerplate a bit.
 
 Of course, if you were using C++ then you could also write it using

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 25 Nov 2019, at 14:37, Yavor Doganov  wrote:
> 
> Gregory Casamento wrote:
>> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:
>>> The answer is simple: because there's a lot to lose and nothing to
>>> gain.
> 
>> This is patently incorrect.  The gain is time and compatibility with
>> the latest code base.  I laid out the advantages and disadvantages
>> of this in my previous posting.
> 
> There are no advantages for the current GNUstep packages in Debian
> which is the main point I was trying to make.  I don't dispute the
> fact that dropping support for GCC will simplify things a lot for
> you.  At certain cost, of course, which you consider negligible.
> 
>> * More Applications, more applications means more end users (sort of
>> chicken and egg thing)
> 
> That's purely hypothetical to the extent of being mere speculation.
> GNUstep supports Clang and David's runtime for quite some time now,
> why there are no more applications?  Why existing GNUstep applications
> have not been updated to take advantage of the new features?

I can tell you exactly why. When I tried out GNUstep for the first time to port 
my OS X apps to Debian, I simply did "apt-get install gnustep" and wanted to 
compile my code and nothing really worked.
Then it took me several weeks to figure out how to get a working toolchain with 
libobjc2 and ARC support which my code required. And I am not a newbie. I write 
code on MacOS since 1994 and Linux since like 1992. The major roadblocks where:

a) the tools which come with Debian where totally useless as it did not support 
modern Objc2 features which my ported code was using already. And it took a 
while to even figure that out.
b) the build process is not well documented. You find all kinds of build info 
out there in the net out of which most are totally outdated and don't work 
anymore. (this has become a bit better since).
c)  there where some bugs, especially in the linking part which where totally 
throwing you off the rails and where giving very puzzling information.
d) if you don't pay attention, the old runtime libobjc which comes with gcc 
gets into your way. And the package is named libobjc4. So go figure that 
libobjc2 is actually newer...

I can assure you that people who are used to MacOS X and Xcode , 99% of it will 
run away. They will simply claim GnuStep is not a mature project.

If you read through my readme   
https://github.com/andreasfink/ulib/blob/master/doc/README-Debian9-stretch.txt 

 you will see how many things can go wrong.

Part of the problem was that Debian 9 was packaging clang 3.8 which is quire  
old these days and was lacking some stuff as well.
Recent Debian 10 however fixed this and adding clang from the llvm repository 
to get a newer version is kind of not a big issue. These days you need clang8 
or newer if you don't want to run into some nasty bugs and use a prebuilt 
package.

The linker was one of the biggest problem. Easy to fix but very difficult to 
figure.

I also tried other options beforehand. Namely Cocotron. The problem with that 
was that its built for crosscompiling from a Mac. Recent upgrades from Xcode 
basically broke that and I think the folks who work on that are mainly focused 
to get it run well on Windows and don't care so much about Linux. Also there's 
not much happening with Cocotron these days. Hence I dropped using it and use 
GNUStep for all my ObjC code under Linux these days. And for me its performing 
very well, once I had working packages.



>> What's to lose:
>> * Possibly a political issue with the FSF, but there are other projects
>> which depend on languages not implemented by GCC.
> 
> I'm not aware of any GNU package written in a compiled language that
> cannot be built with GCC.

I'm not aware of any other GNU package written in ObjC (or even any other 
compiled language besides C or C++).


> I don't know what you mean by "political issue" but such a drastic
> change should be discussed with the GNU Project of which GNUstep is
> still part of.  It is wrong to decide it with a vote that doesn't even
> specify simple things like who is eligible to vote and based on what
> majority the decision is going to be taken.  As a GNU maintainer you
> should know these things.
> 
>> * Support for older platforms which ONLY support gcc.
> 
> RISC-V is the newest GNU/Linux architecture and it's not yet supported
> by Clang.

Wrong

https://riscv.org/2019/10/llvm-clang-risc-v-now-supports-lto-michael-larabel-phoronix/
 



> 
>> So, I apologize if I don't agree with the "nothing to gain" opinion.
> 
> You are free to disagree.  But as it often happens with real life, the
> loss may become obvious only post factum...  You could be left only
> with the "gain" which may not look like a big gain then.  It could
> even look more like you have shot 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 25 Nov 2019, at 11:18, H. Nikolaus Schaller  wrote:
> 
> I know that I likely start a flame war, but watching the discussion from an 
> elevated point of view...
> 
>> Am 25.11.2019 um 10:30 schrieb Gregory Casamento :
>> * Compatibility, much of the API is moving towards using blocks. Blocks *ARE 
>> NOT SUPPORTED* on GCC and aren't likely to be anytime in the near future.
> 
> Hm, where has our own creativity gone?
> 
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.
> 
> So this argument for moving to clang looks more like an excuse that we do not 
> work on our own gcc compatible solution, isn't it?
> 
> -- hns

using the same argument you can say we could use assember by creating some 
tools to output assembler first.
As David pointed out, its a  hell of a lot of work for no benefit and dragging 
along old workarounds which lead to problems and performance impacts.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 24 Nov 2019, at 10:11, Max Chan  wrote:
> 
> I would like to add another plus for dropping GCC: if we want any hope for 
> Swift interworking, we have to use clang as the compiler.
> 
> Apple have no plan to provide any GUI support on Linux version of Swift.

Theres some folks out there working on SwiftUI for other platforms as far as I 
know.

> If we have Swift interworking, even though we may have to drop our own 
> libobjc, Foundation and CoreFoundation in favor of Apple’s release, the 
> GNUStep GUI package can provide the replacement AppKit that Apple’s Swift 
> release lacked.

Is this really true? Interoperability with Swift in my eyes is important for 
the future

Even though I personally don't like Swift (mainly because its not a natural 
upgrade path from C style but implies totally new syntax and does not mean you 
can easily slam existing C or ObjectiveC code in it and it takes time I don't 
have to learn it again), its a modern language getting more and more 
importance. Also in the light of the strong support of Swift from IBM I would 
not underestimate its potential.

The future of Gnustep I see in the area of providing a real good desktop at the 
end. It doesn't have to be a copycat of OS X but allowing ported applications 
to work more or less out of the box. I like what ElementaryOS does. Except its 
based on some fancy language called Vala which is a showstopper for porting. 
The strengths of Gnustep are that people writing MacOS X apps could port them 
to other platforms. And that should include Swift apps  as this area its 
growing big. (and as Swift nicely interwork with ObjC).

I'm  happy to contribute (except I'm not a GUI guy but more  network/daemons 
focused).

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> 
>> This is a major advantage of Objc2.0. 
>> I must admit it took me a while to get used to though. But at the end it 
>> paid off a lot.
> 
> Well, to be precise: ARC could also be done with ObjC 1.0 as far as I see. 
> There is IMHO no special syntax for ARC. You just remove all 
> retain/release/autorelease from the code and the compiler is clever enough to 
> magically make it still work.
> 
> So in summary, ARC alone isn't sufficiently helpful for my work to switch to 
> ObjC 2.0 and no longer use gcc.
> 


The fact is that gcc can not do ARC. This is the main show stopper for gcc. 
On the other hand, switching from gcc to clang is not a problem for 
"traditional programming style" programmers.

The only problem I can see is platforms which gcc supports but clang does not. 
So the real question is are there any users who use ObjC stuff with GnuStep 
under, lets say strange embedded systems.
Given ObjC does not have a bright future under gcc anyway (as they have still 
not implemented ObjC 2.0 features after like 10 years it's out now), does mean 
it will only get worse.

Besides that we have to consider that sticking to gcc will also hinders 
newcomers to get involved. And this i I think is a important point.
The developers hehre with 20 years+ experience will have no problem working 
around non ARC stuff and going backwords because we all know the  old way.
The youngsters out there however don't. If we want to get Gnustep into the 
modern area, we will need to be attractive to newcomes and this means keeping 
up with the modern API's etc. And gcc is miserably failing here. Thats the main 
problem, not if you don't want to use ARC (which is still fine) or not. Others 
want to use ARC but can't under GCC.

In other words, going for clang doesnt mean ObjC 1.0 code wont run but it means 
a lot of ObjC2.0 code will start to run.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 22 Nov 2019, at 09:08, H. Nikolaus Schaller  wrote:
> 
> 
>> Am 22.11.2019 um 08:40 schrieb David Chisnall :
>> 
>> On 22 Nov 2019, at 05:31, H. Nikolaus Schaller  wrote:
>>> 
>>> And the first thing I turn off in a
>>> new Xcode project is ARC.
>> 
>> Why?  ARC generates smaller code, faster code, and code that is more likely 
>> to be correct.
> 
> I never had a problem with any of those three. Code correctness is rarely a 
> retain/release problem but the algorithm.
> So it solves only a small percentage of the coding problems I do face.


Then you have not done any big projects.

Even though my code is well designed in terms of ownership of objects, I still 
managed to every once in a while shoot myself into the foot and have to track 
down memory leaks forever or random crashes.
Switching to ARC made all these problems go away. No more use after free, no 
more keeping objects around after no one uses it anymore etc.
You don't have to think of releasing stuff if you are in the middle of a long 
routine and throw an exception or call return.

This is a major advantage of Objc2.0. 
I must admit it took me a while to get used to though. But at the end it paid 
off a lot.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 21 Nov 2019, at 12:15, Gregory Casamento  wrote:
> 
> David et al, 
> 
> For all of the reasons listed in the previous email I am starting to wonder 
> about the viability of using GCC in the long run.  As far as I can see it the 
> facts are these:
> 
> 1. GCC does not support ARC, blocks and many other features which the API is 
> now using 
> 2. Supporting GCC consumes more time due to having to work around these 
> features using awkward macros
> 3. The further clang's implementation and gcc's implementation of the 
> language drift apart, the more macros we will need to add
> 4. The work needed to add these features is monumental
> 5. We cannot depend on the GCC team to add these as they are more focused on 
> languages outside of ObjC.
> 
> The advantages to dropping GCC are as follows:
> 
> 1. We can simplify the code drastically by removing any and all macros to 
> abstract the missing features 
> 2. We can switch to using faster C++ or ObjC++ implementations of certain 
> functionality.  TBD further.
> 3. We get ARC memory management for free.
> 4. Speeds up development since less time is spent on managing some of the 
> above.
> 
> Disadvantages to dropping GCC:
> 
> 1. Political backlash from the FSF (possible, but unlikely there are projects 
> which use languages not supported by GCC)
> 2. Not able to support older hardware on which clang is unavailable and gcc 
> still is.
> * We need to assess how critical supporting that hardware is.
> 3. Altering our "NetBSD" like philosophy where we can say "Of course GNUstep 
> will build on it."
> 
> Right now these lists are just food for thought.   I am trying to start a 
> discussion about this, not making any final decisions yet.
> 
> Yours, GC
> 
> 

I completely agree.

I have strong doubts that ObjC is used anywhere in the exotic hardware area.
Like if I look at the embedded field where mostly other processor types are 
used, I don't see why GNUStep would be of any use there. And if, they can still 
use an old frozen gcc version if they are old.
I must admit that myself I use GNUStep without any desktop in mind, basically 
Foundation is what I need for my server applications because my code is heavily 
written in ObjC and especially because of its nice features such as ARC. So for 
me going back to gcc is absolutely impossible.

So besides Intel and ARM architectures, what is really used out there in the 
field?
. 

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 12:02, Johannes Brakensiek  
> wrote:
> 
> 
> 
> On 20 Nov 2019, at 11:56, Ivan Vučica wrote:
> 
>> I think that, when you say “you are doing this”, you also miss the part 
>> where I am not a Debian developer and do not build the Debian source+binary 
>> packages that are shipped in Debian :-)
> 
> Yes, I’m sorry. I’ve been in contact about this issue with Yavor Doganov, not 
> with you. :) He was the one who told me about sticking to GCC because of the 
> architectures Debian supports/wants to support.
> 

Which platforms are we exactly talking about?

Is clang not supporting all these additional platforms?
is libobjc even supporting all these other platforms?

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 10:55, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 20 Nov 2019, at 08:37, Andreas Fink  wrote:
>> 
>> 
>> 
>>> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
>>> wrote:
>>> 
>>> Hey Ivan,
>>> 
>>> thank you for your work and your explanations!
>>> 
>>> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
>>> 
>>>> Now... developers may need updated versions when developing their apps. I 
>>>> remember Debian not shipping with NSViewController or NSWindowController 
>>>> when I first came around -- but on the other hand, when I would cut a 
>>>> release, an updated .deb would follow. (Not to mention our source code 
>>>> became much more discoverable, so seeing if a class is missing is much 
>>>> easier too.)
>>>> 
>>>> So when a developer needs a newer version so they can prepare a source 
>>>> tarball for Debian to integrate... they can talk to us. We cut our 
>>>> release, a Debian maintainer (e.g. Yavor) picks it up, the app gets picked 
>>>> up too, everyone happy.
>>>> 
>>>> Yes, I would say developers are very welcome to advocate with maintainers 
>>>> for a release if not cutting one blocks their app's release. :-)
>>>> 
>>>> And at this time, I am still here to help component maintainers with a 
>>>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>>>> evening or two to tackle this kind of request.
>>>> 
>>>> Do you have a specific anecdote about something you wanted up to date, as 
>>>> a binary, which wasn’t in your favorite distro?
>>> 
>>> The problem simply is that f.e. Debian ships libs that are build with GCC 
>>> and thus are missing any of the new language features. I understand you are 
>>> doing this for compatibility with other processor platforms. But this leads 
>>> to the problem that any app developer who wants to build a new app based 
>>> upon the clang ABI has to build and ship everything on his own. I really 
>>> think this is a show blocker for attracting new developers (or even users). 
>>> Or did I miss anything here?
>>> 
>>> Johannes
>>> 
>> 
>> 
>> I can completely agree on this statement. Due to modern code using ARC 
>> everywhere, the gnustep coming with Debian (which is  my main deployment 
>> platform) is usually a problem. I always have to make sure its not installed 
>> and install my own packaged version. On the other hand I have not seen 
>> anyone using ObjectiveC without ARC these days.. Its nice to have for 
>> nostalgia but ARC has solved a million problems for me in my code over the 
>> last decades. So today, I would not even think to do anything with gnustep 
>> without clang.
>> 
>> Having a gnustep which works with arc and without arc would be ok. but 
>> shipping packaged versions with libraries which can not work with ARC is a 
>> show stopper.
>> 
>> And when GNUStep wants to continue following the development of OSX's 
>> platform, ARC is there since more than a decade and everyone depends on it. 
>> So if anyone wants to port OS X code to Linux and considers GNUStep as a 
>> logica platform, then ARC support is a must.
> 
> I have never used a mixed configuration, but from what David's said in the 
> past (I expect he will correct me if I'm wrong),  for the libraries ARC 
> should work whether or not GNUstep is built with clang.
> The libraries do not need to use ARC internally in order to be used by 
> software that is built for ARC, as long as they are built for the same 
> runtime.

there's the catch..  the current distros all come with the old runtime and 
thats where everything falls apart miserably.

> But if a distribution provides gnustep-make configured to use gcc, you would 
> need to install/configure your own version to use clang.
> 

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
> wrote:
> 
> Hey Ivan,
> 
> thank you for your work and your explanations!
> 
> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
> 
>> Now... developers may need updated versions when developing their apps. I 
>> remember Debian not shipping with NSViewController or NSWindowController 
>> when I first came around -- but on the other hand, when I would cut a 
>> release, an updated .deb would follow. (Not to mention our source code 
>> became much more discoverable, so seeing if a class is missing is much 
>> easier too.)
>> 
>> So when a developer needs a newer version so they can prepare a source 
>> tarball for Debian to integrate... they can talk to us. We cut our release, 
>> a Debian maintainer (e.g. Yavor) picks it up, the app gets picked up too, 
>> everyone happy.
>> 
>> Yes, I would say developers are very welcome to advocate with maintainers 
>> for a release if not cutting one blocks their app's release. :-)
>> 
>> And at this time, I am still here to help component maintainers with a 
>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>> evening or two to tackle this kind of request.
>> 
>> Do you have a specific anecdote about something you wanted up to date, as a 
>> binary, which wasn’t in your favorite distro?
> 
> The problem simply is that f.e. Debian ships libs that are build with GCC and 
> thus are missing any of the new language features. I understand you are doing 
> this for compatibility with other processor platforms. But this leads to the 
> problem that any app developer who wants to build a new app based upon the 
> clang ABI has to build and ship everything on his own. I really think this is 
> a show blocker for attracting new developers (or even users). Or did I miss 
> anything here?
> 
> Johannes
> 


I can completely agree on this statement. Due to modern code using ARC 
everywhere, the gnustep coming with Debian (which is  my main deployment 
platform) is usually a problem. I always have to make sure its not installed 
and install my own packaged version. On the other hand I have not seen anyone 
using ObjectiveC without ARC these days.. Its nice to have for nostalgia but 
ARC has solved a million problems for me in my code over the last decades. So 
today, I would not even think to do anything with gnustep without clang.

Having a gnustep which works with arc and without arc would be ok. but shipping 
packaged versions with libraries which can not work with ARC is a show stopper.

And when GNUStep wants to continue following the development of OSX's platform, 
ARC is there since more than a decade and everyone depends on it. So if anyone 
wants to port OS X code to Linux and considers GNUStep as a logica platform, 
then ARC support is a must.

Re: Adventures in libobjc-2.0 land with Debian Buster (32 bit)

[Andreas Fink]

this might help you. It's based on Debian9 but on Debian10 theres only a few dependency libraries having a newever version number.Key takeaway: use llvm8 or llvm9 and use the gold linker and set RUNTIME_VERSION=gnustep-2.0.

installing-gnustep-2019-03-08.pdf
Description: Adobe PDF document
the 
		
	
	
		
			

	
		 18 - AssociatedObject_optimised (OTHER_FAULT)
 20 - AssociatedObject_legacy_optimised (OTHER_FAULT)
errors are still there though but are corner cases accoring to David Chisnall
	

			
		On 24 Jul 2019, at 19:25, Bertrand Dekoninck  wrote:Hi ! I'm currently testing gnustep in debian 10 (32 bit) with libobjc-2.0. I plan to try 64 bit version soon.I've built ilt with clang-8 from https://apt.llvm.org/ and with a script adapted from Patryck Laurent's ones (see attachment).I've tested on real hardware and in a virtual machine and got the same errors.Everything builds fine, base an gui pass test correctly  and most apps run. But some tests fail in libobjc-2.0 :	 19 - AssociatedObject_legacy (Child aborted)	 20 - AssociatedObject_legacy_optimised (Child aborted)Also, GWorkspace fails to load with the following error : Unknown protocol versionAbortI tried with debugapp and gdb and got the following backtrace :bertrand@buster32:~/Bureau/GNUstep-build/libobjc2/build$ debugapp GWorkspaceGNU gdb (Debian 8.2.1-2) 8.2.1Copyright (C) 2018 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Type "show copying" and "show warranty" for details.This GDB was configured as "i686-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:.Find the GDB manual and other documentation resources online at:    .For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from /usr/GNUstep/Local/Applications/GWorkspace.app/GWorkspace...done.(gdb) runStarting program: /usr/GNUstep/Local/Applications/GWorkspace.app/GWorkspace [Thread debugging using libthread_db enabled]Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".Unknown protocol versionProgram received signal SIGABRT, Aborted.0xb7fd4d41 in __kernel_vsyscall ()(gdb) bt#0  0xb7fd4d41 in __kernel_vsyscall ()#1  0xb72ea382 in __libc_signal_restore_set (set=0xbfffde8c)    at ../sysdeps/unix/sysv/linux/internal-signals.h:84#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48#3  0xb72d42b6 in __GI_abort () at abort.c:79#4  0xb75ce5b7 in init_protocols ()   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6#5  0xb75cdc89 in objc_init_protocols ()   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6#6  0xb75c987a in objc_load_class ()   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6#7  0xb75cd55e in __objc_load ()   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6#8  0xb76c275e in .objcv2_load_function ()   from /usr/GNUstep/Local/Library/Libraries/libgnustep-base.so.1.26#9  0xb7fe6343 in call_init (l=, argc=argc@entry=1,     argv=argv@entry=0xbfffe264, env=0xbfffe26c) at dl-init.c:72#10 0xb7fe6442 in call_init (env=0xbfffe26c, argv=0xbfffe264, argc=1,     l=) at dl-init.c:30#11 _dl_init (main_map=, argc=1, argv=0xbfffe264,     env=0xbfffe26c) at dl-init.c:119#12 0xb7fd70fa in _dl_start_user () from /lib/ld-linux.so.2(gdb) Last issue for now :  rik.theme builds fine but doesn't display properly. I know rik uses objc_setAssociatedObject and objc_getAssociatedObject in its Rik+Button.m file.Does anyone encounter these kind of issues
___Discuss-gnustep mailing listDiscuss-gnustep@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnustep___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FreeBSD ports for GDL2 and GSWeb

[Andreas Fink]

You mean this one: https://github.com/gnustep/libs-gsweb 
<https://github.com/gnustep/libs-gsweb> ?

If GNUStep is ported to your target platform then applications or  libraries 
using gnustep should work out of the box without modification. The only area 
where not is maybe when you use operation specific stuff directly. But thats 
why we have libobjc/Gnustep-base etc to abstract that for our applications, So 
I would be suprised if you run into any major issues.


> On 19 May 2019, at 09:22, Edwin Ancaer  wrote:
> 
>  Hello,
> 
> I've been searching for ports for GDL2 and GSWeb, but did not find them.
> 
> Can someone confirm they do not exist, or give the names of the ports 
> otherwise. I tried with gdl2, gsweb, gnustepweb.
> 
> If they don't exist, is this just because nobody has been interested? I ask 
> because there is not much reason in trying to port these applications  if 
> there are technical or other reasons that make it impossible  or very hard to 
> do.
> 
> Thanks,
> 
> Edwin Ancaer
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Andreas Fink
--
Fink Telecom Services, Paradieshofstrasse 101, 4054 Basel, Switzerland
E-Mail: andr...@fink.org https://www.fink.org
Mobile: +41-78-6677333
Skype: andreasfinkJabber/XMPP: andr...@fink.org ICQ: 8239353
--





___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

ARC & Autorelease pool question

[Andreas Fink]

Hello all

I am chasing a memory leak in my application and came to the conclusion that my 
code is not leaking anything but most probably is gnustep-base adding stuff to 
the autoreleasepool which never gets flushed. My understanding of ARC however 
was that the autorelease pool mechanism is kind of obsolete now as objects 
automatically get tossed when there's no reference of it. So a method returning 
an object will return a non released object. Thats why my code has nowhere any 
autorelease call. 

However if gnustep base still adds object for legacy reasons to the pool, I 
must flush it every once in a while. The problem I'm having is that I have 
massive multithreaded code and absolutely nothing happens in the main event 
loop except waiting for a shutdown signal.

My question is simple: What is the correct way to compile gnustep-base with ARC 
so it wont even use autorelease pools at all. Or is this not possible?

I now populated my code with massive amounts of @autorelease { ... } in the 
meantime but I consider this ugly.

Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: gnuconfig and runtime 1.9/ARC issue

[Andreas Fink]

you can also do

export RUNTIME_VERSION=2.0
before you configure/make/install gnustep-make & base and your code.

That overrides whats in libray-combo.make

I usually edit libray-combo.make before I make packages for it


> On 6 May 2019, at 10:14, Frederik Seiffert  wrote:
> 
> Hi Johannes,
> 
>> So somehow the runtime version is still written twice - once using the
>> wrong version (1.8)
> 
> I ran into the same issue and was able to fix it by providing a user config 
> file containing "RUNTIME_VERSION=gnustep-1.9" to GNUstep make using 
> --with-user-config-file=.
> 
> This is caused by library-combo.make always adding 1.8 if RUNTIME_VERSION is 
> unspecified using the ng runtime, which seems like something that should be 
> revisited (esp. now that newer runtime versions are recommended):
> https://github.com/gnustep/tools-make/blob/14a1d33/library-combo.make#L46-L48
> 
> Hope that helps!
> 
> Frederik
> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: runtime 2.0 issues. (Success!)

[Andreas Fink]

Thanks David,

I finally managed to get a proper compiled version under Debian 9 again. This 
was bugging me now for more than a month and I finally can check if I still see 
these memory leaks which I saw with libobjc2-1.8

Using clang-8, a patch to gnustep-make, some environment magic to take the 
right linker and compiler (not too new and not too old) finally did the trick!
There where multiple issues which reciprocally where affecting each other which 
meant whatever you tried, had to fail.

I will verify this now tomorrow on a freshly installed Debian again to be sure 
all is properly working and write down a nice documentation for others so they 
don't have to go through these pains.
I will also will build packages for it so installing gnustep-base (and gui for 
those who need it) will become a piece of cake.


> On 6 Mar 2019, at 17:15, David Chisnall  wrote:
> 
> On 06/03/2019 01:29, Andreas Fink wrote:
>> I just retried with clang-8 compiled from source.
>> Indeed this problem in ./configure of gnustep-base went away.
>> However all tests still fail.
>> its compiled this way during the test:
>> clang  -Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj 
>> -rdynamic -rdynamic -rdynamic  -rdynamic -pthread  -fexceptions 
>> -fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes  
>> ./obj/basictypes.obj/basictypes.m.o 
>> -L/Users/afink/development/gnustep2/base/Source/./obj 
>> -L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread 
>> -lobjc -lm
>> this produces a binary without an error but when running the binary, you 
>> simply get a segfault. and thats the case for all binaries created in the 
>> test.
>> Running it in lldb shows that it throws an exception which then while in the 
>> exception, it creates an exception which then creates a recursive infinite 
>> loop until the stack is filled up.
>> Its caused by this:
> 
> This looks like the issue that I already told you about with BFD ld failing 
> to correctly link -base Additions.  Did you link -base with Gold or LLD 
> (which work) or BFD ld (which doesn't)?
> 
> David



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: runtime 2.0 issues.

[Andreas Fink]

> On 6 Mar 2019, at 17:15, David Chisnall  wrote:
> 
> On 06/03/2019 01:29, Andreas Fink wrote:
>> I just retried with clang-8 compiled from source.
>> Indeed this problem in ./configure of gnustep-base went away.
>> However all tests still fail.
>> its compiled this way during the test:
>> clang  -Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj 
>> -rdynamic -rdynamic -rdynamic  -rdynamic -pthread  -fexceptions 
>> -fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes  
>> ./obj/basictypes.obj/basictypes.m.o 
>> -L/Users/afink/development/gnustep2/base/Source/./obj 
>> -L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread 
>> -lobjc -lm
>> this produces a binary without an error but when running the binary, you 
>> simply get a segfault. and thats the case for all binaries created in the 
>> test.
>> Running it in lldb shows that it throws an exception which then while in the 
>> exception, it creates an exception which then creates a recursive infinite 
>> loop until the stack is filled up.
>> Its caused by this:
> 
> This looks like the issue that I already told you about with BFD ld failing 
> to correctly link -base Additions.  Did you link -base with Gold or LLD 
> (which work) or BFD ld (which doesn't)?


Well linking with lld is not an option as its "too new" under clang-8 as I 
gathered from previous tests.
this was linked with standard linker of the system. Not sure how I change that 
easiest under ./configure of gnustep-base.
Or do you mean the linking at the time of libobjc2.so ? That one has  
CMAKE_LINKER=/usr/bin/ld (default)

and that's version:

# ld --version
GNU ld (GNU Binutils for Debian) 2.28
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: runtime 2.0 issues.

[Andreas Fink]

David, is your version of gnustep-base under FreeBSD using libffi or not? And 
if yes, is it version 3.2.1 or something newer?


> On 6 Mar 2019, at 01:27, David Chisnall  wrote:
> 
> On 05/03/2019 12:45, Andreas Fink wrote:
> 
>> Making all for tool cvtenc...
>>  Linking tool cvtenc ...
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined 
>> reference to `__start___objc_classes'
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined 
>> reference to `__stop___objc_classes'
> 
> As I have said before, this is a bug in clang 7.x  It is fixed in the 8.x 
> release branch and the fix is back-ported in the FreeBSD llvm70 package.  If 
> your favourite operating system's LLVM 7 package does not work, please ask 
> them to incorporate this fix:
> 
> https://svnweb.freebsd.org/ports/head/devel/llvm70/files/clang/patch-tools_clang_lib_CodeGen_CGObjCGNU.cpp?revision=489195=markup
> 
> This bug doesn't affect real code, but it will be a problem for any programs 
> that use Objective-C but don't contain any classes, which unfortunately 
> includes most of the GNUstep base configure scripts.
> 
> I have tested clang 8 on FreeBSD and am able to build all of the GNUstep 
> applications that I've tried (all of the ones in the FreeBSD ports 
> collection) with it without issues.  This version already contains the bug 
> fix.  It does cause a regression in one of the libobjc2 tests, which I'm 
> working on tracking down (it's triggered by a change to how LLVM does ARC 
> optimisation, but that's not actually the cause), but that particular pattern 
> is unlikely to occur in real code.
> 
> David
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: runtime 2.0 issues.

[Andreas Fink]

I just retried with clang-8 compiled from source.

Indeed this problem in ./configure of gnustep-base went away.

However all tests still fail.

its compiled this way during the test:

clang  -Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj -rdynamic 
-rdynamic -rdynamic  -rdynamic -pthread  -fexceptions 
-fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes  
./obj/basictypes.obj/basictypes.m.o 
-L/Users/afink/development/gnustep2/base/Source/./obj 
-L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread 
-lobjc -lm


this produces a binary without an error but when running the binary, you simply 
get a segfault. and thats the case for all binaries created in the test.

Running it in lldb shows that it throws an exception which then while in the 
exception, it creates an exception which then creates a recursive infinite loop 
until the stack is filled up.
Its caused by this:

#57168 0x0040b332 in main () at basictypes.m:161
161   NSAutoreleasePool *pool = [NSAutoreleasePool new];
(gdb) down
#57167 0x772b17c4 in objc_msgSend_fpret () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57166 0x772ad3c7 in slowMsgLookup () from /usr/local/lib/libobjc.so.4.6
(gdb) down
#57165 0x772a41c5 in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57164 0x772a438e in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57163 0x77913590 in +[NSObject initialize] (self=0x77d79b08 
<._OBJC_CLASS_NSObject>, _cmd=) at NSObject.m:1091
1091  NSConstantStringClass = [NSString constantStringClass];
(gdb) down
#57162 0x772b17c4 in objc_msgSend_fpret () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57161 0x772ad3c7 in slowMsgLookup () from /usr/local/lib/libobjc.so.4.6
(gdb) down
#57160 0x772a438e in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57159 0x7795372b in +[NSString initialize] (self=0x77d864f8 
<._OBJC_CLASS_NSString>, _cmd=) at NSString.m:827
827   nonBase = [NSCharacterSet nonBaseCharacterSet];

So where back in libobjc2 code 

> On 6 Mar 2019, at 01:27, David Chisnall  wrote:
> 
> On 05/03/2019 12:45, Andreas Fink wrote:
> 
>> Making all for tool cvtenc...
>>  Linking tool cvtenc ...
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined 
>> reference to `__start___objc_classes'
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined 
>> reference to `__stop___objc_classes'
> 
> As I have said before, this is a bug in clang 7.x  It is fixed in the 8.x 
> release branch and the fix is back-ported in the FreeBSD llvm70 package.  If 
> your favourite operating system's LLVM 7 package does not work, please ask 
> them to incorporate this fix:
> 
> https://svnweb.freebsd.org/ports/head/devel/llvm70/files/clang/patch-tools_clang_lib_CodeGen_CGObjCGNU.cpp?revision=489195=markup
> 
> This bug doesn't affect real code, but it will be a problem for any programs 
> that use Objective-C but don't contain any classes, which unfortunately 
> includes most of the GNUstep base configure scripts.
> 
> I have tested clang 8 on FreeBSD and am able to build all of the GNUstep 
> applications that I've tried (all of the ones in the FreeBSD ports 
> collection) with it without issues.  This version already contains the bug 
> fix.  It does cause a regression in one of the libobjc2 tests, which I'm 
> working on tracking down (it's triggered by a change to how LLVM does ARC 
> optimisation, but that's not actually the cause), but that particular pattern 
> is unlikely to occur in real code.
> 
> David
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: runtime 2.0 issues.

[Andreas Fink]

> On 6 Mar 2019, at 01:27, David Chisnall  wrote:
> 
> On 05/03/2019 12:45, Andreas Fink wrote:
> 
>> Making all for tool cvtenc...
>>  Linking tool cvtenc ...
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined 
>> reference to `__start___objc_classes'
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined 
>> reference to `__stop___objc_classes'
> 
> As I have said before, this is a bug in clang 7.x  It is fixed in the 8.x 
> release branch and the fix is back-ported in the FreeBSD llvm70 package.  If 
> your favourite operating system's LLVM 7 package does not work, please ask 
> them to incorporate this fix:
> 
> https://svnweb.freebsd.org/ports/head/devel/llvm70/files/clang/patch-tools_clang_lib_CodeGen_CGObjCGNU.cpp?revision=489195=markup

I actually have  clang7.1 from the source compiled right now and that problem 
is still there.
With clang8, some tests of libobjc2 fail. Clang7 was the only version of clang 
where this didn't happen.
I'll  integrate this patch and retest.

> 
> This bug doesn't affect real code, but it will be a problem for any programs 
> that use Objective-C but don't contain any classes, which unfortunately 
> includes most of the GNUstep base configure scripts.
> 
> I have tested clang 8 on FreeBSD and am able to build all of the GNUstep 
> applications that I've tried (all of the ones in the FreeBSD ports 
> collection) with it without issues.  This version already contains the bug 
> fix.  It does cause a regression in one of the libobjc2 tests, which I'm 
> working on tracking down (it's triggered by a change to how LLVM does ARC 
> optimisation, but that's not actually the cause), but that particular pattern 
> is unlikely to occur in real code.

Ok so testing clang8 from repo will be next...

> 
> David
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

runtime 2.0 issues.

[Andreas Fink]

Hello all,

I'm still trying to debug what breaks my install of the latest libobjc2 / 
gnustep-base install and found some interesting stuff while doing so.

So far it looks like libobjc2 compiles and installs properly (all tests pass) 
but then gnustep-base doesn't get compiled with the right option and they then 
lateron get into a mismatch.
Once thing I noticed is that gnustep-make applies  -fobjc-runtime=gnustep-1.8 
everyhwere while it should be -fobjc-runtime=gnustep-2.0 now. If I patch this, 
then however ./configure of gnustep-base starts believing all kinds of nonsense 
and tests fails en masse. Tests which are for sure wrong such as the 
runtime/compiler not supporting properties or exceptions etc.

So what I did is force patched out all these options temporarely in 
configure.ac. Namely I had to set the following vars:

BASE_NONFRAGILE_ABI=1
OBJCSYNC=1
OBJC2RUNTIME=1
HAVE_BLOCKS=1

 Now gnustep-base compiles and installs but when running its tests, all tests 
are failing. So I was looking a bit more in details of why all the test 
programs fail.

Here is such a test case and how it's compiled:

/usr/bin/clang-7  
-Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj -rdynamic 
-pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes 
./obj/basictypes.obj/basictypes.m.o 
-L/Users/afink/development/gnustep2/base/Source/./obj 
-L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread
/usr/bin/ld: ./obj/basictypes.obj/basictypes.m.o: undefined reference to symbol 
'__gnustep_objc_personality_v0'
//usr/local/lib/libobjc.so.4.6: error adding symbols: DSO missing from command 
line
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This symbol is actually present in libobjc2:

# nm /usr/local/lib/libobjc.so.4.6 | grep gnustep
0022d598 d DW.ref.__gnustep_objc_personality_v0
0001cac0 T __gnustep_objc_personality_v0
0001cad0 T __gnustep_objcxx_personality_v0
00023fe0 T _ZN7gnustep7libobjc19__objc_id_type_infoD0Ev
00023fd0 T _ZN7gnustep7libobjc19__objc_id_type_infoD1Ev
00023fd0 T _ZN7gnustep7libobjc19__objc_id_type_infoD2Ev
00023fb0 T _ZN7gnustep7libobjc22__objc_class_type_infoD0Ev
00023fa0 T _ZN7gnustep7libobjc22__objc_class_type_infoD1Ev
00023fa0 T _ZN7gnustep7libobjc22__objc_class_type_infoD2Ev
00024120 T 
_ZNK7gnustep7libobjc19__objc_id_type_info10__do_catchEPKSt9type_infoPPvj
00024000 T 
_ZNK7gnustep7libobjc22__objc_class_type_info10__do_catchEPKSt9type_infoPPvj
0022cb90 D _ZTIN7gnustep7libobjc19__objc_id_type_infoE
0022cbb0 D _ZTIN7gnustep7libobjc22__objc_class_type_infoE
00025b70 R _ZTSN7gnustep7libobjc19__objc_id_type_infoE
00025ba0 R _ZTSN7gnustep7libobjc22__objc_class_type_infoE
0022cbc8 D _ZTVN7gnustep7libobjc19__objc_id_type_infoE
0022cc08 D _ZTVN7gnustep7libobjc22__objc_class_type_infoE

but there is no -lobjc in the command line at the end. Adding an  -lobjc  at 
the end of the command line seems to fix this.
it seems to be gnustep-base's configure is at fault here. gnustep-configure 
does in fact report including libobjc but gnustep-base doesnt care about that 
when doing the tests.

$ gnustep-config --objc-libs
-rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks 
-L/root/GNUstep/Library/Libraries -L/usr/local/lib -lpthread -lobjc -lm


The compilation of the gnustep-base tools also fail:

..
...

Making all for tool cvtenc...
 Linking tool cvtenc ...
./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined 
reference to `__start___objc_classes'
./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined 
reference to `__stop___objc_classes'

This seems to be the issue referenced in this bugreport:  
https://savannah.gnu.org/bugs/?53338


if I run these test with different runtime versions, I see failures here:

# clang-7 config/config.non-fragile-ivars.m
# clang-7 -fobjc-runtime=gnustep-1.8config/config.non-fragile-ivars.m
# clang-7 -fobjc-runtime=gnustep-1.9config/config.non-fragile-ivars.m
# clang-7 -fobjc-runtime=gnustep-1.9.9 config/config.non-fragile-ivars.m
# clang-7 -fobjc-runtime=gnustep-2.0config/config.non-fragile-ivars.m
/tmp/config-35c9d0.o: In function `.objcv2_load_function':
config.non-fragile-ivars.m:(.text..objcv2_load_function[.objcv2_load_function]+0xc):
 undefined reference to `__objc_load'
/tmp/config-35c9d0.o:(.data..objc_init[.objc_init]+0x18): undefined reference 
to `__start___objc_classes'
/tmp/config-35c9d0.o:(.data..objc_init[.objc_init]+0x20): undefined reference 
to `__stop___objc_classes'
/usr/bin/ld: a.out: hidden symbol `__stop___objc_classes' isn't defined
/usr/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)

So now the question is, is the compiler "too old" to properly recognize 
-fobjc-runtime=gnustep-2.0  or is 

Re: clang versions for libobjc2

[Andreas Fink]

and the lld linker can not be use to compile libobjc2 and gnustep-base neither. 
So we are in deep water here.

> On 19 Feb 2019, at 21:11, David Chisnall  wrote:
> 
> On 19 Feb 2019, at 18:55, Andreas Fink  wrote:
>> 
>> There is definitively some nonsense  happening when library A has an object 
>> wich librarby B is subclassing and App usese library B and sets a property 
>> of the superclass library A.
> 
> This is a known issue with the pre-2.0 ABI on Linux and was one of the 
> motivations for the new ABI.  It began to appear with fairly recent 
> ld-linux.so and has become deterministic with subsequent releases.  You will 
> see this on *any* libobjc2 release with *any* version of clang on *any* 
> system that uses glibc’s run-time linker.  
> 
> I don’t know if it appears on Android with the bionic run-time linker, it 
> does not appear on any other platform that I’ve tested.
> 
> David
> 



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: clang versions for libobjc2

[Andreas Fink]

Hello all.

After fiddling around with about every variant of compiler and library and 
flags under Debian 9 I can imagine, the conclusion is that libobjc2-1.9 is 
definitively broken under Debian.
When I switch back to 1.8.1 and the latest gnustep release from the webpage 
things become stable again. I also noticed the source I am pulling is from 
github and the webpage talks about another source (I think savanna. gnu or the 
like). I'm not sure if the documentation is not up to date or the github is 
just a mirror.

clang-7 is the only compiler version which can pass all tests (except a few 
around NSDate in gnustep-base which are not really that ).
There is definitively some nonsense  happening when library A has an object 
wich librarby B is subclassing and App usese library B and sets a property of 
the superclass library A. When you step through it in the debugger you can see 
an assigmen't of an interger overwriting a pointer of another object. Or a 
reading of a property returning a object of the wrong type. All kind of madness 
can result out of this. Note. The assignment was done over a setter method, 
self.varname = ... and not via direct access ( _varname =...).

This happens reproduceably in my case after creating the first object and about 
10 lines of code in my Init method, it will call a method which this object is 
supposed to have but because another object is returned, an exception is thrown.

I can't really say if clang is at fault, or the linker or libobjc2's code.  In 
my case, the lld linker didn'tt help. All stuff was linked with the system 
supplied linker and that tended to work stable. Attempts to link with lld-7 
turned out with all kinds of other errors. Fact is, the pointer to data inside 
an object is becoming wrong. I tried to change the order to see if it can be 
solved by laying out the fields in a way an optimizer would not touch it but 
that didnt work neither.

I tried to extract a simple test case but that failed as it was linking 
everything together into a binary and not into individual shared libraries 
first.


I have to say that the setup using gnustep-make is very problematic for me. 
It's kind of impossible to figure out what kind of compiler options are being 
set and to verify if it does build everything as it should.  Things are spread 
over several make files in several directories, some config files, some 
environmental variables. The output nicely tells you how many % is left but you 
can't see what it compiles how if you need to verify if a parameter is passed 
along correctly. At least I have not found any way.  I would like to suggest to 
rethink a bit how gnustep is built and I'm happy  in contributing to that part.

An option to cross compiling from Xcode would be nice to have (given it has a 
stable clang which is well maintained for  objc) but building natively on any 
Unix platform is a must. Cocotron (which I used before) used to cross compile 
from the Mac but had no unix native implementation and it was stuck to gcc 
which lacks all the new objc features. Thats why I started using gnustep.

In my own code I use configure and Xcode in parallel.   cmake turns out to be 
nice too but on the other hand it also hides a lot of abstraction so you end up 
with not knowing what the system really does and if such problems as I had thie 
last weeks hit again, you will basically be lost. There's lots of variables 
which can be set with cmake but every project has its owns and its not really 
well documented.

What are you all using to compile your ObjC projects?



> On 19 Feb 2019, at 10:08, Andreas Fink  wrote:
> 
> 
> clang-9
> The following tests FAILED:
>18 - AssociatedObject_optimised (OTHER_FAULT)
>20 - AssociatedObject_legacy_optimised (OTHER_FAULT)
>
> clang-8
> The following tests FAILED:
>18 - AssociatedObject_optimised (OTHER_FAULT)
>20 - AssociatedObject_legacy_optimised (OTHER_FAULT)
>
> clang-7
>   all tests pass
>   
> clang-6.0
> The following tests FAILED:
>57 - PropertyAttributeTest (OTHER_FAULT)
>58 - PropertyAttributeTest_optimised (OTHER_FAULT)
>59 - PropertyAttributeTest_legacy (OTHER_FAULT)
>60 - PropertyAttributeTest_legacy_optimised (OTHER_FAULT)
>61 - ProtocolExtendedProperties (OTHER_FAULT)
>62 - ProtocolExtendedProperties_optimised (OTHER_FAULT)
>78 - ResurrectInDealloc_arc_optimised (SEGFAULT)
>80 - ResurrectInDealloc_arc_legacy_optimised (SEGFAULT)
>   149 - category_properties (OTHER_FAULT)
>   150 - category_properties_optimised (OTHER_FAULT)
>   
>  clang-5.0.1
>  The following tests FAILED:
>57 - PropertyAttributeTest (OTHER_FAULT)
>58 - PropertyAttributeTest_optimised (OTHER_FAULT)
>59 - PropertyAttributeTest_legacy (OTHER_FAULT)
>60 - PropertyAttrib

clang versions for libobjc2

[Andreas Fink]

clang-9
The following tests FAILED:
 18 - AssociatedObject_optimised (OTHER_FAULT)
 20 - AssociatedObject_legacy_optimised (OTHER_FAULT)
 
clang-8
The following tests FAILED:
 18 - AssociatedObject_optimised (OTHER_FAULT)
 20 - AssociatedObject_legacy_optimised (OTHER_FAULT)
 
clang-7
all tests pass

clang-6.0
The following tests FAILED:
 57 - PropertyAttributeTest (OTHER_FAULT)
 58 - PropertyAttributeTest_optimised (OTHER_FAULT)
 59 - PropertyAttributeTest_legacy (OTHER_FAULT)
 60 - PropertyAttributeTest_legacy_optimised (OTHER_FAULT)
 61 - ProtocolExtendedProperties (OTHER_FAULT)
 62 - ProtocolExtendedProperties_optimised (OTHER_FAULT)
 78 - ResurrectInDealloc_arc_optimised (SEGFAULT)
 80 - ResurrectInDealloc_arc_legacy_optimised (SEGFAULT)
149 - category_properties (OTHER_FAULT)
150 - category_properties_optimised (OTHER_FAULT)

 clang-5.0.1
 The following tests FAILED:
 57 - PropertyAttributeTest (OTHER_FAULT)
 58 - PropertyAttributeTest_optimised (OTHER_FAULT)
 59 - PropertyAttributeTest_legacy (OTHER_FAULT)
 60 - PropertyAttributeTest_legacy_optimised (OTHER_FAULT)
 61 - ProtocolExtendedProperties (OTHER_FAULT)
 62 - ProtocolExtendedProperties_optimised (OTHER_FAULT)
 78 - ResurrectInDealloc_arc_optimised (SEGFAULT)
 80 - ResurrectInDealloc_arc_legacy_optimised (SEGFAULT)
149 - category_properties (OTHER_FAULT)
150 - category_properties_optimised (OTHER_FAULT)

clang-4.0.1
The following tests FAILED:
 57 - PropertyAttributeTest (OTHER_FAULT)
 58 - PropertyAttributeTest_optimised (OTHER_FAULT)
 59 - PropertyAttributeTest_legacy (OTHER_FAULT)
 60 - PropertyAttributeTest_legacy_optimised (OTHER_FAULT)
 61 - ProtocolExtendedProperties (OTHER_FAULT)
 62 - ProtocolExtendedProperties_optimised (OTHER_FAULT)
149 - category_properties (OTHER_FAULT)
150 - category_properties_optimised (OTHER_FAULT)

clang-3.8:
[ 23%] Building C object 
Test/CMakeFiles/category_properties_optimised.dir/category_properties.m.o
/Users/afink/development/gnustep/libobjc2/Test/category_properties.m:7:12: 
error: unknown property attribute 'class'
@property (class, readonly) int val2;
   ^





___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: libobjc2/gnustep-base also failing under FreeBSD + Debian9

[Andreas Fink]

the cases now gets totally overboard...

I have one root class UMObject which does in some cases (debug options) set up 
a c pointer to the class type's name (this to work around lldb not being able 
to display stuff at times).

Anyhow, today I traced a situation down when the app starts up, initializes my 
first class, which initializes its superclass which initializes my UMObject 
root object (which then calls self = [super init] first which calls NSObject 
init. All good. then it sets up a variable containing flags if certain options 
are on or not. So every object has a i32bit integer first with the flags.

What I saw was that the flags where stored somewhere else in my structure. At 
the place I have a pointer to another object.
So I juggled around the order to see if this can fix the issue by tricking away 
the optimizer which might reorder things.

And then things got totally nuts

It always breaks somewhere but then a bit later in my code where it assigns the 
logging object. And the odd thing is I saw my object having  property  A, B, C 
and I changed it to B , XA, XC (renamed some) and in the debugger when doing 
print *self it shows me A, B, C when in the super class and B, XA,XC in the 
root class.

So obviously different parts of the compiler see the objects differently at 
differnet times and then hell breaks loose. 


Here is an example.:

This is my root object

#define UMOBJECT_USE_MAGIC  1
#define UMOBJECT_FLAG_HAS_MAGIC 0x01
#define UMOBJECT_FLAG_LOG_RETAIN_RELEASE0x02
#define UMOBJECT_FLAG_IS_COPIED 0x04
#define UMOBJECT_FLAG_IS_INITIALIZED0xCC00
#define UMOBJECT_FLAG_IS_RELEASED   0x3300

@interface UMObject : NSObject
{
uint32_t_umobject_flags; /*!< internal flags to remember which options 
this object has */
UMLogFeed   *_logFeed;
int _ulib_retain_counter;
char*_magic;
NSString *_xobjectStatisticsName;
}
@end



and this is my current implementation


- (UMObject *) init
{
self=[super init];
if(self)
{
#ifdef UMOBJECT_USE_MAGIC
{
const char *str = [[self class] description].UTF8String;
size_t len = strlen(str)+1;
//_magic = calloc(1,len); /* commented out to see if that helps */
if(_magic)
{
strncpy(_magic, str, len);
_umobject_flags  |= UMOBJECT_FLAG_HAS_MAGIC;
}
}
#endif
if(alloc_file)
{
{
NSString *s = [NSString stringWithFormat:@"+%@\n",[self 
objectStatisticsName]];
NSData *d = [s dataUsingEncoding:NSUTF8StringEncoding];
@synchronized(alloc_file)
{
[alloc_file writeData:d];
}
}
}
   /* DEBUG to the console to see what is happening */
printf("self = %p\n",self);
printf("_umbobject_flags pos = %p\n",&_umobject_flags);
printf("_logFeed pos = %p\n",&_logFeed);
_umobject_flags  |= UMOBJECT_FLAG_IS_INITIALIZED;
printf("_umbobject_flags pos = %p\n",&_umobject_flags);
printf("_self = %p\n",self);

}
return self;
}



and here is what the debugger says:


[root@gnustep-clang7 gitlab]# lldb-6.0 /usr/local/sbin/cnam-server
(lldb) target create "/usr/local/sbin/cnam-server"
Current executable set to '/usr/local/sbin/cnam-server' (x86_64).
(lldb) break set
error: invalid combination of options for the given command
(lldb) run
Process 25406 launched: '/usr/local/sbin/cnam-server' (x86_64)
self = 0x1de5318
_umbobject_flags pos = 0x1de5320   *** THEY ARE THE SAME ?!?!?!?
_logFeed pos = 0x1de5320  
_umbobject_flags pos = 0x1de5320
_self = 0x1de5318
self = 0x1e4dfe8
_umbobject_flags pos = 0x1e4dff0
_logFeed pos = 0x1e4dff0
_umbobject_flags pos = 0x1e4dff0
_self = 0x1e4dfe8
self = 0x1e57648
_umbobject_flags pos = 0x1e57650
_logFeed pos = 0x1e57650
_umbobject_flags pos = 0x1e57650
_self = 0x1e57648
Process 25406 stopped
* thread #1, name = 'cnam-server', stop reason = signal SIGSEGV: invalid 
address (fault address: 0xcc00)
frame #0: 0x77318dd6 libobjc.so.4.6`objc_release + 22
libobjc.so.4.6`objc_release:
->  0x77318dd6 <+22>: movq   (%rbx), %rcx
0x77318dd9 <+25>: movq   0x20(%rcx), %rax
0x77318ddd <+29>: testl  $0x4000, %eax ; imm = 0x4000
0x77318de2 <+34>: jne0x77318e5b; <+155>
(lldb) print self
error: use of undeclared identifier 'self'
(lldb) up
frame #1: 0x77789bf4 libulib.so.1.9`-[UMObject 
setLogFeed:](self=0x01de5318, _cmd=">\e", logFeed=0x01e5b938) 
at UMObject.h:64
   61   NSString *_xobjectStatisticsName;
   62   }
   63
-> 64   @property (readwrite,strong,atomic) UMLogFeed *logFeed;
   65   @property (readwrite,assign,atomic) int ulib_retain_counter;
   66
   67   - (UMObject *) init;

it obvioulsy wants to release something which has never been 

Re: libobjc2/gnustep-base also failing under FreeBSD + Debian9

[Andreas Fink]

Under Debian9, it is impossible to get anything properly working. It seems to 
be that the linker, the compiler and libobjc2 are constantly at war with each 
other. There is no valid combination of either of them.


The combination which got me the furthest is the one which uses clang-7 and the 
standard linker. 
This passes libobjc2 checks and gnustep-base checks.  However once you get to 
your own apps, weird things will happen.

in my case I set up  my AppDelegate object from main with init which in turn 
has a  property called _runningConfig which then gets accessed like this

- (MyAppDelegate *)initWithOptions:(NSDictionary *)options
{
self = [super init];
if(self)
{
/* do set up some vars */
   if(_runningConfig.generalConfig.concurrentTasks!=NULL) /* IT THROWS 
EXCEPTION HERE */
{
/* read some property and do something */


I just noticed that at this point in my code _runningConfig is actually NULL 
because the command line parsing is done  a bit later.
But the exception I get is rather puzzling:.

: Uncaught exception NSInvalidArgumentException, reason: UMLogHandler(instance) 
does not recognize generalConfig

how can a variable being NULL raise this exception?
and _runningConfig  its not of object type UMLogHandler  neither!

So obviously clang is messing up with the property offsets here. But all code 
have been compiled with the same compiler from A-Z !!

It also behaves like this with -O0 compiled superclass and App.

If I fix this and use self.runningConfig instead of _runningConfig, then that 
passes. However it then breaks at some other place with similar puzzling errors.

Above was compiled with  -fobjc-runtime=gnustep-1.8  as gnustep-configure 
reports by default .

This is driving me nuts since more than a month now.
If anyone can solve this mystery, I'm more than happy to pay him.


> On 12 Feb 2019, at 14:43, David Chisnall  wrote:
> 
> On 11/02/2019 16:10, Jordan Schidlowsky wrote:
>> I get these same linker errors when I link for android using a newish lld... 
>>  If you use any other linker these linker errors will go away ( gold or ld 
>> do not have these errors).
> 
> I'd be quite worried if they went away.  The linker is reporting that the 
> compiler generated incorrect code[1].  I saw the same errors with BFD ld.  If 
> you have a linker that is linking it without errors, I wonder what it's 
> actually putting in the binary...
> 
> David
> 
> [1] If anyone cases: someone from Apple decided to make block descriptors 
> public symbols with mangled names, rather than internal symbols.  This is a 
> win most of the time, because it lets the linker deduplicate them, but 
> unfortunately they put the Objective-C type encoding in the name.  On ELF 
> platforms, @ is the separator between the symbol name and the symbol version, 
> so block descriptors ended up appearing as versioned symbols.  This is now 
> fixed in clang, to replace the @ character with something else ('\1', I 
> think).

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: libobjc2/gnustep-base also failing under FreeBSD

[Andreas Fink]

From reading the scrip gnustep-config

 /usr/local/GNUstep/System/Tools/gnustep-config --objc-libs


does call

 gmake --no-print-directory -s -f "$GNUSTEP_MAKEFILES/empty.make" 
print-gnustep-make-objc-flags quiet=yes 2>/dev/null


and on my freshly installed system, there's no gmake. Only make. Thats why the 
output is empty.
after 

 pkg install gmake

I get output:

/usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
-rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
-fobjc-runtime=gnustep-1.8 -fblocks -L/root/GNUstep/Library/Libraries 
-L/usr/local/GNUstep/Local/Library/Libraries 
-L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
-fobjc-nonfragile-abi -lm

which is wrong. gnustep-1.8 instead of gnustep-2.0.

So we are back to square one.

Also gnustep-make should  have a dependency to gmake (or work happily with make)
 


> On 11 Feb 2019, at 19:59, David Wetzel  wrote:
> 
> I just build it after upgrading ports. 
> 
> dave@apu>/usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
> 
> -rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
> -fobjc-runtime=gnustep-1.8 -fblocks -L/home/dave/GNUstep/Library/Libraries 
> -L/usr/local/GNUstep/Local/Library/Libraries 
> -L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
> -fobjc-nonfragile-abi -lm
> 
> dave@apu>/usr/local/GNUstep/System/Tools/gnustep-config --objc-flags
> 
> -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
> -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing 
> -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall 
> -DGSWARN -DGSDIAGNOSE -Wno-import -O2 -pipe -fstack-protector 
> -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing 
> -Wno-import -I/usr/local/include -fobjc-runtime=gnustep-1.8 -fblocks 
> -fconstant-string-class=NSConstantString -I. 
> -I/home/dave/GNUstep/Library/Headers 
> -I/usr/local/GNUstep/Local/Library/Headers 
> -I/usr/local/GNUstep/System/Library/Headers -I/usr/local/include
> 
> dave@apu>pkg info |grep -i gnustep
> 
> gnustep-base-1.26.0_1  GNUstep Foundation library
> 
> gnustep-make-2.7.0_3   GNUstep makefile package
> 
> dave@apu>uname -v
> 
> FreeBSD 11.2-RELEASE-p8 #0: Tue Jan  8 21:35:12 UTC 2019 
> r...@amd64-builder.daemonology.net 
> <mailto:r...@amd64-builder.daemonology.net>:/usr/obj/usr/src/sys/GENERIC 
> 
> 
> 
> Von meinem iPhone gesendet
> 
> Am 11.02.2019 um 13:49 schrieb Andreas Fink  <mailto:af...@list.fink.org>>:
> 
>> I reinstalled a fresh new FreeBSD VM and did install the package 
>> gnustep-base again.
>> 
>> Now  /usr/local/GNUstep/System/Tools/gnustep-config returns absolutely 
>> nothing:
>> 
>> $  /usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
>> $  /usr/local/GNUstep/System/Tools/gnustep-config --objc-flags
>> 
>> WTF. Like every time I try to use gnustep on any system there is some magic 
>> thing happening  which screws up my builds. I've now tried on 6 
>> different OS versions/build environments. I think the gnustep-make / build 
>> environment is so delicate that it's time to rethink it seriously. Otherwise 
>> Gnustep can never become mainstream.
>> 
>> It's a mystic combination of compiler version, linker, 
>> environment-variables,  gnustep-make config files. This is a recipe for 
>> failure.
>> 
>> And I'm only talking about gnustep-base/libobjc2 , not  even gui or anymore 
>> difficult dependencies. Just really basic stuff.
>> 
>> 
>> 
>> 
>> 
>>> On 11 Feb 2019, at 17:07, David Chisnall >> <mailto:gnus...@theravensnest.org>> wrote:
>>> 
>>> On 11/02/2019 15:56, Andreas Fink wrote:
>>>> [root@freebsd /etc]# /usr/local/GNUstep/System/Tools/gnustep-config 
>>>> --objc-libs
>>>> -rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
>>>> -fobjc-runtime=gnustep-1.8 -fblocks -L/root/GNUstep/Library/Libraries 
>>>> -L/usr/local/GNUstep/Local/Library/Libraries 
>>>> -L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
>>>> -fobjc-nonfragile-abi -lm
>>> 
>>> You probably still have some stuff in /etc or /usr/local/etc from your 
>>> previous gnustep-make install that it's picking up (e.g. a GNUstep.conf?).
>>> 
>>> David
>> 
>> Andreas Fink
>> --
>> Fink Telecom Services, Paradieshofstrasse 101, 4054 Basel, Switzerland
>> E-Mail: andr...@fink.org <mailto:andr

Re: libobjc2/gnustep-base also failing under FreeBSD

[Andreas Fink]

I reinstalled a fresh new FreeBSD VM and did install the package gnustep-base 
again.

Now  /usr/local/GNUstep/System/Tools/gnustep-config returns absolutely nothing:

$  /usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
$  /usr/local/GNUstep/System/Tools/gnustep-config --objc-flags

WTF. Like every time I try to use gnustep on any system there is some magic 
thing happening  which screws up my builds. I've now tried on 6 
different OS versions/build environments. I think the gnustep-make / build 
environment is so delicate that it's time to rethink it seriously. Otherwise 
Gnustep can never become mainstream.

It's a mystic combination of compiler version, linker, environment-variables,  
gnustep-make config files. This is a recipe for failure.

And I'm only talking about gnustep-base/libobjc2 , not  even gui or anymore 
difficult dependencies. Just really basic stuff.





> On 11 Feb 2019, at 17:07, David Chisnall  wrote:
> 
> On 11/02/2019 15:56, Andreas Fink wrote:
>> [root@freebsd /etc]# /usr/local/GNUstep/System/Tools/gnustep-config 
>> --objc-libs
>> -rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
>> -fobjc-runtime=gnustep-1.8 -fblocks -L/root/GNUstep/Library/Libraries 
>> -L/usr/local/GNUstep/Local/Library/Libraries 
>> -L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
>> -fobjc-nonfragile-abi -lm
> 
> You probably still have some stuff in /etc or /usr/local/etc from your 
> previous gnustep-make install that it's picking up (e.g. a GNUstep.conf?).
> 
> David

Andreas Fink
--
Fink Telecom Services, Paradieshofstrasse 101, 4054 Basel, Switzerland
E-Mail: andr...@fink.org https://www.fink.org
Mobile: +41-78-6677333
Skype: andreasfinkJabber/XMPP: andr...@fink.org ICQ: 8239353
--





___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: libobjc2/gnustep-base also failing under FreeBSD

[Andreas Fink]

Something is still wrong.
It gives me

-fobjc-runtime=gnustep-1.8

instead of

-fobjc-runtime=gnustep-2.0




[root@freebsd /]# pkg install gnustep-base
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
gnustep-base: 1.26.0_1
libobjc2: 2.0
gnustep-make: 2.7.0_3

Number of packages to be installed: 3

The process will require 15 MiB more space.

Proceed with this action? [y/N]: y
[1/3] Installing libobjc2-2.0...
[1/3] Extracting libobjc2-2.0: 100%
[2/3] Installing gnustep-make-2.7.0_3...
[2/3] Extracting gnustep-make-2.7.0_3: 100%
[3/3] Installing gnustep-base-1.26.0_1...
[3/3] Extracting gnustep-base-1.26.0_1: 100%
[root@freebsd /etc]# gnustep-config
bash: /usr/local/bin/gnustep-config: No such file or directory
[root@freebsd /etc]# gnustep-config
bash: /usr/local/bin/gnustep-config: No such file or directory
[root@freebsd /etc]#
[root@freebsd /etc]# /usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
-rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
-fobjc-runtime=gnustep-1.8 -fblocks -L/root/GNUstep/Library/Libraries 
-L/usr/local/GNUstep/Local/Library/Libraries 
-L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
-fobjc-nonfragile-abi -lm
[root@freebsd /etc]# rm -rf -L/root/GNUstep/Library/Libraries
rm: illegal option -- L
usage: rm [-f | -i] [-dIPRrvWx] file ...
   unlink [--] file
[root@freebsd /]# rm -rf /root/GNUstep
[root@freebsd /]# /usr/local/GNUstep/System/Tools/gnustep-config --objc-libs
-rdynamic -L/usr/local/lib -fstack-protector -pthread -fexceptions 
-fobjc-runtime=gnustep-1.8 -fblocks -L/root/GNUstep/Library/Libraries 
-L/usr/local/GNUstep/Local/Library/Libraries 
-L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib -lobjc 
-fobjc-nonfragile-abi -lm
[root@freebsd /]#


> On 11 Feb 2019, at 16:40, David Chisnall  wrote:
> 
> On 11/02/2019 15:03, Andreas Fink wrote:
>> root@freebsd:/usr/Users/afink/gnustep/base # pkg update
>> Updating FreeBSD repository catalogue...
> 
> Please check that you are using the latest package repo and not the quarterly 
> branch.
> 
> David



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: libobjc2/gnustep-base also failing under FreeBSD

[Andreas Fink]

> On 11 Feb 2019, at 15:58, David Chisnall  wrote:
> 
> On 11/02/2019 11:10, Andreas Fink wrote:
>> Hello David,
>> Given you develop mainly on Freebsd, I tried to see if I can get a stable 
>> instance of libobjc2 and gnustep-base by switching to FreeBSD.
>> but I still run into linker issues. This is how I did it
> 
> This is how I did it:
> 
> # pkg ins gnustep
> 


That gives old stuff:

root@freebsd:/usr/Users/afink/gnustep/base # pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
root@freebsd:/usr/Users/afink/gnustep/base # pkg search libobjc
libobjc2-1.8.1_2   Replacement Objective-C runtime supporting 
modern Objective-C features
root@freebsd:/usr/Users/afink/gnustep/base # pkg search lgnustep
root@freebsd:/usr/Users/afink/gnustep/base # pkg search gnustep
gnustep-1.28.0_5   Objective-C libraries based on the OpenStep 
standard
gnustep-back-0.25.1_2  GNUstep GUI backend
gnustep-base-1.25.0_7  GNUstep Foundation library
gnustep-cdplayer-0.5.1_7   GNUstep CD player with CDDB support
gnustep-examples-1.4.0_7   GNUstep example applications
gnustep-ftp-0.5_5  Compact and handy FTP client for GNUstep
gnustep-gui-0.25.1_7   GNUstep GUI library
gnustep-ladder-1.0_8   GNU Go frontend for GNUstep
gnustep-make-2.7.0_2   GNUstep makefile package
gnustep-preview-0.8.5_9Simple image viewer
gnustep-sudoku-0.7_6   Sudoku solver and generator
gnustep-wrapper-0.1.0_8Create GNUstep app-wrappers of non-GNUstep 
applications
root@freebsd:/usr/Users/afink/gnustep/base #


> 
>> 1. freshly installed VM with FeeBSD 12.0
>> --
>> Installed from Disk image:
>> https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-dvd1.iso
>> 2. Add Depenencies and switch to bash shell
>> ---
>> pkg install git \
>> autoconf \
>> automake \
>> cmake \
>> subversion  \
>> clang-devel-8.d20181024 \
>> wget \
>> bash \
>> pkgconf \
>> sudo \
>> gmake \
>> windowmaker \
>> jpeg \
>> tiff \
>> png \
>> libxml2 \
>> libxslt \
>> gnutls \
>> libffi \
>> icu \
>> cairo \
>> avahi \
>> portaudio \
>> flite \
>> pngwriter
> 
> These look a bit like sensible dependencies.  You can also just do 'pkg ins 
> gnustep-base ; pkg del gnustep-base' to get all of the dependencies for 
> gnustep-base.
> 
>> bash
>> 3. Download the sourcecode of gnustep
>> ---
>> mkdir gnustep
>> cd gnustep
>> wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.15.tar.gz   # 
>> FreeBSD only comes with libiconv-1.14 which has a bug we run into earlier
>> # git clone https://github.com/apple/swift-corelibs-libdispatch # <-- 
>> this doesnt compile under FreeBSD yet. TODO for later.
>> git clone https://github.com/gnustep/scripts
>> git clone https://github.com/gnustep/make
>> git clone https://github.com/gnustep/libobjc2
>> git clone https://github.com/gnustep/base
>> git clone https://github.com/gnustep/corebase
>> git clone https://github.com/gnustep/gui
>> git clone https://github.com/gnustep/back
>> # ./scripts/install-dependencies  <- this doesn't work for freeBSD but 
>> the dependencies above fix that which is based on the openbsd version
>> tar -xvzf libiconv-1.15.tar.gz
>> cd libiconv-1.15
>> ./configure --enable-static --enable-dynamic
>> make
>> make install
>> cd ..
> 
> 
> Not sure why you're manually compiling iconv.  On FreeBSD, this should be 
> part of the base system, so some random third-party version may or may not 
> work.
> 
>> 4. Setting some defaults
>> 
>> export CC="clang-devel"
>> export CXX="clang++-devel"
> 
> I have no idea when the llvm-devel port was last updated, so I'm not sure 
> what this corresponds to.  The GNUstep packages are all built using the 
> llvm70 package, so I'd recommend you install that and use clang70 / clang++70.
> 
>> export 
>> PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin"
>> export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"
>> export LDFLAGS="-fuse-ld=lld-devel"
> 
> I don't know if setting LDFLAGS as an environment variable does anything.
> 
>> 5. install libobjc2 runtime
>> cd lib

libobjc2/gnustep-base also failing under FreeBSD

[Andreas Fink]

Hello David,

Given you develop mainly on Freebsd, I tried to see if I can get a stable 
instance of libobjc2 and gnustep-base by switching to FreeBSD.

but I still run into linker issues. This is how I did it


1. freshly installed VM with FeeBSD 12.0
--

Installed from Disk image:

https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-amd64-dvd1.iso
 



2. Add Depenencies and switch to bash shell
---

pkg install git \
autoconf \
automake \
cmake \
subversion  \
clang-devel-8.d20181024 \
wget \
bash \
pkgconf \
sudo \
gmake \
windowmaker \
jpeg \
tiff \
png \
libxml2 \
libxslt \
gnutls \
libffi \
icu \
cairo \
avahi \
portaudio \
flite \
pngwriter

bash




3. Download the sourcecode of gnustep
---

mkdir gnustep
cd gnustep
wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.15.tar.gz 
   # FreeBSD only 
comes with libiconv-1.14 which has a bug we run into earlier
# git clone https://github.com/apple/swift-corelibs-libdispatch 
 # <-- this doesnt compile 
under FreeBSD yet. TODO for later.
git clone https://github.com/gnustep/scripts
git clone https://github.com/gnustep/make
git clone https://github.com/gnustep/libobjc2 
git clone https://github.com/gnustep/base
git clone https://github.com/gnustep/corebase
git clone https://github.com/gnustep/gui
git clone https://github.com/gnustep/back
# ./scripts/install-dependencies  <- this doesn't work for freeBSD but the 
dependencies above fix that which is based on the openbsd version


tar -xvzf libiconv-1.15.tar.gz
cd libiconv-1.15
./configure --enable-static --enable-dynamic
make
make install
cd ..


4. Setting some defaults


export CC="clang-devel"
export CXX="clang++-devel"
export 
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin"
export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"
export LDFLAGS="-fuse-ld=lld-devel"


5. install libobjc2 runtime

cd libobjc2
mkdir Build
cd Build
cmake ..  -DCMAKE_BUILD_TYPE=Release -DBUILD_STATIC_LIBOBJC=1  
-DCMAKE_C_COMPILER=${CC} -DCMAKE_CXX_COMPILER=${CXX}
make -j8
make install
cd ..
ldconfig



6. install gnustep-make

./configure \
--with-layout=fhs \
--disable-importing-config-file \
--enable-native-objc-exceptions \
--enable-objc-arc \
--enable-install-ld-so-conf \
--with-library-combo=ng-gnu-gnu \
--with-config-file=/etc/GNUstep/GNUstep.conf \
--with-user-config-file='.GNUstep.conf' \
--with-user-defaults-dir='GNUstep/Library/Defaults' \
gmake
gmake install
source /etc/GNUstep/GNUstep.conf
cd ..
 


the output is this:


...
 compiling file NSUUID.m ...
 Compiling file NSValue.m ...
 Compiling file NSValueTransformer.m ...
 Compiling file NSXMLDocument.m ...
 Compiling file NSXMLDTD.m ...
 Compiling file NSXMLDTDNode.m ...
 Compiling file NSXMLElement.m ...
 Compiling file NSXMLNode.m ...
 Compiling file NSXMLParser.m ...
 Compiling file NSZone.m ...
 Compiling file externs.m ...
 Compiling file objc-load.m ...
 Compiling file GSFileHandle.m ...
 Compiling file NSMessagePort.m ...
 Compiling file NSMessagePortNameServer.m ...
 Compiling file NSNetServices.m ...
 Compiling file GSAvahiNetService.m ...
 Compiling file GSAvahiNetServiceBrowser.m ...
 Compiling file GSAvahiClient.m ...
 Compiling file GSAvahiRunLoopIntegration.m ...
 Compiling file GSFFIInvocation.m ...
 Linking library libgnustep-base ...
ld.lld: error: obj/libgnustep-base.obj/NSRegularExpression.m.o: symbol 
__block_descriptor_40_e8_32o_e15_v32@?0@8Q16^C24l has undefined version 
?0@8Q16^C24l
ld.lld: error: obj/libgnustep-base.obj/NSRegularExpression.m.o: symbol 
__block_descriptor_40_e8_32r_e15_v32@?0@8Q16^C24l has undefined version 
?0@8Q16^C24l
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)
gmake[4]: *** [/usr/local/share/GNUstep/Makefiles/Instance/library.make:293: 
obj/libgnustep-base.so.1.26.0] Error 1
gmake[3]: *** [/usr/local/share/GNUstep/Makefiles/Instance/library.make:278: 
internal-library-all_] Error 2
gmake[2]: *** [/usr/local/share/GNUstep/Makefiles/Master/rules.make:297: 
libgnustep-base.all.library.variables] Error 2
gmake[1]: *** [/usr/local/share/GNUstep/Makefiles/Master/library.make:37: 
internal-all] Error 2

libobjc2 / gnustep-base build troubles on Debian9

[Andreas Fink]

Hello David & all


Today I tried to build libobjc2 exactly the way you did as you seemed to have 
no errors.
So I installed Debian Testing (sid) on to an empty VM and got clang-7.0.1 with 
it.


I built then libobjc2 and all tests passed.


Then I went  onto gnustep-make and gnustep-base
Now gnustep-base doesn't want to configure..


It breaks with


The objc runtime library does not appear to have synchronisation support.  Try 
re-configuring gnustep-make with a CPPFLAGS variable containing a -L point to 
specify the directory containing the correct libobjc, or using the 
--with-objc-lib-flag=... option.




This came from the following code test:



configure:8000: checking for objc_sync_enter
configure:8000: /usr/bin/clang-7 -o conftest -I /opt/universalss7/include -L 
/opt/universalss7/lib/ -I/opt/universalss7/include -I/opt/universalss7/include 
-I/opt/universalss7/include -l/opt/universalss7/include -fblocks -x objective-c 
-L /opt/universalss7/lib/ -L/opt/universalss7/lib -L/opt/universalss7/lib 
-L/opt/universalss7/lib -L/opt/universalss7/lib conftest.c -lrt -ldl -lpthread 
-rdynamic -L /opt/universalss7/lib/ -pthread -fexceptions 
-fobjc-runtime=gnustep-2.0 -fblocks -L/root/GNUstep/Library/Libraries 
-L/opt/universalss7/lib -lpthread -l:libobjc.so.4.6 -lm   -lpthread  >&5


conftest.c:130:6: warning: incompatible redeclaration of library function 
'objc_sync_enter' [-Wincompatible-library-redeclaration]
char objc_sync_enter ();
     ^
conftest.c:130:6: note: 'objc_sync_enter' is a builtin with type 'int (id)'
1 warning generated.
/usr/bin/ld: /tmp/conftest-ca1f4b.o:(.data..objc_init[.objc_init]+0x18): 
undefined reference to `__start___objc_classes'
/usr/bin/ld: /tmp/conftest-ca1f4b.o:(.data..objc_init[.objc_init]+0x20): 
undefined reference to `__stop___objc_classes'
/usr/bin/ld: conftest: hidden symbol `__start___objc_classes' isn't defined
/usr/bin/ld: final link failed: bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)




As you can see
the libobjc2 is here:



-rw-r--r-- 1 root root 1151786 Jan 30 08:54 /opt/universalss7/lib/libobjc.a
lrwxrwxrwx 1 root root      14 Jan 30 08:55 /opt/universalss7/lib/libobjc.so -> 
libobjc.so.4.6
-rw-r--r-- 1 root root  683024 Jan 30 08:54 /opt/universalss7/lib/libobjc.so.4.6




gnustep-make was configured that way:



    cd make
    export PREFIX=/opt/universalss7/
    export CC=clang-7
    export CXX=clang++-7


    cat FilesystemLayouts/fhs | sed 
's/^GNUSTEP_DEFAULT_PREFIX=.*$/GNUSTEP_DEFAULT_PREFIX=\/opt\/universalss7/g' > 
FilesystemLayouts/universalss7
    export RUNTIME_VERSION=gnustep-2.0
    export OBJCFLAGS="-fblocks"
    export LDLAGS="-L${PREFIX}/lib"
    ./configure \
     --includedir=${PREFIX}/include \
     --libdir==${PREFIX}/lib \
            --with-layout=universalss7 \
            --disable-importing-config-file \
            --enable-native-objc-exceptions \
            --enable-objc-arc \
            --enable-install-ld-so-conf \
            --with-library-combo=ng-gnu-gnu \
            --with-config-file=${PREFIX}/etc/GNUstep/GNUstep.conf \
            --with-user-config-file='.GNUstep.conf' \
            --with-user-defaults-dir='GNUstep/Library/Defaults' \
            --with-objc-lib-flag="-l:libobjc.so.4.6"




I noticed there is another libobjc runtime on the system which came with 
clang-7 which is at /usr/lib/x86_64-linux-gnu/libobjc.so.4
but given we have put -l:libobjc.so.4.6 , this should not be an issue. (note 
the /opt/universalss7/lib directory is in /etc/ld.so.conf.d/gnustep-make.conf)
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep