|
| From: | Andreas Fink |
| Subject: | Re: clang versions for libobjc2 |
| Date: | Tue, 19 Feb 2019 19:55:37 +0100 |
| 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?
|
| [Prev in Thread] | Current Thread | [Next in Thread] |