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. On Fri, Mar 30, 2018 at 11:10 AM, Fred Kiefer <fredkie...@gmx.de> wrote: > I tried to reproduce this error but failed. Either it is a local problem on > your machine or it was already fixed. Could you please try again? > > Fred > >> Am 30.03.2018 um 00:53 schrieb Riccardo Mottola <riccardo.mott...@libero.it>: >> >> 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 > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
