Re: ANN: GNUstep Windows MSVC Toolchain Scripts
Frederik, Congratulations on this release! Wonderful! GC On Wed, Mar 17, 2021 at 5:39 PM Frederik Seiffert wrote: > 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 dependencies, plus also > libdispatch. Invoking build.bat from an x86 or x64 Visual Studio developer > command prompt will build all libraries for that architecture for both > debug and release CRT libraries. Each library is either build directly in > the Windows shell (libobjc2, libiconv, libxml2, libxslt), or an MSYS2 Bash > shell is spawned for libraries requiring such an environment (libffi, > GNUstep Make/Base). > > I only found usable pre-built binaries for Pthread-win32 and ICU (and no > good way to integrate NuGet packages), so all the others are built from > source. Since building for MSVC is far from standard for projects coming > from Unix (but fortunately always supported in some way it seems), each of > them requires their very own special setup, and required a lot of massaging > to get everything working. > > The resulting set of DLLs should be usable to integrate Objective-C code > in basically any Windows app that is not using MinGW, using either clang or > clang-cl to build ObjC code. The Readme contains some info on the required > compiler and linker flags. Hopefully down the line we can also get other > GNUstep libraries on board as to offer a more complete GNUstep package for > Windows MSVC. > > (I also took a brief stab at trying to build Objective-C code in Visual > Studio, but unfortunately it adds a /TP flag forcing clang-cl to treat the > input as C++ (just like CMake). I’m guessing there are ways around this as > WinObjC was able to integrate ObjC files in VS, which we can hopefully > figure out some time.) > > While many tests in Base are still failing for various reasons, I plan on > spending more time on this in the coming months and will also try to add > MSVC to the Travis CI setup so we can ensure the configuration stays > supported. I already set up CI via GitHub Actions for the scripts > themselves (not running any tests atm.). (And btw. GitHub Actions runners > seem *much* faster than Travis CI.) > > Thank you all and especially David for helping me get this working, and > bearing with me through all my messages to the mailing list on this topic > over the last year! I’m looking forward to see what comes out of this > effort. > > Frederik > > > -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://gf.me/u/x8m3sx - My GNUstep GoFundMe https://teespring.com/stores/gnustep - Store
Re: GNUstep releases this month?
I am thinking of doing it this weekend, any objection? sent from phone On Wed 3 Mar 2021, 20:05 Riccardo Mottola, wrote: > Hi, > > Richard Frith-Macdonald wrote: > > I haven't actually tested, but I did look at the diffs and read up on > the difference between Get/SetWindowLong and Get/SetWindowLongPtr, and it > all makes sense to me ... I was unable to reproduce the problem on my > system simply because, thorugh chance, the windows the system was giving me > all existed in the low part of the address space. > > The only error is spotted in the change was in WIN32Server.m when > styling a popup window ... here LONG (32bit) is used to hold the style > information, where the API requires LONG_PTR (64bit). > > This would have the catastrophic effect of losing style information for > popup windows for all those many users of 64bit windows on a big-endian CPU > :-) > > really catastrophic. Since 64bit is only supported since Windows 2000, I > think that would restrict to Alpha, since PPC was only supported in NT4 > if I am right :) And no mingw outside intel, AFAIK. > > Still, not elegant.. I think I just found the spot and addressed it in > my last commit. > > I'll write some changelog and open a PR, just in time for the release! > > Riccardo >
Re: ANN: GNUstep Windows MSVC Toolchain Scripts
That's great news, congratulations! 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 using the gcc-compatible driver, we have the same problem with /TP being added. We work around this with an undocumented feature of clang where you can provide an environment variable that removes flags from the command line. You can probably set that in your Visual Studio build. Setting this strips the TC and TP flags from clang invocations: CCC_OVERRIDE_OPTIONS=x-TC x-TP x/TC x/TP It would be great at some point to remove the pthread-w32 dependency. SRWLocks and ConditionVariables on Windows seem to provide everything we need for NSLock* and be a fairly small amount of code. David On 17/03/2021 21:39, Frederik Seiffert wrote: 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 dependencies, plus also libdispatch. Invoking build.bat from an x86 or x64 Visual Studio developer command prompt will build all libraries for that architecture for both debug and release CRT libraries. Each library is either build directly in the Windows shell (libobjc2, libiconv, libxml2, libxslt), or an MSYS2 Bash shell is spawned for libraries requiring such an environment (libffi, GNUstep Make/Base). I only found usable pre-built binaries for Pthread-win32 and ICU (and no good way to integrate NuGet packages), so all the others are built from source. Since building for MSVC is far from standard for projects coming from Unix (but fortunately always supported in some way it seems), each of them requires their very own special setup, and required a lot of massaging to get everything working. The resulting set of DLLs should be usable to integrate Objective-C code in basically any Windows app that is not using MinGW, using either clang or clang-cl to build ObjC code. The Readme contains some info on the required compiler and linker flags. Hopefully down the line we can also get other GNUstep libraries on board as to offer a more complete GNUstep package for Windows MSVC. (I also took a brief stab at trying to build Objective-C code in Visual Studio, but unfortunately it adds a /TP flag forcing clang-cl to treat the input as C++ (just like CMake). I’m guessing there are ways around this as WinObjC was able to integrate ObjC files in VS, which we can hopefully figure out some time.) While many tests in Base are still failing for various reasons, I plan on spending more time on this in the coming months and will also try to add MSVC to the Travis CI setup so we can ensure the configuration stays supported. I already set up CI via GitHub Actions for the scripts themselves (not running any tests atm.). (And btw. GitHub Actions runners seem *much* faster than Travis CI.) Thank you all and especially David for helping me get this working, and bearing with me through all my messages to the mailing list on this topic over the last year! I’m looking forward to see what comes out of this effort. Frederik
