Hi Riccardo ! I’ve installed art on debian buster x64 with the gnustep runtime (2.0) from latest source on github.com/gnustep (does it answer your PS, Sergii ?) I did’n’t try Ink, but Gworkspace works fine (well not its inspectors, of course) locally. I don’t see your error, Ricardo. Has this error something to do with the "Sync extension « not present on your system xlib ?
What should I do with valgrind ? Bertrand > Le 25 janv. 2020 à 00:13, cobjective <stoyan...@gmail.com> a écrit : > > Hi, Riccardo! > >> On Jan 24, 2020, at 00:51, Riccardo Mottola <riccardo.mott...@libero.it> >> wrote: >> >> Hi! >> >> to test the latest "libart" stuff I upgraded all GNUStep on the old and >> venerable MIPS Book Letux400 >> >> I got everything to build! yeah! >> >> If I export the display through ssh, everything works and (albeit slow... >> the Letux had the LAN connected through USB on the board) I get a fine >> looking GNUstep! >> >> If I use it locally, however, I get an immediate crash: >> >> (gdb) r >> Starting program: /home/usr-GNUstep/Local/Tools/Ink >> [Thread debugging using libthread_db enabled] >> [New Thread 16384 (LWP 330)] >> Xlib: extension "SYNC" missing on display ":0.0". >> *** glibc detected *** double free or corruption (out): 0x00636300 *** >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread 16384 (LWP 330)] >> 0x2b898a94 in kill () from /lib/libc.so.6 >> (gdb) bt >> #0 0x2b898a94 in kill () from /lib/libc.so.6 >> #1 0x2b674b88 in pthread_kill () from /lib/libpthread.so.0 >> #2 0x2b674c00 in raise () from /lib/libpthread.so.0 >> #3 0x2b89a190 in abort () from /lib/libc.so.6 >> #4 0x2b8d6294 in __fsetlocking () from /lib/libc.so.6 >> #5 0x2b8d6294 in __fsetlocking () from /lib/libc.so.6 >> Previous frame identical to this frame (corrupt stack?) >> >> this does not look very useful and looks like very early memory corruption? >> >> I recompiled all back with debug=yes, I hope that still disables >> optimizations correctl. I do not get a better stack. and not a better >> outcome either! >> >> Could someone using art on x86 or amd64 try valgrind? >> > > > Give more information, please. > Why do you think it’s art backend? Did you try other backends/compiler/linker? > What are your build options (runtime, library combo, compiler, linker)? > > P.S.: Does it mean you can build art backend without ftfont-old.m (with my > changes to art)? > > Sergii