Re: Newbie back again...

[Bertrand Gmail]

Sorry for the mistake, I didn't send the correct script (missing the 
i386 architecture option). Here it is again.


Bertrand


Le 23/04/2017 à 03:23, Bertrand Gmail a écrit :

Hi, Yan
I've spent several hours trying to reinstall again and again with 
clang, objc2, blocks and so on.


And yes, it's a real pain. But I've got now something that seems to be 
finally running.


First of all, regarding your initial question on adding the 386 
architecture on debian Jessie ; yes it's mandatory.


Without it, gui apps will segfault in Debian Jessie, due to something 
in libobjc.
I've seen on 
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux that this 
option was set in the "ubuntu 1404 " section but not in the "ubuntu 
1604" one.


I've reworked my script and I've splitted it in two parts (one for 
installing the dependancies, the other for compilation).

They work as is.

Maybe your problem for now is that libobjc isn't in a place where 
gnustep can find it. I remembered that sometimes ago, it wasn't 
installed in /usr/GNUstep/Local/Library/Libraries and my compiler 
didn't find it. I just picked the files in /usr/local and put them at 
that place and everything worked.


But I didn't have this problem today : everything is at his place and 
run.



You can try them in a clean jessie install to avoid some common 
problems with libraries mismatched or still installed.


Final note : in the script, I didn't add "export CC=clang"  and 
"export CXX=clang++" to bashrc so you will need to pass this option 
each time you compile some other program with gnustep.


Cheers,
Bertrand




my_install_gnustep_first_stage.sh
Description: application/shellscript
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Bertrand Gmail]

Hi, Yan
I've spent several hours trying to reinstall again and again with clang, 
objc2, blocks and so on.


And yes, it's a real pain. But I've got now something that seems to be 
finally running.


First of all, regarding your initial question on adding the 386 
architecture on debian Jessie ; yes it's mandatory.


Without it, gui apps will segfault in Debian Jessie, due to something in 
libobjc.
I've seen on 
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux that this 
option was set in the "ubuntu 1404 " section but not in the "ubuntu 
1604" one.


I've reworked my script and I've splitted it in two parts (one for 
installing the dependancies, the other for compilation).

They work as is.

Maybe your problem for now is that libobjc isn't in a place where 
gnustep can find it. I remembered that sometimes ago, it wasn't 
installed in /usr/GNUstep/Local/Library/Libraries and my compiler didn't 
find it. I just picked the files in /usr/local and put them at that 
place and everything worked.


But I didn't have this problem today : everything is at his place and run.


You can try them in a clean jessie install to avoid some common problems 
with libraries mismatched or still installed.


Final note : in the script, I didn't add "export CC=clang"  and "export 
CXX=clang++" to bashrc so you will need to pass this option each time 
you compile some other program with gnustep.


Cheers,
Bertrand


my_install_gnustep_first_stage.sh
Description: application/shellscript


my_install_gnustep_second_stage.sh
Description: application/shellscript
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Fred Kiefer]

Sorry, this is the point where I have to drop out. Perhaps David has time to 
take over? For this reason I send this mail again to the mailing list. That way 
you will get the best support available.

What you are getting is a mismatch between the available Objective-C runtimes. 
What I could recommend is to make sure that you have only one runtime at a time 
visible for your compilation. I would also suggest to make the compiler more 
explicit, by setting the CC variable. The mechanism to switch on the 
compilation messages didn’t work for you. I think you did forget the „s“ from 
„messages“, but you may also have to set the variable before the command, I 
really don’t remember. This also means you should have gotten the same messages 
during your last run, why didn’t you send them along?
With messages enabled we could see the actual compilation command and would be 
able to tell, which of your compilers get used and what the parameters are.

Fred




> Am 22.04.2017 um 21:54 schrieb Yan Le Guen :
> 
> >Yes, GNUstep still seems to be alive.
> Well good news ;-)
> Not going to argue about sync & multiple differents instructions files...
> 
> >Now to your actual problems:
> 
> >> Am 22.04.2017 um 16:47 schrieb Yan Le Guen :
> >>
> >> Me back again a bit desapointed... that's eventually explaining why so 
> >> long is this post...
> >>
> >> Here is attached:
> >> 1) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/make (version 2.7 from svn) :
> >> ./configure --enable-debug-by-default --with-layout=gnustep 
> >> --enable-objc-nonfragile-abi
> 
> >Did you also make and make install this package? And source the GNUstep.sh 
> >file after that? Sorry, but it is hard to guess what your did without any 
> >transcript.
> I of course did run:
> sudo -E make install
> . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
> and also update my ~/.bashrc on the fly...
> 
> >> 2) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/base (version 1.5 from svn):
> >> ./configure
> 
> >This output looks fine to me.
> well, this part of this outup point out some 'NO' that I do not really 
> understand:
> 
> checking whether objc really works... yes
> checking if the compiler supports -fconstant-string-class... yes
> checking if +load method is executed before main... yes
> checking for objc_sync_enter... yes
> checking for objc_setProperty... yes
> checking for _Block_copy... no
> checking for non-fragile-abi support... yes
> checking for objc_setUncaughtExceptionHandler() in runtime... no
> checking for objc_set_unexpected() in runtime... no
> checking for _objc_unexpected_exception in runtime... no
> configure: Disabling native Objective-C exceptions because the ObjC 
> runtime
> configure: has no way to set an uncaught exception handler.  Please 
> install
> configure: a recent Objective-C runtime if you want to use them.
> checking whether to enable native Objective-C exceptions... no
> checking for objc_sync_enter... (cached) yes
> checking for thread-safe +initialize in runtime... yes
> 
> 
> 
> >> 3) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/base :
> >> ./make -j2
> 
> >Now this is the bit that I really don’t understand and I can see why this is 
> >frustrating for you. Something goes wrong and there is no telling what or 
> >why.
> >GNUstep make is filtering off most of the output. You need to switch the 
> >display of compile messages on by calling make with the variable messages 
> >set to yes. I think this >gets done with this line, but I currently cannot 
> >test it.
> 
> >„make messages=yes“
> 
> OK, using this make command:
> 
> make -j2 message=yes | tee GUNstep-Base_make_outupt.txt
> 
> return this:
> This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
> Running in gnustep-make version 2 strict mode.
> Making all in Source ...
> rm -f dynamic-load.h
> cp simple-load.h dynamic-load.h
> /usr/GNUstep/System/Library/Makefiles/mkinstalldirs .
> cp ../Headers/GNUstepBase/config.h .
> touch ./config.h
> /usr/GNUstep/System/Library/Makefiles/mkinstalldirs ./GNUstepBase
> cp ../Headers/GNUstepBase/GSConfig.h ./GNUstepBase
> touch ./GNUstepBase/GSConfig.h
> Making all in Additions ...
> Making all for subproject Additions...
>  Compiling file GSTypeEncoding.c ...
>  Compiling file GSObjCRuntime.m ...
> In file included from GSObjCRuntime.m:39:
> ../../Headers/Foundation/NSException.h:44:2: error: "There are two separate 
> exception handling mechanisms
>   available ... one based on the standard setjmp() function (which does 
> not require special compiler
>   support), and one 'native' version where the compiler manages the 
> exception handling. If you try to use
>   both in the same executable, exception handlers will not work... which 
>