Hi Bertrand, > On Jan 26, 2020, at 02:09, Bertrand Dekoninck <bertrand.dekoni...@gmail.com> > wrote: > > 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 ?)
It depends on what version of Debian installed on Riccardo's MIPS machine... > 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 >