Re: tools-windows-msvc runtime error

t inserts random padding into the > Objective-C runtime’s metadata sections, which corrupt various things. > > David > >> On 18 Jul 2023, at 08:34, Frederik Seiffert wrote: >> >> Thanks, I reproduced the issue here. It turns out using the Microsoft linker >> causes this iss

Re: tools-windows-msvc runtime error

Thanks, I reproduced the issue here. It turns out using the Microsoft linker causes this issue, but using LLD works fine. I’m not sure why or since when this is, as using link.exe definitely worked for me at one point, but now using either VS 2019 or 2022 causes this crash as soon as

NSFileManager thread safety

Hi all, We’re running into what seems to be a concurrency issue (on Windows) where our app crashes when concurrently calling -[NSData writeToFile:options:error:] (on separate NSData objects) from multiple threads. I noticed that the method uses +[NSFileManager defaultManager], which I think

Re: tools-windows-msvc runtime error

Can you send the backtrace of the crash ("bt" in LLDB)? > Am 16.07.2023 um 15:23 schrieb loserist : > > Hi all! I seem to have found the problem.the problem is that the user-defined > class is not working properly, see the following code and its output message > please.Does anyone know how to

Re: 来自bellabs的邮件

Can you send a backtrace of the crash („bt“ command in LLDB)? > Am 13.07.2023 um 05:41 schrieb bellabs : >  > Thanks for the reminder again, the reason I couldn't run lldb's before was > because the version of python I installed didn't match, now it works fine! I > get the following error

Re: 来自bellabs的邮件

Hi, I just realized we had the following note in our readme (https://github.com/gnustep/tools-windows-msvc), which I think might help you get LLDB working on Windows: > When utilizing the built-in gnustep-make test suite's debug capabilities, the > preferred debugger on Windows is lldb. lldb

Re: 来自bellabs的邮件

I’d suggest trying VS instead, the Community Edition is free if that applies to you: https://visualstudio.microsoft.com/vs/community/ When launching VS just open the .exe to debug it. For LLDB I think you need the right Python DLL in your path. Not sure why Windows isn’t telling you which one

Re: Object creation error

What’s %errorlevel% after running your executable? If it’s 0 it’s not crashing but your console is not showing the log output. You should be able to see the output with DebugView: https://learn.microsoft.com/en-us/sysinternals/downloads/debugview > Am 01.07.2023 um 10:51 schrieb bellabs : >

Re: Error About GNUstep Windows MSVC Toolchain linking Error.

Can you provide the error that happens when running the app? It might also help to run it with the Visual Studio debugger. > Am 30.06.2023 um 16:27 schrieb bellabs : > > It's because it doesn't work so that I'm asking. > > At 2023-06-30 21:58:56, "Frederik Seiffert"

Re: Error About GNUstep Windows MSVC Toolchain linking Error.

I’m not sure but I think you can ignore those linker warnings. Does the executable work? > Am 30.06.2023 um 15:28 schrieb bellabs : > > Hey Everyone! > I compiled my OC++ program using the pre-compiled library provided in > https://github.com/gnustep/tools-windows-msvc with following

Re: Releases

> Am 10.01.2023 um 14:27 schrieb Ivan Vučica : > >> I really would like to minimise the number of steps we have to go through by >> automating as much as possible. > > I did. :-) > > Please see my release jottings on Google Docs. They’re not formal > documentation, but can be interpreted as

Re: minimum compiler requirements - fast enumeration

I’d be all for this. FWIW there’s also the FOR_IN/END_FOR_IN macros in GSFastEnumeration.h, which use fast enumeration with Clang and seem to emulate it with other compilers. > Am 31.01.2022 um 10:40 schrieb Richard Frith-Macdonald : > > A few years ago we declared gcc-4.0 as our minimum

Re: warning when compiling base and other programs

Hi Riccardo, > Am 23.11.2021 um 23:34 schrieb Riccardo Mottola : > > in this case it is coming from gcc 7.5, but I have seen it in other gcc > versions too. like gcc 11 Not sure then why the warning is happening, according to the GCC docs it should be supported:

Re: warning when compiling base and other programs

I recently added NS_FORMAT_ARGUMENT to -[NSBundle localizedStringForKey:...] (that macro was previously unused): https://github.com/gnustep/libs-base/commit/87783e25137b4159dd846bf645aa907371615e8c Which

Re: Building GUI with libobjc2 for Windows MSVC

Hi David, Sorry it took me a while to give this a try. > Am 27.10.2021 um 14:36 schrieb David Chisnall : > > Since all of them end with a close brace, I suspect that there's something in > the field names that isn't a valid PE/COFF symbol name (at least for > dllexported things, not sure if

Re: Building GUI with libobjc2 for Windows MSVC

d, libcxx or others too? Thanks, Frederik > Am 25.10.2021 um 17:42 schrieb David Chisnall : > > Hi, > > If you can comment on the review and approve it, I can commit it (once I’ve > fixed the clangformat warnings). > > David > >> On 23 Oct 2021, at 16:33, Fre

Re: Building GUI with libobjc2 for Windows MSVC

Hi David, > Am 14.10.2021 um 13:59 schrieb David Chisnall : > > I believe this patch should fix it: > > https://reviews.llvm.org/D111792 Thank you, this worked great after I built Clang 13 with this patch applied! What’s the process for getting this merged, and and any idea when we could

Re: Building GUI with libobjc2 for Windows MSVC

Hi David, > Am 13.10.2021 um 19:13 schrieb David Chisnall : > > I believe that this is a bug in clang. If the class is dllexported then the > ivar offset variables for public / protected ivars should be dllexported as > well. I think I missed that case when doing the Objective-C support for

Building GUI with libobjc2 for Windows MSVC

Hi all, I’ve started looking into building libs-gui for Windows using libobjc2 and the MSVC ABI, and I’m down to one linker error that I’m unsure how to deal with: > lld-link: error: undefined symbol: __objc_ivar_offset_NSFileWrapper._icon.☺ > >>> referenced by NSFileWrapperExtensions.m:42 >

Re: Attempting migration from travis-ci.org -> travis-ci.com

That’s great, thank you Greg. Also runs so much faster now. > Am 14.07.2021 um 15:01 schrieb Gregory Casamento : > > BTW, I do plan to add support for other OS's going forward. I just wanted to > get something up and running for now so we don't break the build. > > On Wed, Jul 14, 2021 at

Re: GNUstep releases this month?

> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald > : > > IIRC the standard/historic behavior is that an object can retain itself in > the -dealloc method, to extend its own lifetime, and I guess that the > singletons do that (I haven't checked). > I think that behavior changed for

Re: GNUstep releases this month?

> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald > : > >>> Throwing 0x247a578, in flight exception: 0x244e748 >>> Exception caught by C++: 0 > > appears to be a libobjc bug (one that Riccardo mentioned to me). I think this is just debug output from libobjc2 exception handling, not an

Re: GNUstep releases this month?

> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald > : > > I was just looking at that. The tests are passing for me on debian-10 (gcc) > and fedora-33 (with both gcc and clang with libobjc2 from some months ago) That’s good at least. > I'm guessing that the issue is a recent libobjc2

Re: GNUstep on Windows using Clang + MSVC ABI

Hi David, > Am 02.02.2021 um 12:29 schrieb David Chisnall : > lld-link: error: relocation against symbol in discarded section: __start_.objcrt$SEL >>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init) This is reproducible when building a file that calls ObjC runtime

Re: GNUstep releases this month?

> Am 19.03.2021 um 16:40 schrieb Ivan Vučica : > > I am thinking of doing it this weekend, any objection? The NSFileHandle/singleton tests in Base have been failing for the last couple commits. The test logs look like this – trying to release the singletons correctly throws an exception,

Re: ANN: GNUstep Windows MSVC Toolchain Scripts

Hi David, > Am 19.03.2021 um 15:58 schrieb David Chisnall : > > That's great news, congratulations! Thank you for all your help making it happen! > If you look at the build for libobjc2 on Windows, because we're using a CMake > version that predates official support for either Objective-C or

ANN: GNUstep Windows MSVC Toolchain Scripts

I am pleased to announce a new GNUstep project containing a set of scripts to build GNUstep for Windows with Clang and libobjc2 using the Visual Studio toolchain and MSVC ABI (i.e. without MinGW): https://github.com/gnustep/tools-windows-msvc The scripts currently build GNUstep Base with all

Re: libobjc2 on OpenBSD 6.8 build errors - C++ runtime not found

Hi Riccardo, > Am 02.02.2021 um 15:22 schrieb Riccardo Mottola : > > -- No useable C++ runtime found > > > why doesn't it like my runtime library? The crude way I’ve been debugging the C++ runtime detection (in my Android/Windows endeavors) was by logging the output from try_compile() with

Re: GNUstep on Windows using Clang + MSVC ABI

Sorry everyone, looks like my earlier draft got sent out prematurely... > Am 29.01.2021 um 17:28 schrieb David Chisnall : > > ld -r is pretty flaky everywhere. LLD wasn't going to implement it at all > and GNUstep was one of only two consumers so I think it's fair to say that > it's pretty

Re: GNUstep on Windows using Clang + MSVC ABI

>> - Linking subproject object files directly (instead of merging) >> As David had suspected, merging the subproject object files turned out to be >> an issue: `ld -r` is not available on Windows, and using `ar cr` resulted in >> a subproject.o that didn’t contain all the symbols (I’m guessing

Re: Building GNUstep for Windows using Clang

Hi David, > Am 21.01.2021 um 15:00 schrieb David Chisnall : > > It looks as if you are missing the dllimport attribute on the classes that > you're referencing from another DLL. Thanks so much, that was indeed it! My little DLL test setup is working now. I thought I had tried that before, but

Re: Building GNUstep for Windows using Clang

Hi David, > Am 20.01.2021 um 18:15 schrieb David Chisnall : > > For reference, the $_OBJC_CLASS symbols are meant to be exported from a DLL, > they are the canonical pointers to the classes. The $_OBJC_REF_CLASS > pointers are private to a library and are the pointer that code should use >

Re: Building GNUstep for Windows using Clang

m just missing some flag somewhere when creating the DLL. I’d appreciate any thoughts. Thanks! Frederik > Am 19.01.2021 um 20:50 schrieb Frederik Seiffert : > > Hi David, > >> Am 19.01.2021 um 18:40 schrieb David Chisnall > <mailto:gnus...@theravensnest.org>

Re: Building GNUstep for Windows using Clang

Hi David, > Am 19.01.2021 um 18:40 schrieb David Chisnall : > > On ELF platforms, there were some issues with the ld -r invocation that -base > Additions did. Can you try just adding the .m files from Additions directly > to the -base project and see if that makes the problem go away? I

Re: Building GNUstep for Windows using Clang

e referencing ObjC built-ins in a C file doesn’t work on Windows. I’m planning to skip these config checks when using this setup. Thanks, Frederik > Am 12.01.2021 um 21:47 schrieb Frederik Seiffert : > > Hi all, > > As a second option I’ve been working on trying to build using the

Re: Building GNUstep for Windows using Clang

Hi all, As a second option I’ve been working on trying to build using the MSVC ABI (i.e. without MinGW). Using the latest Clang 11 from the LLVM website and Pthreads-win32, plus removing -lm from target.make, I was able to get quite a bit further running Base configure. However, it fails

Re: Building GNUstep for Windows using Clang

Hi all, I’ve made a bit of progress getting libobjc2 working under MinGW, including adding it to the CI test matrix (currently using stock Clang). Here’s the PR in case anyone wants to follow along on GitHub: https://github.com/gnustep/libobjc2/pull/190 I tried building it with a patched Clang

Re: GNUstep base fails - libobjc2 on NetBSD x86

ola : > > Hi Frederik, > > > On 1/3/21 3:26 PM, Frederik Seiffert wrote: >> Looks like the conftest executable is aborting. Can you try running it with >> a debugger to see where it fails? > > > I couldn't find the conftest binary after the failure, seems it d

Re: GNUstep base fails - libobjc2 on NetBSD x86

Hi Riccardo, Looks like the conftest executable is aborting. Can you try running it with a debugger to see where it fails? Frederik > Am 02.01.2021 um 23:14 schrieb Riccardo Mottola : > > Hi, > > I am still struggling to get GNUstep running on NetBSD/i386... strange thing. > I am trying

Re: Building GNUstep for Windows using Clang

Hi David, > Am 29.12.2020 um 15:57 schrieb David Chisnall : > > Hi all, > > Sorry for the delayed response, I’ve now had time to do a little bit of > digging to understand what’s needed here. Thank you very much, this is super helpful. >> 1. Support building GNUstep with MSVC > > To

Re: Building GNUstep for Windows using Clang

Hi David and all, > Am 02.12.2020 um 20:20 schrieb David Chisnall : > > I am not sure if there is a good way of fixing this other than to use a MSVC > target triple. C++ EH interop almost certainly won't work if MinGW is > targeting the Itanium ABI for C++ and I really don't want to support

Re: GUi stopped compiling

ICU release 68 changed their usage of primitive types, and removed the TRUE and FALSE defines as outlined here: https://github.com/unicode-org/icu/blob/master/docs/userguide/dev/codingguidelines.md#primitive-types You’ll probably need to patch Gui in some way. For Base I simply defined

Re: Building GNUstep for Windows using Clang

And here are the MinGW-w64 Clang packages built with both of David’s patches in case anyone wants to play around with it: https://algoriddim-djay.s3.us-east-1.amazonaws.com/tmp/mingw-w64-i686-clang-11.0.0-4-any.pkg.tar.zst

Re: Building GNUstep for Windows using Clang

> Am 02.12.2020 um 20:20 schrieb David Chisnall : > > It looks as if the code to check which personality function is outside the > runtime-specific code. The attached diff should fix that. FYI these are the linker errors after building Clang with this patch added also: > lld-link: error:

Re: Building GNUstep for Windows using Clang

> Am 02.12.2020 um 20:20 schrieb David Chisnall : > > It looks as if the code to check which personality function is outside the > runtime-specific code. The attached diff should fix that. Thanks! I will try that. > This looks as if clang is still trying to use the Itanium C++ ABI. When the

Re: Building GNUstep for Windows using Clang

> Am 01.12.2020 um 15:42 schrieb David Chisnall : > > Please can you try the attached patch? So the patch resolves the objc_begin_catch/objc_end_catch undefined symbols, but it doesn’t resolve __gnustep_objc_personality_v0 and adds some new linker errors ones: > lld-link: error: undefined

Re: Building GNUstep for Windows using Clang

> Am 02.12.2020 um 17:07 schrieb Gregory Casamento : > > Just a suggestion. Could you commit the binary resulting from the build? > While David might disagree, this is a very heavyweight and difficult build > process. I would prefer to spare others from having to go through it. If >

Re: Building GNUstep for Windows using Clang

> Am 02.12.2020 um 10:50 schrieb David Chisnall : > > You should be able to just do a Windows build with the VS command prompt and > CMake. I normally build clang with CMake + Ninja + either Visual Studio or > an existing LLVM install on Windows. There are no other dependencies. Thanks,

Re: Building GNUstep for Windows using Clang

> Am 01.12.2020 um 15:42 schrieb David Chisnall : > > Please can you try the attached patch? That was quick, thank you very much! I’m having some trouble building Clang via MINGW-packages (https://github.com/msys2/MINGW-packages/issues/7369), but I’ll let you know as soon as I get that to

Re: Building GNUstep for Windows using Clang

Hi Riccardo, > Am 01.12.2020 um 16:27 schrieb Riccardo Mottola : > > just as a note, I tried an update with current ming64 and gcc and things > work as before (nothing broke!) > Actually, there is an improvement, JPEG images work because I fixed it > some weeks ago! Nice, thanks! > I noticed

Re: Building GNUstep for Windows using Clang

> Am 30.11.2020 um 17:59 schrieb David Chisnall : > > I think this is a clang bug. I am probably guarding this on an MSVC target > triple and not on SEH exceptions. Please can you file a clang bug and assign > it to me? https://bugs.llvm.org/show_bug.cgi?id=48348 I hope I summarized this

Re: Building GNUstep for Windows using Clang

Thanks David! After a couple of PRs we’re now down to a linker issue regarding exception handling on Windows. Details and steps to reproduce here: https://github.com/gnustep/libobjc2/issues/187 > These are pretty-much unavoidable on Windows. In C/C++, you typically use a > macro to control

Re: Building GNUstep for Windows using Clang

Hi all, I took another stab at building for Windows, and using a fresh MSYS2 installation and the latest dependencies and Clang version I was able to make a bit of progress and run into some new issues... After building libobjc2 in a Visual Studio prompt and getting Make to build (more on

Re: Building GNUstep for Windows using Clang

and tests fixed. Frederik > Am 15.05.2020 um 10:00 schrieb Frederik Seiffert : > > Hi all, > > Following up on this thread I wanted to give a quick update on building > GNUstep for Windows. > > First, I managed to build Base successfully using GCC on MinGW 64-bit > f

Re: Building GNUstep for Windows using Clang

Hi all, Following up on this thread I wanted to give a quick update on building GNUstep for Windows. First, I managed to build Base successfully using GCC on MinGW 64-bit following Riccardo’s helpful instructions at http://wiki.gnustep.org/index.php/Installation_MSYS2. Two small things here

Re: Building GNUstep for Windows using Clang

> Am 07.03.2020 um 12:33 schrieb Riccardo Mottola : > > since several people asked about it, I will collect and share my work here: > > > http://wiki.gnustep.org/index.php/Installation_MSYS2 > Thank you Riccardo! I’ll follow along and

Re: Building GNUstep for Windows using Clang

Hi David, > Am 06.03.2020 um 17:51 schrieb David Chisnall : > >> I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t >> support the -r flag for incremental linking. > > Hmm, that probably means that -base Additions won't build. Ah makes sense. So I guess that means we

Re: Building GNUstep for Windows using Clang

ng on looking at some of the Clang funclet issues. That’s good to know, thanks. By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows? Seems like WinObjC is not using it. Thanks, Frederik > Am 25.02.2020 um 19:22 schrieb David Chisnall : > > Hi, > > > > On 25/

Building GNUstep for Windows using Clang

Hi all, I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime ABI in order to have support for ARC and blocks, but I’m having some issues and general questions. I’ve successfully built libobjc2 (as well as libdispatch) in a Visual Studio command prompt using CMake and

Re: Cross-compilation

Hi Ladislav, You might want to have a look at the scripts of the GNUstep Android toolchain project, which cross-compiles GNUstep for Android: http://github.com/gnustep/tools-android Hope that helps, and let me know if you have any questions. Frederik > Am 10.01.2020 um 13:00 schrieb Ladislav

Re: Debugging on Linux with non-fragile ABI?

Thank you, that’s very helpful. Regarding LLDB support for the non-fragile ABI we’re in the process of trying to find someone to implement that. Frederik > Am 19.11.2019 um 11:30 schrieb Wolfgang Lux : > > >> Am 18.11.2019 um 10:12 schrieb Frederik Seiffert : >

Re: Debugging on Linux with non-fragile ABI?

tic that shows > you the correct ivar. > > David > > On 18/11/2019 09:12, Frederik Seiffert wrote: >> Hi Wolfgang, >> We’re running into very similar issues debugging using lldb with the GNUstep >> Android toolchain, which is using the modern (v2) ABI. Have you bee

Re: Debugging on Linux with non-fragile ABI?

Hi Wolfgang, We’re running into very similar issues debugging using lldb with the GNUstep Android toolchain, which is using the modern (v2) ABI. Have you been able to get any further with this? The following lldb command seems to indicate that the root cause might be lldb missing knowledge

Re: Please welcome Algoriddim to the GNUstep family

Thanks for the introduction Greg (and apologies for my belated response). We look forward to working with the GNUstep community! Frederik > Am 26.02.2019 um 23:02 schrieb Gregory Casamento : > > > All, > > I would like everyone to welcome Algoriddim to the GNUstep family. I have > been