gnustep-back without freetype
Hi, I'm byilding back on my ol' solaris box. It has a fairly old environment and no pkg-config, which I couldn't get to build, btw. It fails with: checking DPS/dpsNXargs.h presence... no checking for DPS/dpsNXargs.h... no checking for freetype2... no configure: error: in `/export/home/multix/gnustep-src/gnustep-back-0.26.2': configure: error: The pkg-config script could not be found or is too old. Make sure it is in your PATH or set the PKG_CONFIG environment variable to the full path to pkg-config. Alternatively, you may set the environment variables FREETYPE_CFLAGS and FREETYPE_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. However, configure advertises: --without-freetype Do not check for or include freetype but... I get the failure anyway. I actually have an older freetype2 package, I don't know if it is good enough, it still uses freetype-config > freetype-config --cflags -I/opt/csw/include/freetype2 -I/opt/csw/include > freetype-config --libs -L/opt/csw/lib -lfreetype -lz I can pass those values to FREETYPE_CFLAGS and FREETYPE_LIBS, but that is geting in the mess I had on NetBSD some days ago... If we still support buliding without freetype, --without-freetype should work :) It actually passes the freetype check and builds, but has other strange issues I was not getting before! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: strange issue with Mutable Dictionary
Hi, thanks for your efforts. Unfortunately they give me no real clue to ehere the problem is. I cleaned up the init methods and the Flags seem to me properly allocated and release. So I guess something goes wrong on the whole message or some issue reading the cache file (maybe corrupted). Sebastian Reitenbach wrote: Hi, so just updated pantomime and gnumail to latest svn. Otherwise have packages installed, latest releases of all gnustep. I'm on OpenBSD amd64, 6.3, everything built with clang. Now entering my inbox I get: read_unsinged_int: EOF read_unsinged_int: EOF read_unsinged_int: EOF This, which you get at the second attempt to, is not something good. It means that reading certain values from the file, 0 bytes gets read, which is interpreted as EOF according to the manpages. It would be good to know if it is always the same message or not. I enhanced the read APIs to return an error result and write the value in a variable passed by-reference. Perhaps this can help us narrowing down the issue. Although GNUMail is not perfect, I can use IMAP on several different setups: Mac, GNUstep, 32bit and 64bit. So it is not "so bad". I remember having a computer where sometimes the Cachefiles become immense (months ago, maybe that issue was fixed and y ou have old cache files, I don't know) First, I would ask you to update and retry. If we are lucky, we will get more Debug output, e.g. a message number out of the expected ones present in the Folder. If that happens, please try again and see if it is always the same message. Maybe it has issues or it is corrupted. Also, let's do a sanity check: cache files contain only headers, so they should be fairly small. you will find them in GNUstep/LIbrary/GNUMail IMAPCache_* to give a ballpark: my Trash has 9900 messages and has a 3.7M file big and other folders are proportinal to them Please check your sizes and tell us the message count (e.g. by using another Mail Agent). Due to the size being encoded in a 32bit er may have either a 4GB or 2GB because sometimes a signed representation is used. This should give us space for about 500.000 messages per folder. If you think they are corrupt, do not remove them yet (they will regenerate) I still hope the code can be cleaned to fail more gracefully or at least return a more significant message than EOF! Thank you, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-back without freetype
Hoi Fred, Fred Kiefer wrote: as far as I am aware the cairo backend won’t build without freetype. So most likely you are building the xlib or the art backend. And if you do, you really should state this. These backends are deprecated. If you get them to work on your machine, fine. If you don’t, I won’t be able to help you. And nobody else will, as long as you don’t write what is happening when you try to use this specific setup:-( yes absolutely, this is xlib, the most portable backend we have, very useful I think it was my fault, after updating all our flags, it has become more sensitive. It actually picked up a too-old version of something. I tried again from zero and without-freetype and it correctly skipped the test and everything built fine. I was happily running Ink.app on GNUstep on Solaris and SPARC v9 (Netra T1 1U Server) :) In case somebody wants to write Server applications and have a GNUstep gui to manage them... we are ready :) Later on I also was able to compile and start GNUMail! I did not test it it much because it did not connect, but I will investigate. It was already nice to see it coming up. Happens that I always use your app as a test... Thanks, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cocoadialog / other software to port / gnustep cd
Hi, Gürkan Myczko wrote: hi gnusteppers how hard would it be to port https://github.com/cocoadialog/cocoadialog/issues/107 to gnustep? and am i the only one wanting this? at a first glance, it is not really released. There seemed to be an old version which from the screenshots was of the 10.2/10.3 aera, but then new the "stuff" is not finished yet. Maybe you are the only one wanting this, I never heard of it. i'm also trying to list other software that might be interesting to port to gnustep at https://wiki.debian.org/DebianGNUstep I would add: LaternaMagica, Graphos and GSPdf. I miss LaternaMagica which I extra wrote as a convenient image viewer for GS and use daily, while Graphos will improve for the next release (due really soon!). It the least useful application of the 3 mentioned, but is some sort of GNUstep demonstrator. The to-release version improves and I did use it for some "real" work. Especially the latter is really my standard Print previewer and works like a charme! being a ghsotscript wrapper, it renders more reliably than xpdf or poppler based things, it support PS itself best of course. once i have a working emacs.app with the debian sid gnustep, i'll try to make a new livecd.gnustep.org based on that (amd64). wishes/feedback welcome Emacs is a nut to crack to make portable, but on Linux the newest release is a bit usale, but I do get issues, I still use the gtk version for coding. Getting emacs really work with GNUstep and then make it also usable on BSD would be a great achievement for 2018! I'd love it, I spent several hours with only minimal fixes though. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Segmentation Faults - OpenBSD
Hi All, After updating GNUstep on OpenBSD/i386 with gcc, I noticed that all applications segfault. At first, I thought it is a strange combination of an old setup, with system gcc+libobjc1 (which however worked before upgrading) However, I have a second machine where GS was proven working and with gcc 4.9 and its own runtime, a setup that worked before and worked on other system. Test: everything works, update, gnustep base, gui, back : everything segfaults! so that machine is the proof that the commits of the past week broke, I don't see how OpenBSD can be so much different, it worked for a long time. I notice that during gui build: Making all for service GSspell... gmake[4]: Nothing to be done for 'internal-service-compile'. Creating GSspell.service/Resources/Info-gnustep.plist... Segmentation fault (core dumped) gmake[3]: *** [/usr/GNUstep/System/Library/Makefiles/Instance/service.make:141: GSspell.service/Resources/Info-gnustep.plist] Error 1 so I found that something as simple as this: $ plparse Source/Info-gnustep.plist Segmentation fault (core dumped) this smells as an issue in base! doesn't it? this even more: $ plparse Segmentation fault (core dumped) however, this is of no use at all!! Program received signal SIGSEGV, Segmentation fault. 0x0cfd6dbc in _libc_memcpy (dst0=0x38c, src0=0x7b41c0bc, length=2031685792) at /usr/src/lib/libc/string/memcpy.c:54 54 /usr/src/lib/libc/string/memcpy.c: No such file or directory. in /usr/src/lib/libc/string/memcpy.c Current language: auto; currently minimal so now? even id I build with debug, I get no better stacktrace. This sounds bad, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Segmentation Faults - OpenBSD
Hi, Matt Rice wrote: Fred, did you try on OpenBSD? This smells to me like an issue of relying upon the platform dependent shared library constructor call order. perhaps the innocuous looking NSBundle changes here: https://github.com/gnustep/libs-base/commit/43673452a505a79a55dd1d59b0789f5ebc2eec0c#diff-c09284bb3ef153ed33bb7f447c4fe88e such as perhaps: NSBundle +load -> +initialize, and perhaps GSTinyString's +load or some such being called in an unexpected order. anyhow, the setName: call should result in a memcpy... perhaps Riccardo could give it a go without that change. I tried reverting with git that single commit, but git failed. I thus reverted whole base to 26th of March and things look fine. Going forward to the 27th, fine.. up to the 30th of March when it breaks. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Segmentation Faults - OpenBSD
Hi,
On 2018-04-07 18:04:12 + David Chisnall wrote:
>
> No idea if either of them are relevant, but I’ve just pushed two fixes for
> memory-related errors in -base. One writes some data through an
> uninitialised pointer when an exception is thrown and the platform doesn’t
> provide backtrace. The other treats things as GSString instances even if
> they aren’t and so can potentially dereference an invalid pointer.
>
> Either of these could cause random crashes in some usage on some platforms.
unfortunatley not. I still get a hard crash while running "plmerge". For me it
is OpenBSD only, but I got that Gregory has issues on linux to.
I was able to compile with debug and get a better starcktrace, although I think
it is corrupted and loops.. or we have some case of /thread recurision
Riccardo
Program received signal SIGSEGV, Segmentation fault.
0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
at /usr/src/lib/libc/string/memcpy.c:54
54 /usr/src/lib/libc/string/memcpy.c: No such file or directory.
in /usr/src/lib/libc/string/memcpy.c
Current language: auto; currently minimal
(gdb) bt
#0 0x0ba98aac in _libc_memcpy (dst0=0x384, src0=0x7a6f60c4, length=88)
at /usr/src/lib/libc/string/memcpy.c:54
#1 0x0ba9f956 in _libc_arc4random_buf (buf=0x85d03bd4, n=Variable "n" is not
available.
)
at /usr/src/lib/libc/crypt/arc4random.c:154
#2 0x0ba60cfa in omalloc (sz=Variable "sz" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:308
#3 0x0ba60b72 in malloc (size=Variable "size" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:1273
#4 0x0869dd26 in default_malloc (zone=0x286ffa60, size=88) at NSZone.m:124
#5 0x086a0722 in NSZoneMalloc (zone=0x286ffa60, size=88) at NSZone.m:1779
#6 0x085d3bbe in NSAllocateObject (aClass=0x28695760, extraBytes=0,
zone=0x286ffa60) at NSObject.m:788
#7 0x08586b93 in +[NSHashTable allocWithZone:] (self=0x28695760,
_cmd=0x286957f0, aZone=0x286ffa60) at NSHashTable.m:51
#8 0x08524303 in NSCreateHashTableWithZone (k=
{hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c
<_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a
<_NS_non_owned_void_p_retain>, release = 0x8519e30
<_NS_non_owned_void_p_release>, describe = 0x8519e36
<_NS_non_owned_void_p_describe>}, capacity=10, zone=0x286ffa60)
at NSConcreteHashTable.m:308
#9 0x08524169 in NSCreateHashTable (callBacks=
{hash = 0x8519e11 <_NS_non_owned_void_p_hash>, isEqual = 0x8519e1c
<_NS_non_owned_void_p_is_equal>, retain = 0x8519e2a
<_NS_non_owned_void_p_retain>, release = 0x8519e30
<_NS_non_owned_void_p_release>, describe = 0x8519e36
<_NS_non_owned_void_p_describe>}, capacity=10) at NSConcreteHashTable.m:283
#10 0x0864d4e7 in -[NSThread init] (self=0x7d5aea10, _cmd=0x286c3cc0)
at NSThread.m:1092
#11 0x085d428d in +[NSObject new] (self=0x286e5080, _cmd=0x286e5248)
at NSObject.m:1233
#12 0x0864ca6b in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
_cmd=0x286e5438) at NSThread.m:844
#13 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#14 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#15 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#16 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae110,
_cmd=0x286e5270) at NSThread.m:769
#17 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
_cmd=0x286e5438) at NSThread.m:846
#18 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#19 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#20 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#21 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae290,
_cmd=0x286e5270) at NSThread.m:769
#22 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
_cmd=0x286e5438) at NSThread.m:846
#23 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#24 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#25 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#26 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7d5ae310,
_cmd=0x286e5270) at NSThread.m:769
#27 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
_cmd=0x286e5438) at NSThread.m:846
#28 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#29 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#30 0x0864b7d4 in GSPrivateThreadID () at NSThread.m:142
#31 0x0864c6e3 in -[NSThread(Activation) _makeThreadActive] (self=0x7cb4f990,
_cmd=0x286e5270) at NSThread.m:769
#32 0x0864ca9d in +[NSThread _createThreadForCurrentPthread] (self=0x286e5080,
_cmd=0x286e5438) at NSThread.m:846
#33 0x08650424 in GSRegisterCurrentThread () at NSThread.m:2192
#34 0x0864c3bd in GSCurrentThread () at NSThread.m:673
#35 0x0864b7d4 in GSPrivateThreadID () at NSThread
Re: Segmentation Faults - OpenBSD
Hi, David Chisnall wrote: Either of these could cause random crashes in some usage on some platforms. just for the record - I am getting a crash on NetBSD too. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Segmentation Faults - OpenBSD
further update, I got this mix OpenBSD/x86 gcc -> plmerge fails because it says its environment is not setup (no crash) NetBSD/x86 gcc -> plmerge is fine, but any GUI app crashes FreeBSD/amd64 clang -> works Linux/x86 clang -> works Linux/x86 gcc -> deep crash in plmerge Linux/PPC gcc -> crash in plmerge so I am thinking this is maybe more a compiler issue than an OS issue Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Segmentation Faults - OpenBSD
Hi,
Richard just commited some promising fixes.
Things seem better, but not stable. Here a summary of the current
status. OpenBSD seems fine on x86, on amd64 I get some strange issues
that might not be related
FreeBSD/amd64/clang
- seems to work with all apps I tried
- One test failure:
base/NSException/basic.m:
Failed test: basic.m:51 ... addresses and symbols match
OpenBSD/i386/gcc
- seems to work fine
- Two test failures
base/NSException/basic.m:
Failed test: basic.m:51 ... addresses and symbols match
base/NSProcessInfo/general.m:
Failed test: general.m:48 ... -systemUptime works
OpenBSD/amd64/gcc
- gui apps do not start due to some symbol relocations maybe a spurious
error
- Two test failures
base/NSException/basic.m:
Failed test: basic.m:50 ... call stac addresses is not empty
base/NSProcessInfo/general.m:
Failed test: general.m:48 ... -systemUptime works
NetBSD/amd64/gcc
things mostly work, but apps spit out an incredible number of errors,
like below:
- test failures:
base/NSException/basic.m:
Failed test: basic.m:51 ... addresses and symbols match
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c8521602f0) of class GSDictionary in thread
{name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c852161c60) of class GSNotification in
thread {name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c854dfed90) of class NSFont in thread
{name = (null), num = 126204759418048}
2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called
without pool for object (0x72c854dfe790) of class NSFont in thread
{name = (null), num = 126204759418048}
NetBSD/i386/gcc
plmerge "works" however all gui apps crash
(gdb) bt
#0 0xbb20ff0e in pthread_cond_signal () from /usr/lib/libpthread.so.1
#1 0xb7db59fb in _xcb_in_wake_up_next_reader () from
/usr/pkg/lib/libxcb.so.1
#2 0xb7db5b67 in wait_for_reply () from /usr/pkg/lib/libxcb.so.1
#3 0xb7db5ca6 in xcb_wait_for_reply64 () from /usr/pkg/lib/libxcb.so.1
#4 0xb82295dd in _XReply () from /usr/pkg/lib/libX11.so.6
#5 0xb821a014 in XOpenDisplay () from /usr/pkg/lib/libX11.so.6
#6 0xb85b00e4 in -[XGServer _initXContext] (self=0xb8650180,
_cmd=0xb85f63b0 <_OBJC_SELECTOR_TABLE+240>) at XGServer.m:422
#7 0xb85af246 in -[XGServer initWithAttributes:] (self=0xb8650180,
_cmd=0xbbbad128 <_OBJC_SELECTOR_TABLE+72>, info=0x0) at XGServer.m:477
#8 0xbb9cdeb4 in +[GSDisplayServer serverWithAttributes:] (
self=0xbbbad2a0 <_OBJC_Class_GSDisplayServer>, _cmd=0xbbaeb868
<_OBJC_SELECTOR_TABLE+1672>,
attributes=0x0) at GSDisplayServer.m:187
#9 0xbb826fa0 in -[NSApplication _init] (self=0xb88fb330,
_cmd=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>) at NSApplication.m:884
#10 0xbb41c688 in -[NSObject performSelector:withObject:] (self=0xb88fb330,
_cmd=0xbb708d18 <_OBJC_SELECTOR_TABLE+280>, aSelector=0xbbaeb8c0
<_OBJC_SELECTOR_TABLE+1760>,
anObject=0xb88fb330) at NSObject.m:2009
#11 0xbb491f9a in -[NSObject(NSThreadPerformAdditions)
performSelector:onThread:withObject:waitUntilDone:modes:]
(self=0xb88fb330, _cmd=0xbb708e20 <_OBJC_SELECTOR_TABLE+544>,
aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
aThread=0xb8860510, anObject=0xb88fb330,
aFlag=1 '\001', anArray=0xb876a320) at NSThread.m:2094
#12 0xbb491e74 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:]
(self=0xb88fb330, _cmd=0xbb708e28 <_OBJC_SELECTOR_TABLE+552>,
aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
anObject=0xb88fb330, aFlag=1 '\001',
anArray=0xb876a320) at NSThread.m:2053
#13 0xbb491edb in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:] (self=0xb88fb330,
_cmd=0xbbaeb8c8 <_OBJC_SELECTOR_TABLE+1768>,
aSelector=0xbbaeb8c0 <_OBJC_SELECTOR_TABLE+1760>,
anObject=0xb88fb330, aFlag=1 '\001')
at NSThread.m:2063
#14 0xbb825877 in -[NSApplication init] (self=0xb88fb330,
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
exceptions pulling an Abort Trap
fbfe640) at main.m:30 can it be that libobjc2 is incompatible with gcc if not compiled with it? or that base configure got confused? Can I instruct gnustep to use gcc's runtime even if libobjc2 is present, as a "test" ? I configured make with: $ ./configure --prefix=/ --with-layout=gnustep CC=gcc7 CXX=g++7 CPP=cpp7 and base with no additional parameters. configure says: configure:5987: checking the Objective-C runtime configure:5997: result: GNU configure:6014: checking for custom shared objc library configure:6073: result: NONE but it will say GNU for both gcc's and David's runtime, right? Actually, I fear that FreeBSD ships only libobj2 and that gcc7 is without objc runtime somehow.. it is strange, I find only one libobjc.so... Thanks, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: exceptions pulling an Abort Trap
Hi all, nobody has a hint? I am suspecting that if libobjc2 of FreeBSD was compiled with clang (which surely is) it won't work with GCC. It is very strange I did not find GCC's runtime library though. Or maybe the problem is totally different? Riccardo Riccardo Mottola wrote: Hi, I have a strange issue on FreeBSD. I am running gnustep git head. Ít is compiled with gcc7. I am actually unsure which runtime is being used. I have libobjc2 installed as a package, I don't know if gnustep picks up that one or uses gcc's one. I suppose though yes, this is the ldd of base: $ ldd /System/Library/Libraries/libgnustep-base.so /System/Library/Libraries/libgnustep-base.so: libobjc.so.4.6 => /usr/local/lib/libobjc.so.4.6 (0x2860) libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x28625000) libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x281e1000) libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x281ec000) libgnutls.so.30 => /usr/local/lib/libgnutls.so.30 (0x2867d000) libxslt.so.1 => /usr/local/lib/libxslt.so.1 (0x287b6000) libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x28d88000) libz.so.6 => /lib/libz.so.6 (0x28edb000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28ef1000) libm.so.5 => /lib/libm.so.5 (0x28f17000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28f3f000) libffi.so.6 => /usr/local/lib/libffi.so.6 (0x287eb000) libkvm.so.7 => /lib/libkvm.so.7 (0x287f2000) librt.so.1 => /usr/lib/librt.so.1 (0x281fa000) libthr.so.3 => /lib/libthr.so.3 (0x29034000) libicui18n.so.61 => /usr/local/lib/libicui18n.so.61 (0x29057000) libicuuc.so.61 => /usr/local/lib/libicuuc.so.61 (0x29313000) libicudata.so.61 => /usr/local/lib/libicudata.so.61 (0x294ae000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x294b) libc.so.7 => /lib/libc.so.7 (0x28071000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x294bc000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x294d5000) libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x294de000) libp11-kit.so.0 => /usr/local/lib/libp11-kit.so.0 (0x2951f000) libunistring.so.2 => /usr/local/lib/libunistring.so.2 (0x295f) libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x2977a000) libnettle.so.6 => /usr/local/lib/libnettle.so.6 (0x2978b000) libhogweed.so.4 => /usr/local/lib/libhogweed.so.4 (0x297be000) libidn2.so.0 => /usr/local/lib/libidn2.so.0 (0x297eb000) libelf.so.2 => /lib/libelf.so.2 (0x29807000) libc++.so.1 => /usr/lib/libc++.so.1 (0x2981d000) libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x298db000) now, applications are unstable, the get abort trap often and I think this is everytime an exception occours. This is the stacktrace of an examplle, but it is always with raise/throg. Program received signal SIGABRT, Aborted. 0x2823a42f in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x2823a42f in thr_kill () from /lib/libc.so.7 #1 0x2823a40b in raise () from /lib/libc.so.7 #2 0x2823a36f in abort () from /lib/libc.so.7 #3 0x2812237f in objc_exception_throw () from /usr/local/lib/libobjc.so.4.6 #4 0x28d55fcd in -[NSException raise] (self=0x2a262fe4, _cmd=0x2810d1e8 <_OBJC_SELECTOR_TABLE+872>) at NSException.m:1511 #5 0x280e90e7 in -[DBSoap login] (self=, _cmd=, url=, userName=, password=, useHttps=) at DBSoap.m:1262 #6 0x0804c786 in -[AppController doLogin:] (self=, _cmd=, sender=) at AppController.m:295 #7 0x284d3878 in -[NSApplication sendAction:to:from:] (self=0x2a0a88c4, _cmd=0x2358 <_OBJC_SELECTOR_TABLE+664>, aSelector=0x2a1157f8, aTarget=0x2a21c284, sender=0x2a022c84) at NSApplication.m:2250 #8 0x28530e3e in -[NSControl sendAction:to:] (self=0x2a022c84, _cmd=0x28876238 <_OBJC_SELECTOR_TABLE+696>, theAction=0x2a1157f8, theTarget=0x2a21c284) at NSControl.m:760 #9 0x2850bde1 in -[NSCell _sendActionFrom:] (self=0x2c483984, _cmd=0x28876290 <_OBJC_SELECTOR_TABLE+784>, sender=0x2a022c84) at NSCell.m:1451 #10 0x28507c43 in -[NSButtonCell performClickWithFrame:inView:] (self=0x2c483984, _cmd=0x2390 <_OBJC_SELECTOR_TABLE+720>, cellFrame=..., controlView=0x2a022c84) at NSButtonCell.m:1590 #11 0x285311bb in -[NSControl performClick:] (self=0x2a022c84, _cmd=0x28870008 <_OBJC_SELECTOR_TABLE+392>, sender=0x2a022c84) at NSControl.m:858 #12 0x28504cbc in -[NSButton performKeyEquivalent:] (self=0x2a022c84, _cmd=0x289188f8 <_OBJC_SELECTOR_TABLE+2488>, anEvent=0x2c86d964) at NSButton.m:528 #13 0x28632c1b in -[NSView performKeyEquivalent:] (self=0x2a022984, _cmd=0x289200a0 <_OBJC_SELECTOR_TABLE+3104>, theEvent=0x2c86d964) at NSView.m:3490 #14 0x284d63a9 in -[NSApplica
Re: exceptions pulling an Abort Trap
Hi David, On 2018-05-24 12:44:21 + David Chisnall wrote: Hi Riccardo, This looks like what happens if you have no @catch block anywhere on the stack. If you can recompile the runtime, try sticking #define DEBUG_EXCEPTIONS in eh_personality.c - it will report where failures are happening. thanks for the hint. First, let me specify that the libobjc2 I had installed was the binary package provided by FreeBSD. The platform is x86 Second, I noticed that I need libobjc2 package, if i remove it, gnustep base does not find any runtime with GCC7. Could it be that the gcc provided by FreeBSD packages contains language support but no runtime with the intent to have a single runtime for everything (which would be yours)? Indeed I did not find any other libobjc.so in /usr/local I tried building libobjc2 from our github repo sources (I did not yet modivy eh_personality.c, tried a stock compilation), but i fails this way: Scanning dependencies of target CXXExceptions [ 12%] Building C object Test/CMakeFiles/CXXExceptions.dir/CXXException.m.o cc: error: unable to execute command: Segmentation fault (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: i386-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. cc: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/ForwardDeclareProtocol-f61ec1.m cc: note: diagnostic msg: /tmp/ForwardDeclareProtocol-f61ec1.sh cc: note: diagnostic msg: If I run make again, it will continue, but fail repeatably in other places: [ 11%] Built target ObjCXXEHInterop [ 11%] Building C object Test/CMakeFiles/ForwardDeclareProtocolAccess.dir/ForwardDeclareProtocol.m.o cc: error: unable to execute command: Segmentation fault (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) this place looks repeatable, if I run make again and again. A bit unexpected? Can I force it to build with gcc7 or another versin of clang? Apparently packages are only for lder versions than 4.0: bazel-clang38-0.11.0 Fast and correct build system clang-devel-7.0.d20180327 C, Objective-C, and C++ compiler (use devel/llvm-devel) clang33-3.3_10 C, Objective-C, and C++ compiler clang34-3.4.2_8C, Objective-C, and C++ compiler clang35-3.5.2_4C, Objective-C, and C++ compiler clang38-3.8_1 C, Objective-C, and C++ compiler (use devel/llvm38) Thanks, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
assertion when using clang + libobjc2
Hi All, I just finished upgrading a Linux/x86 system where I run clang as compiler and David's libobjc2 compiled from our sources. It is gentoo stable, whith clang 5.0 libobjc2 was compiled with the same clang and from git head. After updating libobjc2, any program dies: $ plparse plparse: /home/multix/gnustep-cvs/libobjc2/protocol.c:226: BOOL init_protocols(struct objc_protocol_list *): Assertion `aProto->isa == protocol_class_gcc' failed. Aborted I have recompiled also base, just for safety, but no help. any clues? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: exceptions pulling an Abort Trap
Hi David,
David Chisnall wrote:
This looks like what happens if you have no @catch block anywhere on the stack.
If you can recompile the runtime, try sticking #define DEBUG_EXCEPTIONS in
eh_personality.c - it will report where failures are happening.
I updated and rebuilt with clang-devel (7.0)
Finally, this compiler completes build! I install but things do not work
better.
I rerun configure of gnustep-base and notice that the obj-c availability
test fails with this error:
| int main(int argc, char **argv) {
| pid_t t = syscall(SYS_gettid); return t == -1 ? 1 : 0; }
configure:7806: result: no
configure:7817: checking whether objc really works
configure:7837: gcc7 -o conftest -g -O2 -I/Local/Library/Headers
-I/Local/Library/Headers -I/System/Library/Headers -I/usr/local/include
-I/System/Library/Headers -fgnu-runtime -x ob
jective-c -shared-libgcc -L/Local/Library/Libraries
-L/Local/Library/Libraries -L/System/Library/Libraries -L/usr/local/lib
-L/System/Library/Libraries conftest.c -lrt -lpthread -rdy
namic -shared-libgcc -pthread -fexceptions -fgnu-runtime
-L/home/multix/GNUstep/Library/Libraries -L/Local/Library/Libraries
-L/System/Library/Libraries -L/usr/local/lib -lobjc -lm >&5
/System/Library/Libraries/libobjc.so: undefined reference to `__atomic_load'
collect2: error: ld returned 1 exit status
configure:7837: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
This hints that libobjc.so is not properly linked or misses atomic_load
for some reason.
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: assertion when using clang + libobjc2
Hi, David Chisnall wrote: Thank you for the report. Most of the tests don’t build with the GCC ABI, so that code path is not as well tested as the two newer ABIs - thank you for testing it, and please do file bugs if you hit any more issues. I believe this is now fixed in git. indeed, we are a little further. gnustep-base tools do run now! However, if I launch and GUI application, it will crash, with this stacktrace: Program received signal SIGSEGV, Segmentation fault. __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33 33 ../sysdeps/i386/i686/multiarch/../strcmp.S: No such file or directory. (gdb) bt #0 __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33 #1 0xb72038c0 in string_compare () from /System/Library/Libraries/libobjc.so.4.6 #2 0xb72037bc in sel_isEqual () from /System/Library/Libraries/libobjc.so.4.6 #3 0xb71fe08d in get_method_description () from /System/Library/Libraries/libobjc.so.4.6 #4 0xb71fdf8f in protocol_getMethodDescription () from /System/Library/Libraries/libobjc.so.4.6 #5 0xb7517f60 in GSProtocolGetMethodDescriptionRecursive ( aProtocol=, aSel=, isRequired=76 'L', isInstance=248 '\370') at GSObjCRuntime.m:827 #6 0xb73fd484 in -[NSDistantObject methodSignatureForSelector:] ( self=0x868b14c, _cmd=, aSelector=0xb77c1ff8 <.objc_selector_list+320>) at NSDistantObject.m:727 #7 0xb75159e7 in GSFFIInvocationCallback (cif=, retp=, args=, user=) at GSFFIInvocation.m:538 #8 0xb4bb9a75 in ?? () from /usr/lib/libffi.so.6 #9 0xb4bb9e26 in ?? () from /usr/lib/libffi.so.6 #10 0xb7400ab0 in -[NSDistributedNotificationCenter(Private) _connect] ( self=, _cmd=) at NSDistributedNotificationCenter.m:781 #11 0xb73ff743 in -[NSDistributedNotificationCenter addObserver:selector:name:ob I thus did run base's tests... here the results: 6924 Passed tests 30 Dashed hopes 9 Failed files 8 Skipped sets 5 Failed tests that's not that good on a standard linux x86 system, but not a disaster either. Failed test: general.m:37 ... -classNamed returns the correct class Failed test: general.m:49 ... -executablePath returns an executable path (gnustep bundle) Failed test: general.m:61 ... -principalClass returns TestClass for +bundleForClass:[TestClass class] Failed file: test00.m aborted without running all tests! Failed file: test02.m aborted without running all tests! Failed file: basic.m aborted without running all tests! Failed file: test01.m aborted without running all tests! Failed file: test02.m aborted without running all tests! Failed file: test03.m aborted without running all tests! Failed file: test04.m aborted without running all tests! Failed file: test05.m aborted without running all tests! Failed file: test06.m aborted without running all tests! Failed test: test01.m:44 ... Got the correct data from a 200 - status load Failed test: test01.m:58 ... 404 - status: Handle load not loaded (resource not found) only the general.m are probably worrysome, I suppose, they refer to bundles though and no crash Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Runtime / exceptions model configuration options
Hi All, I am a bit confused about how to configure different exceptions and runtimes in gnustep make and gui! I notice we have no clear section in a README or INSTALL file or on the wiki, or, in case, I missed it. I need to control of it to correctly test libobjc2 by David and also to avoid this 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 can be pretty disastrous. This error is telling you that the gnustep-base library was built using one form of exception handling, but that the gnustep-make package you are using is building code to use the other form of exception handling ... with the consequence that exception handling would be broken in the program you are building. So, somehow your gnustep-base and gnustep-make package are incompatible, and you need to replace one of them with a version configured to match the other." So we have standard and native. I understand that standard is default for gcc. Fine. The issue is when wanting to use libobjc2 and/or clang. gnustep-make if used with clang enables native exceptions (most probably becausde it is clang's default) I think that if I use --with-library-combo=ng-gnu-gnu on gnustep-base I enable automatically also native exceptions How can I build e.g. with clang and standard exceptions? do I need to pass specific CFLAGS perhaps or do we have ebtter options? I didn't find any. For example, would like to compile code with clang but standard exceptions, so that I can rule out gcc issues with libobjc2. Thank you, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: assertion when using clang + libobjc2
Hi David,
David Chisnall wrote:
Thank you for the report. Most of the tests don’t build with the GCC ABI, so
that code path is not as well tested as the two newer ABIs - thank you for
testing it, and please do file bugs if you hit any more issues. I believe this
is now fixed in git.
I did further thests here and a clean build and recompile of everything.
I did compile a debug version of gnustep-base (although maybe a one for
libobjc is needed to, how is it done with cmake?)
As I wrote, simple tools like plparse do now work, but any gui
application will file.
Here a clean version of Ink:
2018-06-07 00:11:27.699 Ink[6673:6673] styleoffsets ... guessing offsets
2018-06-07 00:11:27.701 Ink[6673:6673] styleoffsets ... guessing offsets
Program received signal SIGSEGV, Segmentation fault.
__strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33
33 ../sysdeps/i386/i686/multiarch/../strcmp.S: No such file or
directory.
#0 __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:33
#1 0xb71058c0 in string_compare ()
from /System/Library/Libraries/libobjc.so.4.6
#2 0xb71057bc in sel_isEqual () from
/System/Library/Libraries/libobjc.so.4.6
#3 0xb710008d in get_method_description ()
from /System/Library/Libraries/libobjc.so.4.6
#4 0xb70fff8f in protocol_getMethodDescription ()
from /System/Library/Libraries/libobjc.so.4.6
#5 0xb75b3443 in GSProtocolGetMethodDescriptionRecursive (
aProtocol=0xb77bfa50 <.objc_protocol.103>,
aSel=0xb77c0080 <.objc_selector_list+192>, isRequired=1 '\001',
isInstance=1 '\001') at GSObjCRuntime.m:827
#6 0xb738bf5c in -[NSDistantObject methodSignatureForSelector:] (
self=0x86bf9cc, _cmd=0xb78030f4 <.objc_selector_list+200>,
aSelector=0xb77c0080 <.objc_selector_list+192>) at
NSDistantObject.m:727
#7 0xb75af5d4 in GSFFIInvocationCallback (cif=0x86c5f40, retp=0xbfffe8a0,
args=0xbfffe830, user=0x86bdc44) at GSFFIInvocation.m:538
#8 0xb4abba75 in ?? () from /usr/lib/libffi.so.6
#9 0xb4abbe26 in ?? () from /usr/lib/libffi.so.6
#10 0xb7392bdb in -[NSDistributedNotificationCenter(Private) _connect] (
self=0x868cbe4, _cmd=0xb77c0048 <.objc_selector_list+136>)
at NSDistributedNotificationCenter.m:781
#11 0xb73904e9 in -[NSDistributedNotificationCenter
addObserver:selector:name:object:suspensionBehavior:] (self=0x868cbe4,
_cmd=0xb77c0038 <.objc_selector_list+120>, anObserver=0x868c8f4,
aSelector=0xb7f5b798 <.objc_selector_list+352>, notificationName=0x0,
anObject=0xb7f5b350 <.objc_str.437>, suspensionBehavior=2)
at NSDistributedNotificationCenter.m:341
#12 0xb7390069 in -[NSDistributedNotificationCenter
addObserver:selector:name:object:] (self=0x868cbe4, _cmd=0xb7f5b850
<.objc_selector_list+536>,
anObserver=0x868c8f4, aSelector=0xb7f5b798 <.objc_selector_list+352>,
notificationName=0x0, anObject=0xb7f5b350 <.objc_str.437>)
at NSDistributedNotificationCenter.m:266
#13 0xb7c49253 in -[_GSWorkspaceCenter init] (self=0x868c8f4,
_cmd=) at NSWorkspace.m:335
I get no information inside libobjc, however:
(gdb) list
822 struct objc_method_description
823 GSProtocolGetMethodDescriptionRecursive(Protocol *aProtocol, SEL
aSel, BOOL isRequired, BOOL isInstance)
824 {
825 struct objc_method_description desc;
826
827 desc = protocol_getMethodDescription(aProtocol, aSel,
isRequired, isInstance);
828 if (desc.name == NULL && desc.types == NULL)
829 {
830 Protocol **list;
831 unsigned int count;
(gdb) po NSStringFromSelector(aSel)
registerClient:
at first, it does not seem wrong, something is doing hfavoc inside
method description or sel_isEqual
maybe with debug information for libobjc2 I can give you better information
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Runtime / exceptions model configuration options
Hi Richard, Richard Frith-Macdonald wrote: So the default is for gnustep-make to use native exceptions, but you can override it using --disable-native-objc-exceptions, and you may need to be aware that, if the compiler/runtime gnustep-base sees at configure time does not support native exceptions, then the base configure process may override the setting from when you configured make. I don't think there should ever be a problem if you configure gnustep-make to use traditional setjmp based exceptions though. NB. make sure you have a clean instuall when changing this stuff ... if you have some libraries/code built one way and some libraries/code built the other way then you will get problems. (I do know I need to recompile everything when switching) sorry I missed that option :( but actually it doesn't help: I already had "make" going standard while base native. I hoped forcing would help though and I tried. I configured and installed make with this: ./configure --prefix=/ --with-layout=gnustep --disable-native-objc-exceptions then I configure base and I explictely see during configure: 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... yes checking whether to enable native Objective-C exceptions... no checking for objc_sync_enter... (cached) yes checking for thread-safe +initialize in runtime... yes yet then build gives the previously copied mismatch error ../../Headers/Foundation/NSException.h:48:2: error: "gnustep-base is configured to use 'traditional' exceptions, but you are building for 'native' exceptions." but how?? maybe there is some trick missing... or configure doesn't "force" clang I got around with this: ./configure OBJCFLAGS=-fno-objc-exceptions but this is inconvenient if I have to add it to every thing I need to configure/compile. Do you think we can do this automatic with gnustep make? or maybe we already have some wizardy but it isn ot working? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Issues linking on NetBSD and Clang
Hi, I have upgraded to NetBSD 8 on x86. This means I updated userland as well as dependencies, thus I need to reconfigure and rebuild also GNUstep. I configured to use clang and libobjc2 this way: ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu CC=clang CXX=clang++ knowing that we have issues with "gnu" I used "ng". This should enable the modern runtime, right? However, when configuring base, I get an issue: configure:7855: checking whether objc really works configure:7875: clang -o conftest -g -O2 -I/Local/Library/Headers -I/Local/Library/Headers -I/System/Library/Headers -I/usr/pkg/include -I/System/Library/Headers -x objective-c -L/Local/Library/Libraries -L/Local/Library/Libraries -L/System/Library/Libraries -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -L/System/Library/Libraries conftest.c -lrt -lpthread -rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-1.8 -fblocks -L/home/multix/GNUstep/Library/Libraries -L/Local/Library/Libraries -L/System/Library/Libraries -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lpthread -lobjc -lm -lpthread >&5 In file included from conftest.c:104: In file included from ././config/config.objc.m:2: ././config/objc-common.g:54:3: warning: assignment to Objective-C's isa is deprecated in favor of object_setClass() [-Wdeprecated-objc-isa-usage] obj->isa = self; ^ ~~~ object_setClass( , ) ././config/objc-common.g:47:5: note: instance variable is declared here id isa; ^ 1 warning generated. /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_GetDataRelBase' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_SetGR' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_GetLanguageSpecificData' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_DeleteException' /System/Library/Libraries/libobjc.so: undefined reference to `__gcc_personality_v0' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_Resume_or_Rethrow' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_RaiseException' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_SetIP' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_GetRegionStart' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_GetTextRelBase' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_Resume' /System/Library/Libraries/libobjc.so: undefined reference to `_Unwind_GetIP' clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) configure:7875: $? = 1 I wonder why "gcc personality" ? I am confused. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
libs-base fails to compile on OpenBSD
Hi, I just upgraded OpenBSD to 6.4, including all packages. The compiler did not change in revision, I guess it was just updated, so gcc is still 4.9 from ports. I recompile GNUstep from scratch and it fails: Compiling file runtime.c ... In file included from runtime.c:35:0: /usr/include/objc/objc-api.h:365:1: error: unknown type name 'retval_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:365:34: error: unknown type name 'arglist_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:440:33: error: unknown type name 'MetaClass' Method_t class_get_class_method(MetaClass _class, SEL aSel); ^ /usr/include/objc/objc-api.h: In function 'class_get_class_name': /usr/include/objc/objc-api.h:476:10: error: dereferencing pointer to incomplete type return CLS_ISCLASS(_class)?_class->name:((_class==Nil)?"Nil":0); I suspect something wrong in gcc, but since it stayed to the same version since previous OpenBSD, I do wonder! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Sebastian Reitenbach wrote: What platform are you on? Why don’t you take the path the packages take and use base clang, and libobjc2? because libobjc2 I always have issues with that setup or clang or something. I like to use GCC and its runtime. I definitely don’t recommend to use the system libobjc, at least you seem to pick up system libobjc headers. You have a point here, it is not picking up the correct headers - I am not using the system GCC but the one from packages (gcc 4.9) which is a perfctly fine runtime and which worked in OpenBSD 6.3 (as well as on many other systems, FreeBSD, Linux... etc) With GCC no extra path is needed usually, it should just pick up "its own" runtime" Making all for subproject ObjectiveC2... egcc runtime.c -c \ -MMD -MP -Wall -Wdeclaration-after-statement -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -pthread -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -I/System/Library/Headers/ObjectiveC2 -I../. -I../ -I../../Headers -I. -I/home/multix/GNUstep/Library/Headers -I/Local/Library/Headers -I/System/Library/Headers -I/usr/local/include -I/Local/Library/Headers -I/Local/Library/Headers -I/System/Library/Headers -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/local/include/p11-kit-1 \ -o obj/ObjectiveC2.obj/runtime.c.o In file included from runtime.c:35:0: /usr/include/objc/objc-api.h:365:1: error: unknown type name 'retval_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:365:34: error: unknown type name 'arglist_t' retval_t objc_msg_sendv(id, SEL, arglist_t); If I look for the file, rohan$ sudo find /usr -name objc-api.h /usr/include/objc/objc-api.h /usr/src/gnu/gcc/libobjc/objc/objc-api.h /usr/src/gnu/lib/libobjc/libobjc/objc/objc-api.h which is the standard file! however, if I look for objc.h, I find "both" versions: rohan$ sudo find /usr -name objc.h /usr/include/objc/objc.h /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/objc.h /usr/src/gnu/gcc/libobjc/objc/objc.h /usr/src/gnu/lib/libobjc/libobjc/objc/objc.h objc-api.h seems to have disappeared! But I checked against latest gcc8 on debian linux and the file is not there. Perhaps we should not include it at all? Or stop including it from a certain version of GCC onwards because it does not exist? I can skip that, but then I hit another header... and then redefinitions. I actually wonder how this all worked before. It looks as if there is only one compiler, it works, but if two are installed, a mess ! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, Wolfgang Lux wrote: I haven't been using OpenBSD for years, so I'm not sure why there is an /usr/include/objc header directory that does not match the compiler. But anyway, this is a problem that you'll see on every system where you use a gcc version which does not match the default compiler. Gcc knowns about the special directory containing the Objective-C headers and includes that in the default search path. However, that applies only to Objective-C files and not to plain C files like runtime.c. I think the best way to move forward would be renaming runtime.c into runtime.m so that this file gets compiled with the correct search path. it could be a trick... I think here it is a little more awkward, however: the "pkg" gcc is in its own directory: /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/objc.h The system gcc, is system-wide in the search path: /usr/include/objc/objc.h Now, I suppose the GCC trick is that including "objc.h" works correctly. However, if you include objc-api.h, which does not exist anylonger in more recent versions of gcc, it will include the "Old" one because it is the only one and it is in a valid search path, do you get my reasoning? I think we should include the "right" system headers in runtime, perhaps some should not be included or we should have some sort of "if gcc < XX" include one set, else other set (I don't know which version9. Instead, we check header-per-header and "somewhere" they will be found and then pulled in. I am sure thus your .m trick would work? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, Wolfgang Lux wrote: To be honest, no. The runtime.c file unconditionally includes objc-api.h, so it's obviously not supposed to compiled with a compiler that lacks the objc-api.h header file. So it doesn't really matter if the compiler would find the header from a different compiler version because the file shouldn't be compiled in the first place.:-) indeed this is tricky. First I tried renaming runtime.c to runtime.m and compile it with ObjC. It does not fix the issue. then I tried including thr.h instead of objc-api.h and thr.h, but it is not enough, one symbnol I miss is in runtime.h If I include that, I get tons of redefinitions, likle this: In file included from runtime.m:36:0: /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/runtime.h:284:20: error: conflicting types for 'object_getIndexedIvars' objc_EXPORT void * object_getIndexedIvars (id object); ^ I wonder a bit what kind of magic we are doing there: I actually wonder how it works elsewhere where I use even more modern GCC. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Fred, Fred Kiefer wrote: Riccardo, you seem to be missing out on the underlying problem that Wolfgang tried to explain. For the GNUstep base library there are two cases which are supported. Either a new Obj-C runtime is installed on your machine then this gets used and the GNUstep additions won’t be needed. Or you only have an old Obj-C runtime, then the additions get compiled so that base is able to use the new functions although the runtime does not provide them. In your case a new runtime and an old one are present. Somehow both are detected and the additions get compiled against the new runtime. This has never been supported and is totally useless. Your unusual setup seem to trigger a bug in the configurations scripts where the wrong runtime gets used to decide whether or not to compile the additions. The best you could do now is just to remove the old runtime and everything should be detected correctly. I may be stubborn, but I do not understand where I have the "new" runtime. I have on my system two runtimes 1) old GCC 4.2 runtime installed in "system" /usr/include 2) newer GCC 4.9 runtime installed in /usr/local I do not have a the libobjc-2 runtime installed at all. removing the system one is not trivial, but for the sake of testing, I renamed /usr/include/objc so that it doesn't get found. I rerun configure, this is the output: checking the Objective-C runtime... GNU checking for custom shared objc library... NONE checking objc/runtime.h usability... yes checking objc/runtime.h presence... yes checking for objc/runtime.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes this sounds plausible. Compilation fails: Making all for subproject ObjectiveC2... Compiling file runtime.c ... runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory #include ^ compilation terminated. which is expected, the gcc 4.9 runtime does not have that file... nor does it have gcc 6.5 or 8.2 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, Wolfgang Lux wrote: Am 18.12.2018 um 22:01 schrieb Riccardo Mottola : Making all for subproject ObjectiveC2... Compiling file runtime.c ... runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory #include ^ compilation terminated. which is expected, the gcc 4.9 runtime does not have that file... nor does it have gcc 6.5 or 8.2 Right. The ObjectiveC2 library is supposed to provide a compatibility interface layer around the historic GNU runtime API, providing API calls compatible with Apple's new ObjectiveC-2 runtime API. This Objective-C runtime bundles with gcc has been updated in gcc 4.6 IIRC, so the ObjectiveC2 directory shouldn't be compiled in the first place when you are using anything newer than gcc 4.6. Perhaps there's an issue with the configure script so that the ObjectiveC2 library incorrectly gets compiled on your system? Let me resurrect this thread - I was busy and did not use OpenBSD for a while, now I wanted to and hit this issue again, I am on a different laptop (x64 vs x86) but that doesn't matter I suppose. renamed /usr/include/objc so that it is not found, I don't care about using the system compiler, I only want to use gcc from pkg (why it is 4.9, I don't know... OpenBSD decisions). For the record, the "make" configure line is: $ ./configure --prefix=/ --with-layout=gnustep CC=egcc CXX=eg++ LDFLAGS=-Wl,-R/usr/local/lib egcc being the name for the newer gcc installed. (4.9 that is). The objc is in: /usr/local/lib/gcc/x86_64-unknown-openbsd6.4/4.9.4/include/objc which is, AFAIK, correct. The base configure script reports: checking the Objective-C runtime... GNU checking for custom shared objc library... NONE checking objc/runtime.h usability... yes checking objc/runtime.h presence... yes checking for objc/runtime.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes 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... no checking for objc_setProperty... no checking for _Block_copy... no 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) no this looks all correct? However, afterwards it fails as we had past month: Compiling file runtime.c ... runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory #include ^ compilation terminated. You suggested this all should not be built at all, but which test is getting confused? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
error compiling latest base on FreeBSD (ihex)
Hi, just tried to updated base on FreeBSD-amd64 /clang but it fails. I did re-run configure. Linking tool cvtenc ... Compiling file AGSParser.m ... ../Source/./obj/libgnustep-base.so: undefined reference to `ishex' clang: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [/System/Library/Makefiles/Instance/tool.make:89: obj/cvtenc] Error 1 Any clues? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error compiling latest base on FreeBSD (ihex)
Hi Richiard! Richard Frith-Macdonald wrote: Seems likely to be related to pollution of the global namespace with new functions (though the error message appears to suggest the opposite). I changed that code (getting rid of ishex while fixing a couple of other issues); please try now. it compiled+linked now! I have now an issue in back, will I report separately! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
issue compiling Back (undeclared identifier)
Hi, on the same FreeBSD/amd64 - clang setup, I get an undeclared itendifier Compiling file XGServerEvent.m ... XGServerEvent.m:730:52: error: use of undeclared identifier 'GSAppKitAppHide' subtype: GSAppKitAppHide ^ 1 error generated. gmake[5]: *** [/System/Library/Makefiles/rules.make:479: obj/x11.obj/XGServerEvent.m.o] Error 1 It is apparently introduced by commit b492ac87cd07046c8d9ca88fcb5e9bb44e39c32c of 5 April. How does it compile for others? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: issue compiling Back (undeclared identifier)
Hi Sergii, Sergii Stoian wrote: You need to recompile reinstall libs-gui from master branch. `GSAppKitAppHide` is defined in AppKit/NSEvent.h indeed, that was enough. I actually did it, but some issue with git and install happened, a new GUI install fixed the issue. I always update base->gui->back in that order since many many years now! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
PCButton - tracking rect
Hi all, in ProjectCenter's PCButton access to private ivar _tracking_rects is done (actually in our header it is PACKAGE_SCOPE , I don't know exactly, but it must translate into private). How could I avoid that? apparently it is a hard error on latest clang, but it is ugly anyway. I found no public method for accessing it. Apparently, this is all done for tooltip management... I wonder if it is needed at all, I don't understand what the code is doing special there, don't have Buttons standard toolitps? Thank you, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PCButton - tracking rect
Hi Sergii, Sergii Stoian wrote: Hi Riccardo, I've wrote tooltips for ProjectCenter PCButton's implementation. After that someone has copied this implementation into NSView. I looked into ProjectCenter sources long time ago. I was convinced that PCButton's private tooltips implementation was replaced with NSView's. thank you, I will then try to remove the custom implementatino and use the standard and see that everything still works! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PCButton - tracking rect
Hi Sergii, Sergii Stoian wrote: I've wrote tooltips for ProjectCenter PCButton's implementation. After that someone has copied this implementation into NSView. I looked into ProjectCenter sources long time ago. I was convinced that PCButton's private tooltips implementation was replaced with NSView's. I removed the custom ToolTip implementation in PCButton and removed the custom stuff. Now, very little of PCButton remains, just some graphic settings, essentially. The good news is that it works as before. The bad news is that there were certain bugs in the tooltips and they remain :) This means.. that the NSView implementation has taken them over 1 to 1. With windowmaker, some tooltips work, sometimes they don't show, the behaviour is - move pointer over button - TT doesn't show - while it doesn't show, the WindowMaker icon gets grey (looses Application Icon) and sometimes even jumps (focus lost?) - slight mouse move over the same "target", ToolTip appears and WindowMaker shows app icon again, everything fixed I remember discussing this a while back with Fred. Do you notice that too? I'm testing with ProjectCenter, I will look for other apps that have tooltips, but now PC should be really "standard". Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PCButton - tracking rect
Hi Sergii, It is not easy to reproduce On 2019-05-22 10:34:36 + Sergii Stoian wrote: With windowmaker, some tooltips work, sometimes they don't show, the behaviour is - move pointer over button - TT doesn't show In my case, TT moves with mouse cursor (as it should). Here too, once it shows. By the first time the mouse is on the button, the TT may not show, with the behaviour I will describe again. If then he mouse is moved again, it will show and then track as it should. - while it doesn't show, the WindowMaker icon gets grey (looses Application Icon) and sometimes even jumps (focus lost?) I didn't quite understand what you mean by "gets gray" - it becomes stippled/highlighted as when application starts, just tile remains without application icon or appicon completely disappears? - slight mouse move over the same "target", ToolTip appears and WindowMaker shows app icon again, everything fixed I can't reproduce it. But my setup: - based on gui/back 0.25.0 - use ART backend; - parts of WindowMaker I've incorporated into NEXTSPACE's Workspace contains my fixes and enhancements (including focus handling area); What is your setup? Could you try to reproduce this with ART backend? If you use master branch of gui/back you should observe problems with text drawing (0.25.1 includes NSStringDrawing rewrite and broke ART in that area) but window management should be OK. I'm afraid I need a couple of weeks to create alternate setup. I'm busy with preparing of NEXTSPACE 0.85 release now. I still have one laptop wth ART and tried, the behaviour is slightly different (no grey icon) but the tooltip doesn't show sometimes and will show by moving the mouse again. That is, regarding the Button and TT, it behaves the same The behaviour is - start with a minimal desktop of windowmaker, no other apps besides xterm - move with one continous movement the mouse on a ProjectCenter button (I use the toolbar) - the second or third button (but usually the first time it works) * the tooltip doesn't show * on certain systems, at the same time, the app icon becomes totally grey, that is, it looses even the standard icon it had (e.g. the ProjectCenter icon), totally empty and stays so. As if WindowMaker had no clue about which app it was... * moving the mouse on the same button (or sometimes waiting long...) makes the ToolTIp appear and, in case, the Application Icon comes again! Added confusion: opening apps (non-gnustep) , e.g. a browser and other windows and getting back to ProjectCenter everything seems to work! TT shows! closing the other apps keeps PC working TT, however clong and restarting PC, makes it act up again. That is, no restart of WindowMaker is needed to "reproduce" the issue. It doesn't look cairo or art depdent. Also, I tried on another system where I run XFCE and the issue doesn't happen, so I think it is indeed an interaction with WindowMaker. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Errors compiling Libobjc2
Hi I am trying to buid libobjc2 source on OpenBSD. I am using the system compiler clang 7.0.1, I have installed gnustep-make and configured with ng-gnu-fnu compilation fails though: [ 11%] Built target WeakImportClass_optimised Scanning dependencies of target objc_msgSend [ 11%] Building C object Test/CMakeFiles/objc_msgSend.dir/objc_msgSend.m.o [ 11%] Linking C executable objc_msgSend ld: error: undefined symbol: _Unwind_Resume >>> referenced by objc_msgSend.m >>> CMakeFiles/objc_msgSend.dir/objc_msgSend.m.o:(main) cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error 1 in . (Test/CMakeFiles/objc_msgSend.dir/build.make:98 'Test/objc_msgSend') *** Error 2 in . (CMakeFiles/Makefile2:6645 'Test/CMakeFiles/objc_msgSend.dir/all') *** Error 2 in /home/multix/code/gnustep-svc/libobjc2/Build (Makefile:163 'all') matrix$ clang --version OpenBSD clang version 7.0.1 (tags/RELEASE_701/final) (based on LLVM 7.0.1) Target: amd64-unknown-openbsd6.5 Thread model: posix Ideas? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Errors compiling Libobjc2
Hi, On 2019-06-21 16:13:58 + David Chisnall wrote: On 21/06/2019 16:08, Riccardo Mottola wrote: ld: error: undefined symbol: _Unwind_Resume It looks as if your toolchain doesn't automatically link anything that provides the exception ABI. On most *NIX systems this comes from something called libgcc_s.so (which, on FreeBSD, is actually LLVM's compiler-rt - on some platforms it's installed as such). What happens when you compile a C program that uses -fexceptions and __attribute__((cleanup)) on OpenBSD? Does it link something that provides these symbols? I did some research and found that Unwind_Resume is in libc++, however to get all Unwind symbols, libc++abi is needed. Thus, if I build libobjc2 with: cmake .. -DCMAKE_EXE_LINKER_FLAGS=-lc++abi it will build and link. Why it is needed, I don't know, but other projects have the same recent on recent OpenBSD since the clang switch. However, I get then the same error when linking tools and apps, THus I tried to pass -lc++abi also for base, but then I get Compiling file Unicode.m ... Linking subproject Additions ... clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument] ld: error: attempted static link of dynamic object /usr/bin/../lib/libc++abi.so.0.1 clang: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [/System/Library/Makefiles/Instance/subproject.make:61: obj/subproject.o] Error 1 gmake[3]: *** [/System/Library/Makefiles/Instance/subproject.make:45: internal-subproject-all_] Error 2 so, perhaps this is the right track, but I couldn't figure out the complete solution. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Missing header file in base?
Hi, if I compile base, I get this error: Compiling file NSMetadata.m ... In file included from NSMetadata.m:35: ../Headers/Foundation/NSMetadata.h:33:9: fatal error: Foundation/NSMetadataAttributes.h: No such file or directory 33 | #import | ^~~ compilation terminated. make[4]: *** [/mingw64/System/Library/Makefiles/rules.make:479: obj/libgnustep-base.obj/NSMetadata.m.o] Error 1 make[3]: *** [/mingw64/System/Library/Makefiles/Instance/library.make:278: internal-library-all_] Error 2 and indeed the file is not there in the git checkout. Riccardo
Re: Missing header file in base?
Hi, Gregory Casamento wrote: LOL, bogus commits. This should be fixed now. indeed. I fixed another small thing that impaired GCC compilation and then found out that GUI wouldn't build either. "core" should really be built fully to test things end-to-end. I believe it is fixed now. I could compile up to GWorkspace and it runs fine. Riccardo
Re: Embedded blocks...
Hi, Yavor Doganov wrote: В Tue, 29 Oct 2019 12:50:23 +, David Chisnall написа: I don't really understand how this works. GCC does not support a post-2005 dialect of Objective-C. GNUstep is a framework that aims to provide an implementation of the 2019 Objective-C standard library. Why is it politically problematic for GNUstep to drop support for GCC, but not problematic for GCC to drop support for GNUstep? But GCC didn't drop support for GNUstep. It just cannot cope with the changes of the language/runtime that are completely under the control of a single corporation. It is not surprising that the last major changes in GCC related to Objective-C were implemented by GNUstep developers (Nicola and Richard, IIRC). I would hate to be dependent on clang. I actually like the situation where we have two compilers. On many OS/arch combinations I use... one compiler is better than the other. I like this freedom. GNU-step GNU-compiler for me is a good match, but being able to use clang is a good add, the other way, I don't feel comfortable. Basically, the only target market is GNUstep developers on platforms that Clang doesn't support, which I think is a set containing only Riccardo). This is an exaggeration. I fixed a bug in SOPE on SuperH just a few months ago. Over the years, I recall fixes in GNUstep core libraries on HP-PA, GNU/Hurd and GNU/kFreeBSD, to name a few. And non-core packages on sparc, ppc, ppc64, powerpcspe and m68k. GNUstep aims for portability and this is closely related with code quality. Once you start dropping targets for no good reason you can expect regressions in quality here and there, and more effort when the need to support a new architecture arises. I subscribe to this. Thank you for stepping in, or it looks like me being "the only one" which is not true. I happen to be the only one writing actively to this group and being member of the core team, but there are others which just are "silent". I don't use GNUstep on m68k since years.. because I was unable to upgrade my machine to a more recent debian, font memories :-P However my interest in PPC revived a lot since I am member of the PPC (Power Progress Community) and GCC is currently a better compiler for that platform. On SPARC the same (to be honest, I didn't even try clang there yet) I still need to play on MIPS LE.. and will test compilers there. Availability of these boards has risen the multitude of platforms again, exciting. В Wed, 30 Oct 2019 01:27:56 +0200, Sergii Stoian написа: IMHO political motifs shouldn’t constrain technical decisions Well, the goal of the GNU Project is technical but that goal is set because of an ideal and GNU maintainers are supposed to exercise proper judgment when making decisions on technical matters, too. Well... this could be discussed, the whole GNU project can be said "political" (see quotes) if not at least ideological. Several projects and libraries were formed just because one didn't a specific license. One could say that the whole Free Software is born out of "politcal reasons." Moreover using these nice Objective-C 2.0 features make GNUstep code look much more familiar to potential macOS/iOS developers. It is extremely naive to expect that macOS/iOS developers will start coming in numbers, anxious to implement classes and missing functionality, just because of that. GNUstep predates the thing called "Objective-C 2.0" and I don't remember an avalanche of patches flowing in before 2005. They won't... the cool thing is Swift anyway... or Rust or whatever if you like chaning language every day. But some occasional MacOS dev could peek by. I like the cleanieness of Obj-C 1.0 except some compromises it had. (Likewise, it was foolish to presume that the move to GitHub will install an entire new generation of energetic programmers. The reality is that pretty much the same small set of heroic people are doing the work.) Here, even if I don't like GitHub, I must say that it helps in exposure, the code is easier to browse and even if a hoard of programmers won't materialize because GNUstep's appeal is a niche, we can get more report and exposure. Here a can of worm opens about the bad interface of code comments or comments on patches of GitHub opens. So... I don't like the "tool" but the fact that it is of ease is true. I myself have contributed easily wth code and patches to other project just because their "home" was consistent and easy. GitHub or equivalent gitlab environment make that easy. Having two bug trackers, a code in another place and releases in yet another... do not help. Not a real issue, mind you, but don't help for sure. Riccardo
base fails to compile with gcc
Hi, our base is not compiling on Debian with current gcc 9.2. The latter errors are certainly for Blocks being used enyway, but the first error about NSSet confuses me. I fixed NSError not being found because a missing header, but that is not enough. Making all for library libgnustep-base... Compiling file NSXPCConnection.m ... In file included from NSXPCConnection.m:25: ../Headers/Foundation/NSXPCConnection.h:36:62: error: expected ‘;’ before ‘<’ token 36 | @class NSMutableDictionary, NSString, NSOperationQueue, NSSet, NSLock, NSError; | ^ | ; In file included from ../Headers/Foundation/NSObjCRuntime.h:41, from ../Headers/Foundation/NSObject.h:30, from ../Headers/Foundation/NSXPCConnection.h:28, from NSXPCConnection.m:25: ../Headers/Foundation/NSXPCConnection.h:40:49: error: unknown type name ‘NSError’ 40 | DEFINE_BLOCK_TYPE(GSXPCProxyErrorHandler, void, NSError *); | ^~~ ../Headers/GNUstepBase/GSBlocks.h:68:28: note: in definition of macro ‘DEFINE_BLOCK_TYPE’ 68 | retTy (*invoke)(void*, argTys, ## __VA_ARGS__);\ | ^~ ../Headers/GNUstepBase/GSBlocks.h:69:3: warning: no semicolon at end of struct or union 69 | } *name | ^ ../Headers/Foundation/NSXPCConnection.h:40:1: note: in expansion of macro ‘DEFINE_BLOCK_TYPE’ 40 | DEFINE_BLOCK_TYPE(GSXPCProxyErrorHandler, void, NSError *); | ^ ../Headers/Foundation/NSXPCConnection.h:41:51: error: ‘void’ must be the only parameter 41 | DEFINE_BLOCK_TYPE(GSXPCInterruptionHandler, void, void); | ^~~~ ../Headers/GNUstepBase/GSBlocks.h:68:28: note: in definition of macro ‘DEFINE_BLOCK_TYPE’ 68 | retTy (*invoke)(void*, argTys, ## __VA_ARGS__);\ | ^~ ../Headers/Foundation/NSXPCConnection.h:42:51: error: ‘void’ must be the only parameter 42 | DEFINE_BLOCK_TYPE(GSXPCInvalidationHandler, void, void); | ^~~~ ../Headers/GNUstepBase/GSBlocks.h:68:28: note: in definition of macro ‘DEFINE_BLOCK_TYPE’ 68 | retTy (*invoke)(void*, argTys, ## __VA_ARGS__);\ | ^~ In file included from NSXPCConnection.m:25: ../Headers/Foundation/NSXPCConnection.h:85:49: error: expected ‘)’ before ‘^’ token 85 | - (id) remoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler; | ^ | ) ../Headers/Foundation/NSXPCConnection.h:85:51: error: expected ‘)’ before ‘(’ token 85 | - (id) remoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler; | ^ | ) ../Headers/Foundation/NSXPCConnection.h:87:60: error: expected ‘)’ before ‘^’ token 87 | - (id) synchronousRemoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler; | ^ | ) ../Headers/Foundation/NSXPCConnection.h:87:62: error: expected ‘)’ before ‘(’ token 87 | - (id) synchronousRemoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler; | ^ | ) NSXPCConnection.m:90:49: error: expected ‘)’ before ‘^’ token 90 | - (id) remoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler | ^ | ) NSXPCConnection.m:90:51: error: expected ‘)’ before ‘(’ token 90 | - (id) remoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler | ^ | ) NSXPCConnection.m:95:60: error: expected ‘)’ before ‘^’ token 95 | - (id) synchronousRemoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler | ^ | ) NSXPCConnection.m:95:62: error: expected ‘)’ before ‘(’ token 95 | - (id) synchronousRemoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler | ^ | ) make[4]: *** [/System/Library/Makefiles/rules.make:479: obj/libgnustep-base.obj/NSXPCConnection.m.o] Error 1
Re: base fails to compile with gcc
Fred Kiefer wrote: I fixed these places. Bugs like this could easily be avoided by using branches and pull requests and having the travis CI test the build on different environments. But this did not happen. Looks like somebody wants to stop compilation of GNUstep with gcc. Thanks Fred. Tested and worked. Why "blocks" are a GCC issue, I do wonder how clang could compile the missing NSError.h - it looks a partial push was done or a push was done before performing a build! Riccardo
Re: Gitflow proposal
Hi, Fred Kiefer wrote: Also it won’t work. Nobody is getting payed to review pull requests on GNUstep. If I started to write pull requests for GNUstep gun, they would be sitting there for a year or so without anybody noticing. "gun" ??? git is a gun? :) But I agree, there are no paid reviewers here. Theoretically, maintainers of every package should do that, but it is too much to ask. Even at work, people getting in charge of code reviews of pullr equest can get a high level of stress! As Richard stated in another mail - complex comments are long to write and discussions inside comments can be even worse than per mail, chat or phone! The bigger problem is that even Gitflow won’t help us with our quality issues. Over the last few months I have tried to provide comments to most of the pull requests in the GNUstep repository. I do this a lot at work and doing so comes naturally to me. Most of the developers react positive by fixing the issues I point to. There is one exception and please look it up in git to see the difference. In that case many of my comments did get ignored others, where flagged as done although no change was made and sometimes branches where merged even when travis reported them as broken or while I had objected merging them. So even a workflow that enforces all this is of no use in this case. This is precious work, Fred. One thing though: I really hate hoe comments are managed. I don't have a clear list of comments to review, re-read, etc. They can be both in a PR (which is easier) or also on just a commit, in that case with the github UI is a mess. I loose track, so I actually rely on the emails I get for the comments and link-open to find the reference on the code again. So it is a complicated way to handle things. Generally speaking, however, this setup has several advantages in control, but is timeconsuming. At work, I think a full set up gets very bureaucratic. # stable trunk -- "devel" trunk wtih merges of all the feature branches > bug fix branch > feature branch 1 > feature branch 2 but, since here we don't work with a whole load of sub-contractors and developers, I'd prefer something more simple! And it could be even worse. With Gitflow in place as a rule, Riccardo and I could have been stopped from doing the emergency fixes we did last night to get master compiling again (and not only for gcc, Riccardo's change must have fixed compilation of clang as well). As long as we have rogue developers with full permissions out there, we need ways to counteract. So yes, let's use more branches and pull requests but especially those developers that break the build. And if we ever manage to get them to follow that rules we might start to think about more process. Branches should be used for everything which is a longer-running changes should be a branch and pulled together. Riccardo
Re: base fails to compile with gcc
Hi, Gregory Casamento wrote: Here is a link, for reference: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow Some might argue that this should only be done with large teams, but I used this process on a small team when I worked at a company known as customink where we only had 4 people and it still helped things go very smoothly. This is the process I've been trying to adhere to. I would advocate that, if PRs could have prevented this then, perhaps, we should all move to it. I had a discussion with Riccardo where he thought this process was too much and was silly and that merging to the master branch directly is always the best way to go. That's precisely what caused this. We can make all of the arguments that "a focused developer wouldn't make these mistakes" but that's BS. Process is here to prevent mistakes or to mitigate them. Git Flow Workflow - Release Branches Actually... I might revise what I previsouly said, also because while discussing thigns with Fred and Gregory, I propose essentially the same model, with two "amendments" 1) some minor stuff can also be done directly in "develop" instead of Master (e.g. to follow Richard's flow, to avoid having too many branches) 2) to have us all developers essentially build and compile "develop" which becomes the equivalent of our current trunk Trunk thus becomes the "stable". If we all live on the violet branch, it means that we continue checking stuff. Thus, still keep the mantra that "Develop" should not break, although it is not as bad as "Trunk" What do you think? Riccardo
Issues subclassing NSMutableArray
Hi!
I wanted to subclass NSMutableArray, so that I can easily add some extra
methods.
I declared my subclass like this:
@interface FileArray : NSMutableArray
{
}
However, when I run my app, I get this:
StepSync.app/StepSync: Uncaught exception NSInvalidArgumentException,
reason: [FileArray-addObject:] should be overridden by subclass
I did override all concrete methods in the easiest possible way, calling
super. For addObject I did:
- (void)addObject:(id)anObject
{
[super addObject:anObject];
}
why is this not enough or not working in any case?
Riccardo
Re: Issues subclassing NSMutableArray
Hi Richard, On 11/17/19 4:53 PM, Richard Frith-Macdonald wrote: Because NSMutable array is an abstract class. You need to create a concrete class with actual instance variables to store data in. In your case you overrode the superclass implementation, but did do by calling the superclass implementation ... which is abstract and can't do anything. You have to override the implementation in a way that actually adds the object to a storage area. Than you for the tip. I also had to override "init" in the same fashion you suggested. In layman terms, if you subclass something abstract, there is actually nothing, so there is no storage and you have to "wrap" it yourself and instead of using "super" use the content. Riccardo
Base NSScanner/GSFormat issues - segmentation fault
Hi, on a very plain Linux i386 32bit setup, configured with clang, libobjc2 and ng-gnu-gnu runtime I always had issues with almost everything crashing, this is months old (years?). What happens is this: Program received signal SIGSEGV, Segmentation fault. 0xb757a078 in myGetC (c=) at NSScanner.m:91 91 (void)GSToUnicode(&dst, &size, &c, 1, internalEncoding, 0, 0); Here a Trace. #0 0xb757a078 in myGetC (c=) at NSScanner.m:91 #1 -[NSScanner scanDouble:] (self=, _cmd=out>, value=) at NSScanner.m:823 #2 0xb7ba9056 in +[NSColor(GNUstepPrivate) colorFromString:] (self=, _cmd=, str=) at NSColor.m:1810 #3 0xb7ba5166 in initSystemColors () at NSColor.m:277 #4 +[NSColor initialize] (self=, _cmd=) at NSColor.m:328 #5 0xb7291c58 in objc_send_initialize () from /System/Library/Libraries/libobjc.so.4.6 #6 0xb729db58 in slowMsgLookup () from /System/Library/Libraries/libobjc.so.4.6 #7 0xb72a3b11 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6 #8 0xb7be61d0 in +[NSImage initialize] (self=, _cmd=) at NSImage.m:451 #9 0xb7291c58 in objc_send_initialize () from /System/Library/Libraries/libobjc.so.4.6 #10 0xb729db58 in slowMsgLookup () from /System/Library/Libraries/libobjc.so.4.6 #11 0xb72a3b11 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6 #12 0xb7bbce88 in getStandardCursor (name=, style=) at NSCursor.m:183 #13 0xb7bbcdad in +[NSCursor arrowCursor] (self=0x817d260, _cmd=0xb7ec7174 ) at NSCursor.m:201 #14 0xb7bbcaec in +[NSCursor initialize] (self=0x817d260, _cmd=0x8090918) at NSCursor.m:69 #15 0xb7291c58 in objc_send_initialize () from /System/Library/Libraries/libobjc.so.4.6 #16 0xb729db58 in slowMsgLookup () from /System/Library/Libraries/libobjc.so.4.6 #17 0xb72a3b11 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6 #18 0xb43992d8 in -[XGServer(WindowOps) _initializeCursorForXWindow:] (self=, _cmd=, win=) at XGServerWindow.m:3980 #19 0xb4391ea0 in -[XGServer(WindowOps) _checkStyle:] (self=out>, _cmd=, style=) at XGServerWindow.m:931 #20 0xb4393a34 in -[XGServer(WindowOps) _setupRootWindow] (self=, _cmd=) at XGServerWindow.m:1659 #21 0xb4389ef6 in -[XGServer _initXContext] (self=, _cmd=) at XGServer.m:465 #22 0xb4389fe8 in -[XGServer initWithAttributes:] (self=, _cmd=, info=) at XGServer.m:478 #23 0xb7cd0c44 in +[GSDisplayServer serverWithAttributes:] (self=, _cmd=, attributes=) at GSDisplayServer.m:181 #24 0xb7b65a8f in -[NSApplication _init] (self=0x83be414, _cmd=0xb7ea0b50 ) at NSApplication.m:892 #25 0xb753cc13 in -[NSObject performSelector:withObject:] (self=, _cmd=, aSelector=, anObject=) at NSObject.m:2024 For a long time I worked around this by removing optimization, the minimum was this in base: GSFormat.m_FILE_FILTER_OUT_FLAGS = -O% Now... this hack stopped working for me, GNUstep is "broken". In the meanwhile, I also updated the compiler. it is cloang 8.0.1, no longer clang 6. I hope that if there was some strange compiler bug, it should have been gone. So I start fearing that we have some bad code, but it happens "only" in this setup I have. Any suggestion? Riccardo
Crash in any GUI app
Hi!
I was testing Niels gnustep-make patch and while I discovered the issue
with "gnu-gnu-gnu" and clang-libobjc2, I actually found out that also
ng-gnu-gnu is not working anymore.
On FreeBSD - amd64 / clang, I get this stacktrace:
Program received signal SIGSEGV, Segmentation fault.
0x0008013a38dc in -[GSStandardWindowDecorationView updateRects]
(self=0x808d66e08, _cmd=0x8018dd400)
at GSStandardWindowDecorationView.m:98
98 if (hasTitleBar)
Current language: auto; currently minimal
(gdb) bt
#0 0x0008013a38dc in -[GSStandardWindowDecorationView updateRects]
(self=0x808d66e08, _cmd=0x8018dd400)
at GSStandardWindowDecorationView.m:98
#1 0x0008013a46e3 in -[GSStandardWindowDecorationView
initWithFrame:window:] (self=0x808d66e08, _cmd=0x8018e0888,
frame={origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
w=0x808fd9408)
at GSStandardWindowDecorationView.m:167
#2 0x0008013a67b9 in +[GSWindowDecorationView
newWindowDecorationViewWithFrame:window:] (self=0x808874320,
_cmd=0x801860e38, frame={origin = {x = 0, y = 0}, size = {width =
0, height = 0}}, aWindow=0x808fd9408)
at GSWindowDecorationView.m:77
#3 0x0008012f6862 in -[NSWindow
initWithContentRect:styleMask:backing:defer:] (self=0x808fd9408,
_cmd=0x801860b48,
contentRect={origin = {x = 0, y = 0}, size = {width = 0, height =
0}}, aStyle=64, bufferingType=0, flag=0 '\0')
at NSWindow.m:1077
#4 0x0008012f6c49 in -[NSWindow
initWithContentRect:styleMask:backing:defer:screen:] (self=0x808fd9408,
_cmd=0x8016db960, contentRect={origin = {x = 0, y = 0}, size =
{width = 0, height = 0}}, aStyle=64, bufferingType=0,
flag=0 '\0', aScreen=0x0) at NSWindow.m:1140
#5 0x0008010c3e76 in -[NSApplication(Private) _appIconInit]
(self=0x808bf0e88, _cmd=0x8016db2a0)
at NSApplication.m:3884
#6 0x0008010ba724 in -[NSApplication _init] (self=0x808bf0e88,
_cmd=0x8016da940) at NSApplication.m:932
#7 0x000801ec4c4b in -[NSObject performSelector:withObject:] ()
from /System/Library/Libraries/libgnustep-base.so.1.27
#8 0x000801f60546 in -[NSObject(NSThreadPerformAdditions)
performSelector:onThread:withObject:waitUntilDone:modes:]
() from /System/Library/Libraries/libgnustep-base.so.1.27
#9 0x000801f60256 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from
/System/Library/Libraries/libgnustep-base.so.1.27
#10 0x000801f602d1 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:] ()
from /System/Library/Libraries/libgnustep-base.so.1.27
#11 0x0008010baa7f in -[NSApplication init] (self=0x808bf0e88,
_cmd=0x8016db180) at NSApplication.m:986
#12 0x0008010ba300 in +[NSApplication sharedApplication]
(self=0x808ac57a0, _cmd=0x8016c58c0) at NSApplication.m:858
#13 0x000801091ccd in NSApplicationMain (argc=1,
argv=0x7fffe7b0) at Functions.m:78
I don't think this has any relations to the runtime options checking,
hasn't it?
Riccardo
Re: Crash in any GUI app
Hi, Sergii Stoian wrote: I seems like old fixed bug in libobjc2. Look here https://github.com/gnustep/libobjc2/issues/96. What version of libobjc2 are you using? I'm using the one I got from FreeBSD, libobjc2-2.0_1 Replacement Objective-C runtime supporting modern Objective-C features So if the fix is from March 27, 2019 I bet I don't have it. Darn. I can't upgrade FreeBSD ont his box because it breaks TONS of other things I can try on my other computer if packages got updated. There an "upgrade" release already broke important stuff for me. Riccardo
Re: Base NSScanner/GSFormat issues - segmentation fault
Hi, Fred Kiefer wrote: To me this sounds like a compiler issue. The best you can do is get clang to create assembler output (-S for gcc, most likely it is the same) and pass the result for this small function on to David. As a workaround you may try to extend your little hack to cover NSScanner.m as well. That is: A compiler issue carrying over a long time... and happens only on this laptop? I wonder... but if we can confirm it is that, I will try to work with David with that. NSScanner.m_FILE_FILTER_OUT_FLAGS = -O% I did that and I still get a segmentation fault, but in a different place. #0 0xb75a4932 in -[NSTimer initWithFireDate:interval:target:selector:userInfo:repeats:] (self=0x84f5424, _cmd=0xb788f404 , fd=0x0, ti=30, object=0x84e99c4, selector=0x0, info=0x0, f=1 '\001') at NSTimer.m:120 #1 0xb757425f in +[NSRunLoop _runLoopForThread:] (self=, _cmd=, aThread=) at NSRunLoop.m:784 #2 0xb75742c5 in +[NSRunLoop currentRunLoop] (self=, _cmd=) at NSRunLoop.m:811 #3 0xb7573fff in +[NSRunLoop initialize] (self=0x81096f0, _cmd=0x8090918) at NSRunLoop.m:747 #4 0xb7290c58 in objc_send_initialize () from /System/Library/Libraries/libobjc.so.4.6 #5 0xb729cb58 in slowMsgLookup () from /System/Library/Libraries/libobjc.so.4.6 #6 0xb72a2b11 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6 #7 0xb438a084 in -[XGServer(EventOps) setupRunLoopInputSourcesForMode:] (self=, _cmd=, mode=) at XGServerEvent.m:227 #8 0xb4389003 in -[XGServer initWithAttributes:] (self=, _cmd=, info=) at XGServer.m:480 #9 0xb7cd0c44 in +[GSDisplayServer serverWithAttributes:] (self=, _cmd=, attributes=) at GSDisplayServer.m:181 #10 0xb7b65a8f in -[NSApplication _init] (self=0x83be424, _cmd=0xb7ea0b50 ) at NSApplication.m:892 #11 0xb753bc13 in -[NSObject performSelector:withObject:] (self=, _cmd=, aSelector=, anObject=) at NSObject.m:2024 #12 0xb75a42ac in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] ( self=, _cmd=, aSelector=out>, aThread=0x82fe384, anObject=, aFlag=, anArray=) at NSThread.m:2164 #13 0xb75a3e34 in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] ( self=, _cmd=, aSelector=out>, anObject=, aFlag=, anArray=) at NSThread.m:2119 #14 0xb75a3e7c in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] ( self=, _cmd=, aSelector=out>, anObject=, aFlag=) at NSThread.m:2130 #15 0xb7b66088 in -[NSApplication init] (self=, _cmd=) at NSApplication.m:986 #16 0xb7b659fe in +[NSApplication sharedApplication] (self=out>, _cmd=) at NSApplication.m:858 #17 0xb7b4d347 in NSApplicationMain (argc=, argv=) at Functions.m:78 #18 0x0804b220 in main (argc=, argv=, env=) at main.m:33 Riccardo
Re: Base NSScanner/GSFormat issues - segmentation fault
Hi all, hi Fred. I went further. I disabled all optimizations and rebuilt whole base. (Is there any easier way than editing config.make manually?) I get now this fat stacktrace: Program received signal SIGSEGV, Segmentation fault. 0xb3d58101 in xcb_writev () from /usr/lib/libxcb.so.1 (gdb) bt #0 0xb3d58101 in xcb_writev () from /usr/lib/libxcb.so.1 #1 0xb3ef52be in _XSend () from /usr/lib/libX11.so.6 #2 0xb3ef58b1 in _XReply () from /usr/lib/libX11.so.6 #3 0xb3edb31e in XGetWindowProperty () from /usr/lib/libX11.so.6 #4 0xb3eda113 in XGetIconSizes () from /usr/lib/libX11.so.6 #5 0xb42e145a in -[XGServer(WindowOps) iconSize] (self=, _cmd=) at XGServerWindow.m:4612 #6 0xb7cfa52f in GSGetIconSize () at GSIconManager.m:88 #7 0xb7b64c10 in +[NSAppIconView initialize] (self=, _cmd=) at NSApplication.m:532 #8 0xb71db018 in objc_send_initialize () from /System/Library/Libraries/libobjc.so.4.6 #9 0xb71e6f18 in slowMsgLookup () from /System/Library/Libraries/libobjc.so.4.6 #10 0xb71ece81 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6 #11 0xb7b6c005 in -[NSApplication(Private) _appIconInit] (self=, _cmd=) at NSApplication.m:3903 #12 0xb7b65cdf in -[NSApplication _init] (self=0x83bdfe4, _cmd=0xb7ea0b50 ) at NSApplication.m:932 #13 0xb752a9f8 in -[NSObject performSelector:withObject:] (self=0x83bdfe4, _cmd=0xb789a6b0 , aSelector=0xb7ea0b50 , anObject=0x83bdfe4) at NSObject.m:2024 #14 0xb75d4953 in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] ( self=0x83bdfe4, _cmd=0xb789a6a0 , aSelector=0xb7ea0b50 , aThread=0x82fdf44, anObject=0x83bdfe4, aFlag=1 '\001', anArray=0x83cc494) at NSThread.m:2164 #15 0xb75d45cc in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] ( And, most importantly, I just installed libobjc2 from GIT! I somehow remember this issue, do you Fred? Riccardo
warning in base with gcc
Hi!
when compiling base with GCC I see this warning
NSOperation.m: In function '-[NSBlockOperation main]':
NSOperation.m:581:19: warning: assignment to 'GSBlockOperationBlock'
{aka 'struct *'} from incompatible pointer type 'i'
[-Wincompatible-pointer-types]
while((theBlock = [en nextObject]) != NULL)
maybe it is bogus with our block macros, but why?
I wonder what the type "i" is.
Riccardo
compiling GNUstep on OpenBSD - various compiler/runtime options
ithmetic exception. 0x02b46e5fd66f in ?? () from /usr/libexec/ld.so (gdb) bt #0 0x02b46e5fd66f in ?? () from /usr/libexec/ld.so #1 0x02b44f363c00 in ?? () #2 0x in ?? () Riccardo
Re: compiling GNUstep on OpenBSD - various compiler/runtime options
Hi, On 1/3/20 11:08 AM, Richard Frith-Macdonald wrote: 1) gcc + own runtime (make detects this config all by itself) 2) gcc + libobjc2 (make configured with gnu-gnu-gnu) 3) clang + libobjc2 and make configured gnu-gnu-gnu 4) clang + libobjc2 and make configured ng-gnu-gnu The introduction of the ng runtime specification was supposed to mean that we*don't* have those four options: it means we support only two setups (1) and (4) above. The combinations you list as (2) and (3) are unsupported/invalid because 1. means the original (also called legacy) objc 4. means all the latest next-gen stuff (next-gen because we didn't want to use the objc-2.0 lable) There's nothing in between as a simple recognition of the realities of what compiler works reliably with each runtime. In practice, clang may be able to build code for the old runtime (so individuals might get 3 to work for them, but we can't support them) Ok. I went overboard with options then :-P I'm fine with 3) being useless, I just did try all combinations out of curiosity. I actually think 2) makes some sense and it used to be supported, at least I remember it compiling+linking, but then failing. Only not that libobjc2 needs clang now, I used to test 2) years ago by using full gcc. Maybe David can tell us more about 2). The most important combinations are of course 1) and 4) and I think they should work both on most platforms except perhaps for specific bugs. I will try to provide more information so we can get them both working on OpenBSD. Riccardo
Re: compiling GNUstep on OpenBSD - various compiler/runtime options
Hi, On 2020-01-03 10:07, Sebastian Reitenbach wrote: The gnustep packages use option 4, you may look into gnustep.port.mk and the respective packages makefiles. Libobjc is installed as libobjc2. Linker is ld.bfd. Libobjc2 is still only 1.8, a few packages had build issues and others runtime issues when I tried to upgrade to libobjc2 2.0. With your inspiration, I got a big step forward. I am able to run "ink" now using Option 4) clang + libobjc2 "current". I needed to configure make [in Niels fork]: ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu --with-tar=/usr/local/bin/gtar LDFLAGS=-fuse-ld=bfd (we always have issues with BSD tar, so I just added it.. but what exactly does this bfd linker mean) re-build cmake, after having sourced GNUstep.sh, using these options: cmake .. -DBUILD_STATIC_LIBOBJC=On -DTESTS=Off then reconfigure && reinstall make! after this, building of the rest of gnustep as just plain configure&make install the only two "big" differences are that - I included that bfd linker option - I did not specify for libobjc2 -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_FLAGS=-c as suggested in the INSTALL! Riccardo Riccardo
issue with mixed Objective-C ABI and SystemPreferences
Hi! I was able to compile most of GNUsteps apps with the options discussed in a previous mail, the only combination I got working is clang + Obj-C 2. Most apps seem to work fine, including GWorkspace (which loads inspectors just fine) and ProjectCenter. SystemPreferences instead does not start! I get this issue: Version 2 Objective-C ABI may not be mixed with earlier versions. and a crash. Why? No real clue yet. I checked compilation of SystemPreferences with messages=yes and clang is used. More ideas? Riccardo
Re: GORM usability enhancements
Hi, On 2019-12-23 22:48:51 +0100 Gregory Casamento wrote: I don't want to tie people to the outline view. I already explained the rationale of why in the last post. Classes should be treated like everything else and be editable by inspectors. I, personally, think the Outline view in Gorm should be done away with as it would eliminate this confusion. Eliminate it as Apple did long ago? I think it is wrong.. I like the double view: it is not really the same thing. Actions and Outlets are seen in a different way and "editing"is done in the Inspector with its editor. I don't see it is a real duplication, since you do editing in the Inspector (as you would with other objects) Apart from getting used to it, what is the issue? Riccardo
Re: GORM usability enhancements
Hi, On 2019-12-20 11:56:01 +0100 Sergii Stoian wrote: > 1. Enhancements in model files (conrtols positionning, autosizing, fonts, > menu items rearrangements). I think *most* of it is fine...Gorm matches quite closely NeXT IB and old Mac IB which were quite fine! But indeed, some autosizing and some elements are not so optimal. > 2. Sort out focus change between controls and windows (I've noticed some > inconviences). I did very few... but I do notice instead that when doing a connection to a target with many object icons, the icon list doesn't scroll properly and the target is drawn not below the cursor sometimes (but the connection will the correctly happen to the drawn target.. so it is bad, but usable) > 3. Document window changes: fix selection of objects, make object titles > editable (get rid of "Set Name" panel), finish and make usable Class Editor > outline editor (get rid of Class Editor Inspector). Class Editor Inspector is fine! For me enhancements would be useful in the object element drawing/positioning. The automatic guidelines and snapping... is worse than on old Mac IBs... but I don't know exactly why, perhaps it is a matter of layers and what is preferrably selected as a snap. Mac is quite aggressive and abundant, I think. A really big enhancement would be however undo. In everything it will be perhaps difficult (e.g. adding object, editing actions). But being able do undo "editing" of the graphical elements: size, positioning, etc... would be very useful since it is often trial-and-error. Just my 0.02 € Riccardo
Re: issue with mixed Objective-C ABI and SystemPreferences
Hi, Fred Kiefer wrote: From the error message I would suspect that you have an old plugin for SystemPreferences lying around that still gets loaded causing this issue. no, I don't have old plugins laying around. So very strange. I uninstalled and no plugins are left. I will investigate further what could be left over. Riccardo
crash when using local display but not remote
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?
Re: crash when using local display but not remote
HI Sergii On 1/25/20 12:13 AM, cobjective wrote: 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)? yes it means that the art backend builds without ftfont-old.m - so I just approved your changes Since everything works /displays when the display is exported to another computer, it is a strange issue, but I guess not font-related, since art backend always uses the "original" client font, not the server's fonts. The Debian version used is old... and is even a small "mix" of packages made to work years ago on that minimal netbook, upgrading now is due to kernel issues (although maybe Nikolaus makes progress, thanks to the CI20 board!) impossible. The runtime is gcc's one and it is some gcc 4 series, cpu is MIPS little-endian.. so I doubt you have an "i386" machine with that stuff. I will perform some further tests Riccardo
Re: crash when using local display but not remote
Hi, On 1/26/20 1:49 AM, Sergii Stoian 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... no, it is too generic. It is anyway good news that the art backend runs fine for you too! Did you notice the superior quality in rendering fonts and splines in Graphos? :-P On i386 with gcc and gcc runtime (but a totally different OS setup) everything works for me too! tried a couple of apps and everything looks smooth & quick. Even if it runs, a memory issue (which is what the libc error suggests) could go unnoticed and valgrind should be able do detect it. I was never good at using it though, Fred is the master It is hard to work on that minimal machine. If I had a working CI20, it would be much easier! Especially the old TLS means that I cannot sync directly to github :( Riccardo
Re: crash when using local display but not remote
Hi! Sergii Stoian wrote: >> 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 have debian 4.0 and am limited to a 2.4 kernel. The rest is some sort of a mix. gcc 4.1.2 and its own runtime I don't think this is an "art" bug, but an xlib/x11 issue, since it happened also when I compiled accidentally with the xlib instead of the art backend. For your informatin, I just compiled the art backend again on this small machine, with all your latest patches after the merge, and it compiles and also works fine if remote X is displayed. I usuallky always export display, because the small keyboard is unsuitable for typing the build commands :-P Riccardo
Cairo backend seems broken - mainScreen visibleFrame has no size
Hi, I just upgraded back and now no app is able to display images and/or sizinig windows. I think there is an issue determining the size and/or resolution of the screen. For example, LaternaMagica comes up with an infinte main window. I fear it might be related to the latest enhancements of Sergey, but have to investigate. Can anyone else reproduce? I get these warnings: (moria:gap/user-apps/LaternaMagica) multix% LaternaMagica 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] No local time zone specified. 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] Using time zone with absolute offset 0. 2020-01-30 07:31:38.888 LaternaMagica[17860:17860] styleoffsets ... guessing offsets 2020-01-30 07:31:38.935 LaternaMagica[17860:17860] styleoffsets ... guessing offsets 2020-01-30 07:31:39.144 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.446 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.477 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.492 LaternaMagica[17860:17860] The font specified for NSFont, FreeSans, can't be found. 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1183. In -[NSView setFrame:] given negative width 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1188. In -[NSView setFrame:] given negative height 2020-01-30 07:31:39.767 LaternaMagica[17860:17860] Cairo status 'invalid value (typically too big) for the size of the input (surface, pattern, etc.)' in DPSinitgraphics PRICE, instead, comes up, shows the same warnings as before in the conosole. Additionally, when loading an image: 2020-01-30 07:36:44.420 PRICE[17955:17955] current screen size: 0.00 x 0.00 2020-01-30 07:36:44.420 PRICE[17955:17955] current window size: 118.00 x 28.00 2020-01-30 07:36:44.745 PRICE[17955:17955] Cairo status 'invalid value (typically too big) for the size of the input (surface, pattern, etc.)' in DPSinitgraphics So this tells me that: screenFrameSize = [[NSScreen mainScreen] visibleFrame].size; NSLog(@"current screen size: %f x %f", screenFrameSize.width, screenFrameSize.height); is 0! and this can't be good! Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi! I updated my laptop (NetBSD / amd64 / gcc compiler and runtime) and now all GUI apps crash on startup: Starting program: /Local/Tools/Ink Xlib: extension "MIT-SHM" missing on display "localhost:11.0". 2020-01-31 14:58:52.354 Ink[14930:130845475800848] styleoffsets ... guessing offsets Program received signal SIGSEGV, Segmentation fault. 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] (self=0x7700d4c87010, _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at XGServerWindow.m:4528 4528 if (output_info->crtc) (gdb) bt #0 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:] (self=0x7700d4c87010, _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at XGServerWindow.m:4528 #1 0x7700c98600d2 in -[XGServer(WindowOps) _OSFrameToXFrame:for:] (self=0x7700d4c87010, _cmd=0x7700c9ab4430 <_OBJC_SELECTOR_TABLE+2544>, o=..., window=0x7700d6135c80) at XGServerWindow.m:512 #2 0x7700c986423d in -[XGServer(WindowOps) window] (self=0x7700d4c87010, _cmd=0x7700c9ab4390 <_OBJC_SELECTOR_TABLE+2384>, frame=..., type=2, style=64, screen=0) at XGServerWindow.m:1917 #3 0x7700c9863498 in -[XGServer(WindowOps) _setupRootWindow] (self=0x7700d4c87010, _cmd=0x7700c9ab0030 <_OBJC_SELECTOR_TABLE+400>) at XGServerWindow.m:1614 #4 0x7700c98560fb in -[XGServer _initXContext] (self=0x7700d4c87010, _cmd=0x7700c9ab0080 <_OBJC_SELECTOR_TABLE+480>) at XGServer.m:469 #5 0x7700c9856278 in -[XGServer initWithAttributes:] (self=0x7700d4c87010, _cmd=0x7700d60b4550 <_OBJC_SELECTOR_TABLE+144>, info=0x0) at XGServer.m:487 #6 0x7700d5c2db71 in +[GSDisplayServer serverWithAttributes:] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #7 0x7700d5a31715 in -[NSApplication _init] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #8 0x7700d50f87d1 in -[NSObject performSelector:withObject:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #9 0x7700d5180760 in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #10 0x7700d518061c in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #11 0x7700d518068b in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #12 0x7700d5a31b89 in -[NSApplication init] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #13 0x7700d5a3167e in +[NSApplication sharedApplication] () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #14 0x7700d5a11699 in NSApplicationMain () from /System/Library/Libraries/libgnustep-gui.so.0.28.0 #15 0x004019db in gnustep_base_user_main () #16 0x7700d512ac8b in main () from /System/Library/Libraries/libgnustep-base.so.1.27.0 #17 0x004017fc in ___start () #18 0x7f7e8a60cc38 in ?? () from /usr/libexec/ld.elf_so #19 0x0001 in ?? () #20 0x7f7fffaecf48 in ?? () #21 0x in ?? () the structure is null and needs to be checked. I also noticed that in case the call fails, there is no fallback. I restructured the code a little bit and pushed a fix. At least, now it does not crash for me anymore and Ink comes up and shows windows :-) However, I sstill get issues with X: 2020-01-31 15:07:47.335 Ink[27979:125763785598736] X-Windows error - BadRROutput (invalid Output parameter) on display: localhost:11.0 type: 0 serial number: 576 request code: 138 and even windowmaker when a GS application starts. wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch (invalid parameter attributes) Request code: 12 X_ConfigureWindow Request minor code: 0 Resource ID: 0x63 Error serial: 59874 Regards, Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi Sergii! Sergii Stoian wrote: I've added check for number of XRandR outputs. Please test and report if it helps. Yes it helps! now applications start both locally and remotely I got only one kind of error now and only once a the first start of Ink. starting it again, no error, so I do wonder and will keep an eye on it and also test on other computers. wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch (invalid parameter attributes) Request code: 12 X_ConfigureWindow Request minor code: 0 Resource ID: 0x63 Error serial: 59874 no more X-Windows errors. Out of curiosity, do you have XRandR enabled and it's not working? What is the Xorg log messages about it? How can I know? xome option to the "xrandr" command? P.S.: You haven't answer me about my XInitThreads idea. Have you succeded? Sorry, had no time to test yet. "Real Job" is consuming 99% of CPU time :-P But will test that as soonas I can and report back. Riccardo
Re: Cairo backend seems broken - mainScreen visibleFrame has no size
Hi! On 2/1/20 11:32 PM, Sergii Stoian wrote: Yes it helps! now applications start both locally and remotely I got only one kind of error now and only once a the first start of Ink. starting it again, no error, so I do wonder and will keep an eye on it and also test on other computers. Good. I've done testing myself and found more flows in current implementation. I start working on solution and almost done. You can find more fixes in 'randr' branch of libs-back. I fear the latest changes made window opening slower, I tested also on good and up-to-date computers with fine video card. no more X-Windows errors. > Out of curiosity, do you have XRandR enabled and it's not working? > What is the Xorg log messages about it? How can I know? xome option to the "xrandr" command? Do you observe some good "xrandr" output? in the sense that it reports correct screen size? then yes. It is true both for local as remote displays. Riccardo
Re: crash when using local display but not remote
Hi! On 1/28/20 11:28 AM, Sergii Stoian wrote: I'm not sure, just an idea: this problem may have relation to enabled multithreading in X11. Probably due to outdated X server. Could you please try to comment out line in x11/XGServer.m that contains XInitThreads() (line 419) and recompile/reinstall backend? I tried and it does not help. Now... the best would be to backout some changes and test, but without direct git/svn access it is quite bad. I'll see if I can nevertheless understand this better. Riccardo
Re: crash when using local display but not remote
Hi! On 1/28/20 11:28 AM, Sergii Stoian wrote: I'm not sure, just an idea: this problem may have relation to enabled multithreading in X11. Probably due to outdated X server. Could you please try to comment out line in x11/XGServer.m that contains XInitThreads() (line 419) and recompile/reinstall backend? I was able to restrict the offending breakage. As of 14 September (version bump) everything worked fine on the Letux400 MIPS-LE As of 13 January it is already broken As of 14 January it is still broken giving the memory error on startup. (I include obviously the minor ALPHA_THRESHOLD fix) I'm a little bit confused with the commits of 13th and 14th January, since they seem to contain similar things! Somehow, however in the "fixes" for the icon there appears to be a memory issue! Riccardo
Re: crash when using local display but not remote
Hi, On 04/02/2020 22:15, Sergii Stoian wrote: Clear explanation, thank you. It is a usual case when image contains more bytes than image size (width * height)? I feel we need to return back old code with your explanation in comment. What do you think? I don't know about "this" specific image case, but generally speaking yes. Cocoa does this now (since 10.6 at least) quite aggressively, so "bytes per row" is not necessary width * samplesPerPixel. In GNUstep i have not noticed that. So I had to fix quite some image processing code (e.g. PRICE, LaternaMagica) which worked fine in GNUstep and on 10.4 Mac. I guess it is done for optimization, address alignment for various reasons. Riccardo
Re: crash when using local display but not remote
Hi Fred! On 07/02/2020 10:20, Fred Kiefer wrote: I just committed a merge of the two approaches (plus a few compiler warning fixes). I hope this should fix Riccardo's issues. It might also be slightly faster as I removed the copy before the colour swap. At least the swapColor function now does what the comment above it claims:-) Thanks for the work and analysis. Unfortunately it still doesn't work for me. I grabbed latest trunk it contains your commit plus a later merge+commit by Sergii. Maybe it has to do with the fact that this is not a "DirectColor" display but a "TrueColor" display? I remember reading a comment by you that indexed color would not work. This small display is TrueColor 16 planes. Or does indexedColor for you means old 256 color - 8 bit? I hope we did not break that too, for old machines :-P RIccardo
Re: Multimonitor support
Hi Fred! On 03/02/2020 21:15, Fred Kiefer wrote: Sergii has written a great patch that will tremendously improve support for multiple monitors in GNUstep by using the XRandR extension. There is a downside to it though, this patch will also remove any multi screen support that was there before without XRandR. So if you have a multi monitor setup and your system won’t support XRandR we would like to hear from you and try to find a solution that is acceptable for all sides. I hope that there is nobody in this specific situation but it seems easier to ask in advance than to fix it later. Sounds great. First question - this refers only to X11, right? Multi-Monitor support (or lack of) under windows are unaffected? Second question - what was there "before" which would stop working, so which multi-monitor support is "left out" ? A setup to test it. Currently I use GNUstep and multi-monitor only in a setup with a Laptop + external screen, which means usually a relatively recent OS. Randr 1.2 has been around almost 10 years. If we don't require more modern features, I probably won't hit these limits. A laptop without xrandr is hard to sue, since only with it the external monitor can be dynamically added/removed. My more "esoteric" machines are single-monitor setups. Solaris 7 with two Monitors would be a setup? I don't have setups like that. Riccardo
Re: Next GNUstep release
Hi! Fred Kiefer wrote: I would like to schedule a shared new release for the core GNUstep packages (make, base, gui, back) around the end of March. We have a lot of excellent new features and it would be great to bring those out to more distributions and users. We are a bit later than in previous years still we should leave us enough time to prepare that release. I hope that it is possible to merge the Wayland branch before. (And yes, I still didn’t get around to review that. Sorry) And to give other new features like the multi monitor support a bit more testing and polishing. But I would suggest that we do not start or merge other big features during that time. (Smaller changes like the ones Greg is working in gui on should be fine) Any objections? And most importantly, Ivan will you have time to cut all these releases? Of course we could move that point around a week or two if that date fits better. I think it is fine, although it should be really tested... on different configs. There is a lot "happening" lately. Especially in back things are in flux and had performance or compatibility issues. Of course, promising stuff to.. Also make! I was proposing to merge Niels' patch but i see RFM did it. So now it only needs to be tested more... Riccardo
Re: crash when using local display but not remote
Hi Fred,
Fred Kiefer wrote:
> It is rather the later and that would also only change for the application
> icon. We should instead concentrate on the crash you are having on the Letux.
> You wrote that the version from September 14th works fine. Does this version
> also show the message „Xlib: extension "SYNC" missing on display ":0.0“.“?
> If it does we may ignore this hint, otherwise it might be worthwhile to
> follow.
I extra checked once again by compiling the old version and installing it.
I get several messagies for the SYNC message (I think one for every
window at least) and everything works. So we should ignore that, at
least, for the crash it is invariant.
>
> With all the latest changes could you please try again and report the stack
> trace you are getting? It would also help if you could find out which code is
> crashing. For this you could start by getting the normal debug output from
> the backend (—GNU-Debug=Dflt,XGTrace,Frame) and after you have the general
> region just add a few NSLog statements of your own.
How do you exactly use that? I tried both:
defaults write GNU-Debug {Dflt,XGTrace,Frame}
as well as:
Ink --GNU-Debug=Dflt,XGTrace,Frame
but nothing useful gets printed out, just the crash.
Do I need to recompile something with some specific option?
> The original message you posted (glibc detected *** double free or corruption
> (out)) points to a free call. We have plenty of these, but this might be a
> hint when you are getting closer.
I hope so. building with "debug=yes" and running in gdb makes an
incredible slow run, but no better trace:
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 12897)]
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?)
Riccardo
Re: crash when using local display but not remote
Fred!
Fred Kiefer wrote:
>
> You may have to set these separately. I was hoping there was a way to specify
> and array here, but did not check. So the easiest was is
>
> Ink —GNU-Debug=Dflt —GNU-Debug=XGTrace —GNU-Debug=Frame
Oh that finally helps, it is actually --GNU-debug=xxx (two dashes)
I get this:
root@hobbit:~# Ink --GNU-Debug=Dflt --GNU-Debug=XGTrace --GNU-Debug=Frame
2009-12-28 22:54:25.191 Ink[312:312] WindowMaker hack: Preparing app
icon window
2009-12-28 22:54:25.297 Ink[312:312] DPSwindow: {x = 0; y = 0; width =
0; height = 0} 2
2009-12-28 22:54:25.306 Ink[312:312] Draw mech 1 for screen 0
2009-12-28 22:54:25.310 Ink[312:312] O2X 0, 40, {x = 0; y = 0; width =
0; height = 0}, {x = 0; y = 480; width = 0; height = 0}
2009-12-28 22:54:25.315 Ink[312:312] X2H 0, 40, {x = 0; y = 480; width =
2; height = 2}, {x = 0; y = 480; width = 2; height = 2}
Xlib: extension "SYNC" missing on display ":0.0".
2009-12-28 22:54:26.003 Ink[312:312] Hint posn 1: 0, 480
2009-12-28 22:54:26.005 Ink[312:312] Hint size 1: 2, 2
*** glibc detected *** double free or corruption (out): 0x006415f0 ***
Aborted
The values look fine for me.
I started putting in some logs, then more logs and even more logs :-O
I am sure the issue is happening in here:
if (!didCreatePixmaps)
{
[self _createAppIconPixmaps];
}
I heavily log-traced _createAppIconPixmaps too
The crash precisly happens with the line:
RDestroyXImage(rcontext, rxImage);
So for some the new code here makes a double-free. I wonder if it is a
good idea at all to use a WINGs function here at all when before we did not.
I commented the Destroy out and things do work now! But I don't think
this is the correct solution.
I wanted to look up some WINGs documentation and check, but appears it
disappeared into net oblivion?
Riccardo
Libobjc2 on Linux - link issues
Hi! while I got a reliable clang+libobjc2 setup on OpenBSD with the bfd linker (contrary to other experiences here) I am unable to get it to work on something as simple as a current Linux/i386 with clang 8 I configure current make with: ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu LDFLAGS=-fuse-ld=gold I tried with and without LDFLAGS gold. I build and install "our" libobjc2. When I configure base, I get this failure: /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_guard_acquire' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::terminate()' /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_guard_abort' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::ios_base::Init::Init()' /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_rethrow' /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_begin_catch' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::ios_base::Init::~Init()' /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_guard_release' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*)' /System/Library/Libraries/libobjc.so: error: undefined reference to 'operator new(unsigned int)' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::cerr' /System/Library/Libraries/libobjc.so: error: undefined reference to '__cxa_end_catch' /System/Library/Libraries/libobjc.so: error: undefined reference to 'operator delete(void*)' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::ostream::operator<<(std::ostream& (*)(std::ostream&))' /System/Library/Libraries/libobjc.so: error: undefined reference to 'std::basic_ostream >& std::endl >(std::basic_ostream >&)' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) If Instead I do NOT use gold option, I get this 1 warning generated. /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::ostream::operator<<(std::ostream& (*)(std::ostream&))' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::basic_ostream >& std::endl >(std::basic_ostream >&)' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `operator delete(void*)' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `__cxa_end_catch' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*)' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `__cxa_guard_release' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::ios_base::Init::~Init()' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `operator new(unsigned int)' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::cerr' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `__cxa_begin_catch' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `__cxa_rethrow' /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: /System/Library/Libraries/l ibobjc.so: undefined reference to `std::ios_base::Init::Init()' which is even more weird? Riccardo
Re: crash when using local display but not remote
Hoi Fred! Fred Kiefer wrote: > You won’t have to look up the WINGs documentation. In most cases we do not > use a separate Wraster library but have copies of the files in this > directory. The one you are looking for is util.c, but first check your > configuration look whether the Wraster library gets used or our local files. > It could well be that there is an issue with that code. Or the opposite may > be true and you have one of the rare cases where Wraster is available but > faulty. But that is highly unlikely. I guess it is not used/detected. In config.log: WITH_WRASTER='no' as the output LIBS: LIBS='-L/usr/lib -lart_lgpl_2 -lm -lfreetype -lz -lXt -lXext -lX11 ' given that I have: #define XSHM 1 that is the path taken. As a final test, I commented out "free" inside RDestroyXImage And it does not avoid the issue! The issue instead appears to be the XDestroyImage call, commenting out that, I get no crash. As I check, the "non" shared path is taken. RDestroyXImage rx->image is not shared! What's going on? Riccardo
base / libobjc2 link issues on FreeBSD 12
Hi, getting a working clang+libobjc2 is a small saga now :-P I want to update my FreeBSD 12.1 laptop too. I did the same setup I did on my FreeBSD 11.3 workstation and it does not work, I am puzzled. configure make: ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu ( I did not specify anything about the linker) configure and install libobjc2 (to get the latest one, the FreeBSD supplied version is still faulty and causes crashes) The generated libobjc2 has: $ ldd /System/Library/Libraries/libobjc.so /System/Library/Libraries/libobjc.so: libthr.so.3 => /lib/libthr.so.3 (0x20842000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x2086b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20887000) libc.so.7 => /lib/libc.so.7 (0x20446000) $ then when I configure base, the objc test fails with one missing symbol: configure:7860: checking whether objc really works configure:7880: clang -o conftest -g -O2 -I/Local/Library/Headers -I/Local/Library/Headers -I/System/ Library/Headers -I/usr/local/include -I/System/Library/Headers -x objective-c -L/Local/Library/Libra ries -L/Local/Library/Libraries -L/System/Library/Libraries -L/usr/local/lib -L/System/Library/Librari es conftest.c -lrt -ldl -lpthread -rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-1.8 -fblocks -L/home/multix/GNUstep/Library/Libraries -L/Local/Library/Libraries -L/System/Library/Libraries -L/us r/local/lib -lobjc -lm >&5 In file included from conftest.c:107: In file included from ././config/config.objc.m:2: ././config/objc-common.g:54:3: warning: assignment to Objective-C's isa is deprecated in favor of obje ct_setClass() [-Wdeprecated-objc-isa-usage] obj->isa = self; ^ ~~~ object_setClass( , ) ././config/objc-common.g:47:5: note: instance variable is declared here id isa; ^ 1 warning generated. configure:7880: $? = 0 configure:7880: ./conftest ld-elf.so.1: /System/Library/Libraries/libobjc.so.4.6: Undefined symbol "_ZNSt3__14cerrE" configure:7880: $? = 1 configure: program exited with status 1 and now? Riccardo
Re: base / libobjc2 link issues on FreeBSD 12
Hi David, David Chisnall wrote: ld-elf.so.1: /System/Library/Libraries/libobjc.so.4.6: Undefined symbol "_ZNSt3__14cerrE" configure:7880: $? = 1 configure: program exited with status 1 This looks as if something is including a C++ header that is pulling in iostream, specifically the libstdc++ version of iostream. libstdc++ is not installed by default on FreeBSD, so I'm not sure how that's happening. Do the libobjc2 tests also fail with this error? well, "make test" has 178 failures, which means... probably all of them, not very promising. So this is FreeBSD, so I wonder what is going wrong. I configured libobjc2 this way: cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_FLAGS=-c $ make test Running tests... Test project /usr/home/multix/code/gnustep-cvs/libobjc2/Build Start 1: alias 1/178 Test #1: alias .***Failed 0.00 sec Start 2: alias_optimised 2/178 Test #2: alias_optimised ...***Failed 0.00 sec Start 3: alias_legacy <> 0% tests passed, 178 tests failed out of 178 how can I share you the failure details? where are they? Riccardo
Re: base / libobjc2 link issues on FreeBSD 12
Hi David, thanks for the support, read below. I also cheked - there is no other libobjc on the system, no libobjc2 package installed from ports. David Chisnall wrote: On 20/02/2020 11:01, Riccardo Mottola wrote: cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang -DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_FLAGS=-c clang++ is a C++ compiler, clang is a C compiler, so your CMAKE_CXX_COMPILER value looks wrong. Clang is the default compiler on FreeBSD, so these seem redundant (I don't know why you are adding -c to ASM flags either). I don't know if the system clang on FreeBSD 12 is sufficiently new, the package uses clang80. freebsd 12.1 system compiler is clang 8.0.1 I added these options because they are mentioned like this in your INSTALL file! Just as a test, I did again a clean build with absolutely no options, just: cd Build $ cmake .. -- The C compiler identification is Clang 8.0.1 -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/cc -- The CXX compiler identification is Clang 8.0.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Testing C++ interop -- Testing /usr/lib/libcxxrt.so as the C++ runtime library -- Using /usr/lib/libcxxrt.so as the C++ runtime library -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- GNUstep install type set to SYSTEM -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success -- Configuring done -- Generating done -- Build files have been written to: /home/multix/code/gnustep-cvs/libobjc2/Build make -j2 < build...> -> all 178 tests fail. where are the errors of the tests? Riccardo
Re: crash when using local display but not remote
Hi! Fred Kiefer wrote: > I still don’t know for sure what is going on here. Most likely we are > overriding some other data when copying the image. To prevent this I made the > pre conditions of the new code explicit. If these are not fulfilled no app > icon for WindowMaker will be created. I also changed the code to only create > this icon for WindowMake, that way less systems will be affected by this > issue. Could you please try again on your Letux? I just tried again, now Ink starts up both locally & remotely! However, I get this warning when exporting to a "real color" display 2020-02-25 16:36:17.620 Ink[2192:2192] Unsupported context depth 24 2020-02-25 16:36:18.236 Ink[2192:2192] XShm not supported, XShmAttach() failed. 2020-02-25 16:36:18.238 Ink[2192:2192] Falling back to normal XImage (will be slower). I suppose XShm fails because it is over ssh? But what is the first message? Locally, instead, I only get Unsupported context depth 16 So... the depth is correct 16 and 24, but why unsupported? On the same computer which gave the 24bit depth warning and I was exporting the display to, if I run instead GNUstep and Ink locally, I see: 2020-02-25 16:02:43.318 Ink[24686:24686] No local time zone specified. 2020-02-25 16:02:43.319 Ink[24686:24686] Using time zone with absolute offset 0. 2020-02-25 16:02:43.252 Ink[24686:24686] styleoffsets ... guessing offsets 2020-02-25 16:02:43.320 Ink[24686:24686] styleoffsets ... guessing offsets 2020-02-25 16:02:49.517 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. 2020-02-25 16:02:50.744 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. 2020-02-25 16:02:50.998 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. 2020-02-25 16:02:51.071 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. 2020-02-25 16:02:51.072 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. 2020-02-25 16:02:51.646 Ink[24686:24686] Ignore left offset change from 0 to 31 2020-02-25 16:02:51.646 Ink[24686:24686] Ignore right offset change from 0 to -31 2020-02-25 16:02:51.647 Ink[24686:24686] Ignore top offset change from 0 to 31 2020-02-25 16:02:51.647 Ink[24686:24686] Ignore bottom offset change from 0 to -31 2020-02-25 16:02:51.647 Ink[24686:24686] Reparent was with offset 31 31 2020-02-25 16:02:51.647 Ink[24686:24686] Parent border,width,height 0,64,64 2020-02-25 16:02:51.977 Ink[24686:24686] The font specified for NSFont, FreeSans, can't be found. Riccardo
Re: Next GNUstep release
Hi, before a release, I would like these issues to find a solution. - understand why we don't work properly on my ThinkPad T23 neither with the Cairo nor with the xlib backend with similar issues - understand/fix/workaround the libobjc2 which impede me to test current GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64 afterwards a "run" on our current applications would be fine. After core release, I think a release of acouple of other apps could be nice. ProjectCenter and some GAP apps should go. I will also finalize a PRICE release in the next weeks. Riccardo
Display issues (Was: Next GNUstep release)
Hi, Sergii Stoian wrote: Hi, On Feb 27, 2020, at 23:09, Riccardo Mottola wrote: Hi, before a release, I would like these issues to find a solution. - understand why we don't work properly on my ThinkPad T23 neither with the Cairo nor with the xlib backend with similar issues Could you please be more specific and describe these issues? I have an issue I am working on with Fred, I can forward you some mail because they contain screenshot and I did not spam the mailing list. Essentially I discovered that many windows contain "garbage" and what we discovered so far - certain windows width cause garbage do be displayed, resizing the window may cause it do display correctly - this garbage is compatible with an wrong offset increasing for each row (you see diagonal lines if you have a white window with a border) - the issue happens both with cairo and xlib (recent discovery of two days ago, before we were concentrating on a cairo issue) it looks like an issue that somwehre a padding/alignment is lost: e.g. width*bytesPerPixel != bytesPerRow, but where? I have not seen this issue elsewhere. The T23 is itself a pretty standard setup: Devuan ascii, GCC runtime, i386. Only the videocard is a little bit vintage/odd (S3) but it works with any other program except GNUstep :-P Riccardo
Re: Next GNUstep release
Hi! Ivan Vučica wrote: - understand/fix/workaround the libobjc2 which impede me to test current GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64 Honestly, I would have expected that libobjc2 FreeBSD should work out of the box given David is/was working on FreeBSD... Me too! and of course he is not able to reproduce my issue or I bet he would have been quick at fixing things. However, since I have the issue on more than one system... I'd say it is not just one unlucky machine. Riccardo
Re: Building GNUstep for Windows using Clang
Hi, On 3/6/20 7:44 PM, Gregory Casamento wrote: Since we are talking about building on Windows 10 using clang and msys2 I would like someone to write up a comprehensive guide on how. From A to Z, please. I realize I'm likely to be roasted for this request by multiple people, but at this point it needs to be done and I am quite used to being roasted. :/ well, since I am working since almost a year to get instead a working ming64 setup on windows7 & windows10 with GCC, there is probably some common ground. I never started this because.. it yields a not totally stable result and it is not very reproducible from computer to computer, it is very strange. I propose a wiki page. Then two sub-sections for the different compiler & runtimes. Riccardo
Re: Building GNUstep for Windows using Clang
Hi, On 3/7/20 11:54 AM, Riccardo Mottola wrote: well, since I am working since almost a year to get instead a working ming64 setup on windows7 & windows10 with GCC, there is probably some common ground. I never started this because.. it yields a not totally stable result and it is not very reproducible from computer to computer, it is very strange. I propose a wiki page. Then two sub-sections for the different compiler & runtimes. since several people asked about it, I will collect and share my work here: http://wiki.gnustep.org/index.php/Installation_MSYS2 Riccardo
Re: Display issues (Was: Next GNUstep release)
Hi Sergii, Sergii Stoian wrote: You forgot to mention one important detail. This problem only shows up with 16 bit depth. Most likely this happens as some data structure that holds the intermediate pixel information rounds the line length to a multiple of 8, 16, 32 or even 64 and we use one value below that, so we get an offset for each line which leads to the displayed garbage. The problem is that I am not able to reproduce the issue and don’t know which intermediate structure needs adjustment. It looks strange. Some regions which are roughly filled with XFillRectangle should look plain. But they don’t (Riccardo sent me a screenshots). We need to be sure the video driver works correctly. The next step is to understand what code in GNUstep drives that weird behaviour. I performed some tests by hacking xorg.conf ... I was a bit rusty at that, but a refresh does good. We are forced at home for cornavirus anyway. I can enable/disable HW acceleration in the driver and force 16 bit or 24 bit. This gives us 4 combinations! 1) Accel + 16 bit : GNUstep Broken as per original screenshot 2) NoAccel + 16bit : Everything Works fine! 3) Accel + 24bit: GNUstep slightly broken, like 16 bit but there is clearly a repaint where (mouse cursor ruins display, there is clearly a driver bug in this mode) 4) NoAccel + 24bit: works so, clearly HW acceleration makes some difference. I checked other apps, I did run not only WindowMaker, xterm, gvim, but also more difficult apps like emacs and firefox and they do look fine without the issues we have in both 16bit and 24 bit acceleration. Interesting is GNUstep in 24 bit accelerated mode: it looks broken similar to 16bit, but in 16 bit a broken window is just broken and always look the same from the beginning (refresh, minimize, etc) and depends only on the size, in 24 bit it is different! in 24 bit accel, the window comes up and looks broken like in 16bit then immediately draws and looks "decent" (small glitches). However a move or a iconize/reopen will make it broken, like in 16bit mode. My guess is that we do some double-buffering or shadow buffering somewhere and the two buffers are not "aligned" What is common here to both cairo&xlib? I don't know if I mentioned, but when I tested 16bit-accel, I tested both backends! so it is not "cairo specifc". I did not test art because I don't have libart nor art fonts in this machine, but if you wish, I could try. Riccardo
Re: Building GNUstep for Windows using Clang
Hi, Frederik Seiffert wrote: >> >> >> http://wiki.gnustep.org/index.php/Installation_MSYS2 > > > Thank you Riccardo! I’ll follow along and will gladly test > instructions here. > I just complteted to my best. By writing this tutorial I was finally able to replicate the setup I had once runnign at work also on my personal system. I failed previously! I got "Ink" working. Unfortunately other problems exist. E.g. jpeg images are not loaded, network connections do not work. (All this worked in our old, classinc mingw setup) Maybe you want to try your luck with gcc and objc-1 first to see if then everything works and then start working on clang? Riccardo
Failure to launch apps - segfault in NSTimer
Hi,
on the following setup:
- Gentoo Linux
- x86
- libobjc2 (latest git)
- latest base/gui/back
A launch of Ink does:
Program received signal SIGSEGV, Segmentation fault.
0xb7561fc8 in -[NSTimer
initWithFireDate:interval:target:selector:userInfo:repeats:]
(self=0x84cb9f4, _cmd=0xb784e4d0 , fd=0x0, ti=30,
object=0x84cb8d4, selector=0x0, info=0x0, f=1 '\001') at NSTimer.m:119
119 if (ti <= 0.0)
what is fd in the signature, which is null?
119 if (ti <= 0.0)
(gdb) list
114 target: (id)object
115 selector: (SEL)selector
116 userInfo: (id)info
117 repeats: (BOOL)f
118 {
119 if (ti <= 0.0)
120 {
121 ti = 0.0001;
122 }
123 if (fd == nil)
still, none of these looks wild, except, perhaps
#0 0xb7561fc8 in -[NSTimer
initWithFireDate:interval:target:selector:userInfo:repeats:]
(self=0x84cb9f4, _cmd=0xb784e4d0 , fd=0x0,
ti=30, object=0x84cb8d4, selector=0x0, info=0x0, f=1 '\001')
at NSTimer.m:119
#1 0xb75318ff in +[NSRunLoop _runLoopForThread:] (self=,
_cmd=, aThread=) at NSRunLoop.m:784
#2 0xb7531965 in +[NSRunLoop currentRunLoop] (self=,
_cmd=) at NSRunLoop.m:811
#3 0xb753169f in +[NSRunLoop initialize] (self=0x81092c0, _cmd=0x8090918)
at NSRunLoop.m:747
#4 0xb723d158 in objc_send_initialize ()
from /System/Library/Libraries/libobjc.so.4.6
#5 0xb7249058 in slowMsgLookup ()
from /System/Library/Libraries/libobjc.so.4.6
#6 0xb724efc1 in objc_msgSend () from
/System/Library/Libraries/libobjc.so.4.6
#7 0xb75623e4 in +[NSTimer
scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:]
(self=, _cmd=, ti=,
object=, selector=, info=,
f=) at NSTimer.m:241
#8 0xb7cb4dbb in +[GSServicesManager newWithApplication:] (
self=, _cmd=, app=)
at GSServicesManager.m:556
#9 0xb7cb4e3f in +[GSServicesManager manager] (self=,
(gdb) p self
$1 = (NSTimer *) 0x84cb9f4
(gdb) p object
$2 = (id) 0x84cb8d4
(gdb) po object
Riccardo
Re: Next GNUstep release
Hi, Richard Frith-Macdonald wrote: >> Sunday would be a good time for me, but I am fine waiting. Also, if it’s not >> a binary-breaking change, I can always cut an additional point release. Let >> me know what you think. > I think it's about time to make a release. I'm looking at the > NSURLComponents stuff some more today, but as it's a new class (not in the > previous release), as long as it compiler reliably (it does) it's not going > to break anything and should not stop us making a release. > > I would release "base" as it is in master though, not mergein any branches.. I have decently tested it on a couple of platforms with gcc. Riccardo
Re: Next GNUstep release
Hi! Richard Frith-Macdonald wrote: > What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, > in that we could auto-generate ChangeLog entries from the repository, either > by an automated commit hook or (assuming that's not easy to do readily), > using a script to get details from the repository just before we make a > realease, so that anyone getting a release of the software still gets a > comprehensive ChangeLog. > > Then we would be saved the overhead of writing ChangeLog entries and could > concentrate on: > 1. meaningful commit entries, which of course we should all be doing anyway > ;-) > 2. writing release notes for any substantive change (rather than ChangeLog > entries for even minor changes), to appear in the NEWS when we make a release > > If we stop writing ChangeLog entries, we should be able to write release > notes and still be spending less time, and of course that would make the > process of cutting a release less onerous. It sounds reasonable. I'd like to see what this ChangeLog could look like. I still "love" our ChangeLog and miss it in projects where it does not exist. It contains two important informations grouped together: The conext of a Commit plus files, descriptions and if the author is nice, even the Method. e.g. 1970-01-01 John Doe * NSApplication.h * NSApplication.m (runLoop:) HookUp runLoop to some Event. is a context not found in other tools. To inspect the "files", in GIT or SVN I end up essentially going on the web interface and finding it. But to know which file was modified, with git I use the "blame" or again skip through the web interface. The extra information about the method is lost in any case. Here, instead, I just use grep or view on the ChangeLog, find what I need on the console in matter of secons once I have found meaning ful commits, then I still can open the web interface, in spect it, etc. So a mere log of commit messages is totally useless, since "git log" or "svn log" provide that (and often the comments are not that meaningful). Maybe we can find a compromise here. Riccardo
Re: Next GNUstep release
Hi,
Ivan Vučica wrote:
> Please also see the other thread for my thoughts so I don't repeat
> them in detail, but just this:
>
> On Mon, Apr 6, 2020 at 2:46 PM David Chisnall
> wrote:
>> Compare these two pages:
>>
>> The ChangeLog file:
>> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>>
>> The Git history:
>> https://github.com/gnustep/libs-base/commits/master
>>
>> The second is easier to skim, easier to jump to exact changes, and
>> easier to use to isolate change in a particular area (only care about
>> changes in the tools? Look here:
>> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
>> main history page).
I completely agree that the ChangeLog is much easier to skim than the
git history! Even if the one of github is nicely formatted.
I wrote separately about the usefullness of grouping files, comments and
possibly methods together.
> Should we enforce each commit to be larger before publishing? Should
> we enforce commit chains to end up in a merge commit which is
> detailed? Should we enforce updating changelog-equivalent only when a
> particular feature is finished and ready to be added -- but *enforce
> it consistently*?
No please not minimum length...
> Again, I don't want to have to have to distinguish between "this is
> adding a new class", "this is fixing a security bug", "this is
> *partially* addressing a security bug", "this is a quick compile fix",
> "this is a large overhaul of the build system" by having to inspect
> each commit in a really long chain of commits. Not necessarily a tree,
> even.
>
> FWIW ChangeLog entries *when written* were more useful for this
> purpose. The problem was *when they weren't written*.
Mostly because they were a little more thought off.
Of course if you just write "fix implementation" and skim a log, you
don't know what.
Suppose the scenario where you implement feature X and by this solve a
bug B1.
1. clean-up some code
2. implement a new method
3. use the new method
4. clean up some other methods and fix bug.
5. add some boilerplate, comments
6. add a test case
I would have made 6 different commits, with 6 messages. But for a
ChangeLog perhaps just 2 commits are useful. One for the new
implementation, citing the file, the method and reference to feature X.
Then a commit with the usage and bug fix for reference fo B1.
Adding a test case, a fix is "not that useful" in the ChangeLog.
This is, of course, theoretical world.
> Git commits as written today are unsustainable.
And about in most projects (FOSS or not) I see.
Perhaps a good average is in mozilla, with longer messages, bug
reference, etc. However, there, the commits are essentially just
merge-in of patches.
So there is a very strict reference bug-bug-number-commit and the commit
are comprehensive, if done in steps numbered (like my case above would
have bug B1 and then commit 1/6, 2/6 etc etc)
We are not so disciplined and it is a bit the opposite of how he always
worked.
> But maintainers, please just decide something and proclaim that this
> is what will be done. It doesn't have to be consistent among packages,
> but *within* a particular release of an individual package, I'd like
> to see consistency. We can't have some people "opt-out" of the chosen
> process. Maintainers need to be the ones to enforce this, including
> possibly writing the log entries ('blogposts'?) themselves.
>
we need to agree on some sort of common line.
Of course, everybody wants to type and update the least possible during
hacking, but then different developers have different tastes and needs
when looking up the changes during bug hunting or releaseing.
Riccardo
Re: Changelog and git log hygiene
Hi Ivan Ivan Vučica wrote: > > Is this a fix? Is this a security fix? Is this just a part of a > security fix? Or is this a new feature? Or is this a portion of a new > feature? Has this skeleton implementation been finished before this > release -- how do we announce the work done? "Implemented" or "stubbed > out"? > Yes... I think sometimes we should better commti lines, especially about stubs, half implementations, full implementations. Fixes vs features. I found this issue too lately while sometimes skimming for changes and bug hunting. > > > Either everyone please agree to keep a journal in ChangeLog file, or > another change log; or consistently write about large chunks of code > you wrote (e.g. NSOrderedSet as one entry of 3 sentences rather than > 30 commits without anything related among them) so we can put them in > release notes. this short line you wrote quite well matches the longer description I proposed in my last mail, I think Riccardo
FreeBSD - no luck with libobjc2
Hi Fellow Hackers, anybody using GNUstep on FreeBSD? ? I am unable to... and I have 1 workstation, 2 laptops relying on it (actually, 3 laptops, one now a bit obsolete). Some run FreeBSD 11, some 12... on none I can get it currently to work. I was able to get it to work about 1 year ago, because the "pkg" provided by FreeBSD worked, but that version of libobjc2 is buggy so any GUI version crashes, other people reported that. So building from sources. This worked a bit, was unreliable, but stopped totally for me. Maybe something in libobjc2, something in FreeBSD updates, I don't know. David is capable of doing, obviously... I don't. For me this is quite a "show stopper", since it cripples my home computer. I configure gnustep-make with: $ ./configure --with-layout=gnustep --prefix=/ --with-library-combo=ng-gnu-gnu CFLAGS=-I/usr/local/include Then here the problems and tests I did on FreeBSD 11.3 p7 System compiler is clang 8.0.0 I use "ccmake ." to edit the current configurations of the cmake build. with "t" I access the linker. After each I use "c" to write configuration and "g" to generate and exit. First attempt: CMAKE_LINKER /usr/local/bin/ld.gold Fails this way: [ 10%] Linking C executable ObjCXXEHInterop_arc_legacy_optimised ../libobjc.so.4.6: undefined reference to `std::__1::ios_base::clear(unsigned int)' ../libobjc.so.4.6: undefined reference to `ceilf' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::put(char)' ../libobjc.so.4.6: undefined reference to `std::__1::basic_stringstd::__1::char_traits, std::__1::allocator >::__init(unsigned long, char)' ../libobjc.so.4.6: undefined reference to `std::__1::ctype::id' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::sentry::sentry(std::__1::basic_ostreamstd::__1::char_traits >&)' ../libobjc.so.4.6: undefined reference to `std::__1::__vector_base_common::__throw_length_error() const' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::flush()' ../libobjc.so.4.6: undefined reference to `std::__1::ios_base::getloc() const' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::sentry::~sentry()' ../libobjc.so.4.6: undefined reference to `std::__1::locale::use_facet(std::__1::locale::id&) const' ../libobjc.so.4.6: undefined reference to `std::__1::cerr' ../libobjc.so.4.6: undefined reference to `std::__1::locale::~locale()' ../libobjc.so.4.6: undefined reference to `std::__1::basic_stringstd::__1::char_traits, std::__1::allocator >::~basic_string()' cc: error: linker command failed with exit code 1 (use -v to see invocation) So I try bfd linker: [ 10%] Linking C executable ObjCXXEHInterop_arc_legacy_optimised ../libobjc.so.4.6: undefined reference to `std::__1::ios_base::clear(unsigned int)' ../libobjc.so.4.6: undefined reference to `ceilf' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::put(char)' ../libobjc.so.4.6: undefined reference to `std::__1::basic_stringstd::__1::char_traits, std::__1::allocator >::__init(unsigned long, char)' ../libobjc.so.4.6: undefined reference to `std::__1::ctype::id' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::sentry::sentry(std::__1::basic_ostreamstd::__1::char_traits >&)' ../libobjc.so.4.6: undefined reference to `std::__1::__vector_base_common::__throw_length_error() const' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::flush()' ../libobjc.so.4.6: undefined reference to `std::__1::ios_base::getloc() const' ../libobjc.so.4.6: undefined reference to `std::__1::basic_ostreamstd::__1::char_traits >::sentry::~sentry()' ../libobjc.so.4.6: undefined reference to `std::__1::locale::use_facet(std::__1::locale::id&) const' ../libobjc.so.4.6: undefined reference to `std::__1::cerr' ../libobjc.so.4.6: undefined reference to `std::__1::locale::~locale()' ../libobjc.so.4.6: undefined reference to `std::__1::basic_stringstd::__1::char_traits, std::__1::allocator >::~basic_string()' cc: error: linker command failed with exit code 1 (use -v to see invocation) Then I try the system linker: CMAKE_LINKER /usr/bin/ld and I get exactly the same error again. So now? Is this not the correct way to change cmake parameters? I think this is quite a mess. Riccardo
Re: FreeBSD - no luck with libobjc2
Hi Wolfgang, glad to see you around. Wolfgang Lux wrote: Am 13.04.2020 um 13:56 schrieb Riccardo Mottola : So now? Is this not the correct way to change cmake parameters? I've never used ccmake, but I'm using cmake directly in the way suggested in the INSTALL file: cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=RelWithDebInfo .. and then I don't try to touch the cmake configuration in any way. Presumably you can even omit the -DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER options on FreeBSD because there should be no gcc (unless you've installed it yourself or it got installed by some package you are using). But then both shouldn't hurt either. The -DCMAKE_BUILD_TYPE option is only for getting debugging symbols for libobjc2 (and to prevent Class from being an abstract type, which makes debugging even more of a pain than it is already due to gdb and lldb not being aware of the instance variables offsets). That said, I would recommend nuking your old build directory and starting from scratch before calling cmake because it seems to update the existing configuration. So if that is already broken in some way, you'll still end up with a configuration that's most likely broken again. I started that way, then I thought of trying different linkers and the best place to do that is I think "ccmake .". Or perhaps I am wrong. I uninstalled gcc, since it doesn't work to build GNUstep anyway on FreeBSD (this is why libobjc2 is critical for me here, or I'd just gcc and avoid the hassle) I think this is quite a mess. Well, cmake is a mess (unless you'r used to it, of course); my first complaint is the lack of an equivalent for ./config.status -V, which would just show the configuration parameters that were provided to cmake in this particular build directory. well, I think ccmake . should show you the last "status" and how it was initialized... I started from a total clean Build directory: cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo only command I gave. -- The C compiler identification is Clang 8.0.0 -- The ASM compiler identification is Clang -- Found assembler: /usr/bin/cc -- The CXX compiler identification is Clang 8.0.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Testing C++ interop -- Testing /usr/lib/libcxxrt.so as the C++ runtime library -- Using /usr/lib/libcxxrt.so as the C++ runtime library -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- GNUstep install type set to SYSTEM -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success -- Configuring done -- Generating done -- Build files have been written to: /home/multix/code/gnustep-cvs/libobjc2/Build Builf fails: I get just one error now (which was included in the big list we had before) [ 11%] Linking C executable ObjCXXEHInterop_arc_optimised ../libobjc.so.4.6: undefined reference to `ceilf' cc: error: linker command failed with exit code 1 (use -v to see invocation) --- Test/ObjCXXEHInterop_arc_legacy_optimised --- *** [Test/ObjCXXEHInterop_arc_legacy_optimised] Error code 1 to test "gold" I thus nuked the Build Directory again: and did: cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_LINKER=/usr/local/bin/ld.gold Gold fails the same way: [ 11%] Linking C executable ObjCXXEHInterop_arc_legacy_optimised ../libobjc.so.4.6: undefined reference to `ceilf' cc: error: linker command failed with exit code 1 (use -v to see invocation) --- Test/ObjCXXEHInterop_arc_optimised --- *** [Test/ObjCXXEHInterop_arc_optimised] Error code 1 make[2]: stopped in /usr/home/multix/code/gnustep-cvs/libobjc2/Build So indeed, it was not coming out before. Now I tried an additional trick: use "ccmake ." again: CMAKE_EXE_LINKER_FLAGS -lm that seems to have fixed it! I am running GNUstep again on my workstation. Now I will test on the laptops... and try first to use the system linker and not gold, just to see. Riccardo
Re: FreeBSD - no luck with libobjc2
Hi Johannes, I hope you had a nice Easter. Johannes Brakensiek wrote: > >> I've never used ccmake, but I'm using cmake directly in the way >> suggested in the INSTALL file: >> cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ >> -DCMAKE_BUILD_TYPE=RelWithDebInfo .. >> and then I don't try to touch the cmake configuration in any way. > > I don’t know if I already mentioned it (;)), but there is a very good > tutorial from Andreas Fink on how to build GNUstep using clang under > FreeBSD: > http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD I skimmed through it.. it looks a bit overkill, I try to intall GNUstep the minimum to each system, so I try not to install new compilers etc etc. However, it confirms all steps I am doing. I would mark several steps "optional" (new compilers...) I think I found a solution now for libobjc2 on FreeBSD 11, I mentioned it in the other thread (edit linker flags) To the guide I would however add check out of liobjc2 needs: git submodule update --init --force --remote to get some submodules. Riccardo
Re: FreeBSD - no luck with libobjc2
Hi, Wolfgang Lux wrote: >> I think this is quite a mess. > Well, cmake is a mess (unless you'r used to it, of course); my first > complaint is the lack of an equivalent for ./config.status -V, which would > just show the configuration parameters that were provided to cmake in this > particular build directory. some further information about this. On FreeBSD 11.3 the "only" fix I need is to add this in libobjc2: cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo CMAKE_EXE_LINKER_FLAGS -lm Is enough. On FreeBSD 12 instead, the "-lm" hack is no longer needed (provided, as Wolfgang says, that I start with a cleanbuild directory, regerration doesn't wor, this was my culprit). So a clean start of everything now allows to compile everything (no gold linker needed) but things do not work then, I get a crash Starting program: /Local/Tools/Ink BFD: /System/Library/Bundles/libgnustep-back-028.bundle/libgnustep-back-028: version count (1588) does not match symbol count (2586) Program received signal SIGBUS, Bus error. 0x00080021846a in ?? () from /libexec/ld-elf.so.1 (gdb) bt #0 0x00080021846a in ?? () from /libexec/ld-elf.so.1 #1 0x in ?? () (gdb) quit To solve this, I need to use ld.gold. ./configure --with-layout=gnustep --prefix=/ --with-library-combo=ng-gnu-gnu LD=/usr/local/bin/ld.gold LDFLAGS=-fuse-ld=/usr/local/bin/ld.gold And then rebuild everything. Interesting that this is needed ONLY on FreeBSD 12, not on FreeBSD 11 which works fine with the system linker|! Curious, or not? Riccardo
Re: CMake 3.16
Hi David! hope all is well. David Chisnall wrote: > > What is the most recent cmake that is easy to install on your GNUstep > development systems? I'd like to get an idea of when moving to > depending on 3.16 (released last November) will be viable for most > people. > On NetBSD latest pkg release has 3.16 On FreeBSD you already know. We would need to check if OpenBSD will include it in the next release due soon. On Devuan/ascii I have 3.7 and I don't know if it will ever get more than that, being extended support. For me on other platforms I don't use cmake, since I use gcc and not libobjc2 currrently (although I'd like to be able to use the gcc+libobcj2 combination again as I did long ago) Riccardo
Lost information converting decoded value to in32_t
Hi! I noticed that on a totally fresh installation on intel 32bit, I get many warnings of the type "Lost information converting decoded value to in32_t" when starting GWorkspace. Putting a breakpoint, I noticed that this issue is not coming from "my" code but directly from NSUnarchiver of the GSGormLoader. Is it a bug? or did some types change and broke compatibility with existing gorm types? The first "halt" I get is when loading Attributes.gorm of GWorkspace's Inspector Riccardo
Re: Lost information converting decoded value to in32_t
Hi, On 25/05/2020 09:50, Fred Kiefer wrote: The first "halt" I get is when loading Attributes.gorm of GWorkspace's Inspector Looks like your archive has a value that gets encodes as an NSInteger and this is 32 bit on your current machine but the original encoded value was actually 64 bit and uses more than the 32 bit you are able to read. The best thing to do is to find out which value it is that causes the behaviour and encode (and decode) it as a long. And to answer your question, the message itself is surely not a bug, it just shows how clever base tries to deal with different encoded values. The actual encoding may be a bug. There it would really help to know where it is coming from. Yes, I understand the error is not in the Unarchiver - I have seen the check. But my question is why should I have an invalid number in a Gorm file. So either a bug in it, in some archiver or in some compatibility. From the stacktrace I couldn't undestand what exactly that value is. I hope it is not an issue of creating a gorm file on a 64bit machine and reading it back on a 32bit or something like that! First thing, I will see if I can reproduce this on other machines. I do not see this on my workstation, but it is running on 64bit, with a different OS and with a different compiler and runtime :-P Too many differences. Riccardo
Re: Lost information converting decoded value to in32_t
Hi, after hacking an evening with this with Fred, I have an update. I hope Richard, Wolfgang, David... can chime in. I opened a PR with a proposed solution which "works" On 2020-05-25 07:50:26 + Fred Kiefer wrote: Looks like your archive has a value that gets encodes as an NSInteger and this is 32 bit on your current machine but the original encoded value was actually 64 bit and uses more than the 32 bit you are able to read. The best thing to do is to find out which value it is that causes the behaviour and encode (and decode) it as a long. And to answer your question, the message itself is surely not a bug, it just shows how clever base tries to deal with different encoded values. The actual encoding may be a bug. There it would really help to know where it is coming from. The issue is in NSUnarchiver itself, around line 1401. The unarchived NSInteger coming from the gorm file is just "2": However the tests fail, even with simulations: (gdb) p big $1 = 2 (gdb) p big > 2147483647 $2 = 0 (gdb) p big < -2147483648 $3 = 1 What is interesting, if gdb follows the same literal rules and promotions of GCC: (gdb) p (int64_t)-2147483648 $8 = 2147483648 (gdb) p (int64_t)-2147483648l $9 = 2147483648 (gdb) p (int64_t)-2147483648L $10 = 2147483648 (gdb) p (int64_t)-2147483647 $15 = -2147483647 Whatever I do as a literal suffix, it comes out positive. One value less and it works. Here I am at loss with types and constants. Looking up on the internet, I found the explanation is that the literal is only the number part without signed, regarless if it is a signed or unsigned decimal. Then the - operator is performed. For this reason it is usually written as (-2147483647 -1) in the limits header files. With that explanation, it is promoted to the "unsinged" type and then the "-" operation fails and underflows. For that reason I propose to change the lower bounds check to an equivalent easy to read if (big > 2147483647 || big + 2147483648 < 0 instead of the "minus 1" trick. I wanted to open a PR on an "fix_32bit_decode" branch, but apparently... everything got pushed to master without the branch. Sorry. So please if you disagree, revert and fix with the style you prefer. Also, perhaps, technically, we should apply the same style for int8-t and int16_t although we perhaps will never encounter that because minimum literal type is "int". Riccardo
