Windows build broken on weekly build, 1.1.2 latest doesn't have a windows version

[drmclem]

Hi

Downloaded the weekly build version and it fails on entry point not found libaws-cpp-sdk-s3.dll - the latest release version doesn't have a windows build - last version which works is GDL - GNU Data Language, Version v1.1-dirty.

Matthew

[GillesDuvert]

@drmclem thanks for the report, this seems pretty strange as gdl does absolutely not need any interface to Amazon Web Services (and if it does, then this dependency must be removed at once!)
(This seen from my linux point-of-view of course)
Probably a system library used by GDL or the windows installer needs it. Afraid I cannot help you on a Windows subject, hopefully somebody else will have an answer.

[drmclem]

these are all being installed from the msi installed from the weekly assets

Also these files are in the .zip file as well as the gdlsetup...msi

[fawltylanguage]

HDF5 dependency?

[GillesDuvert]

probably just download it from the web? I found https://www.dllme.com/dll/files/aws-cpp-sdk-s3

[drmclem]

Hi all - I just wanted to update on some info on this one and windows building in general. Managed to set up and build gdl with windows on Win 11 but have several issues with mixed package types which may explain the failure of windows build asset from earlier. In short,

• yes the quick one - libaws is a dependency on hdf5

The longer one -

• When a default MSYS2 is installed it presents 4 working environments and by default opens the ucrt runtime linkage, but the build scripts and instructions on the WIKI don't correctly pick this up instead defaulting to the MSVCRT versions so you can end up with odd packages being collected for the install. When running the UCRT64 environment, everything is under /ucrt64 not /mingw64 but the scripts copy from the deep link - /msys64/mingw64 ... which is not the default).

The MSYS2 does now seem to provide useful environment variables to help with this - I have made the necessary mods to the build script and tested it on my build system for the ucrt and it all seems to work better now (as an aside - I wanted the UCRT version to use with the CALL_EXTERNAL function)

I have update the build_gdl.sh to use the provided environment variables

declare -x MSYSTEM="UCRT64"
declare -x MSYSTEM_CARCH="x86_64"
declare -x MSYSTEM_CHOST="x86_64-w64-mingw32"
declare -x MSYSTEM_PREFIX="/ucrt64"

Which should work for all the variants as long as the dependant packages are available (which they are for MSVCRT and UCRT - happy to push to a branch and pull request if helpful - also I think the wiki instructions could be improved with the changes to MSYS2 environments and defaults - again happy to edit if wanted.

This may help with building windows versions - if possible I would suggest providing information on which runtime is used - the gdl built with MSVCRT will not load UCRT dll's from call external and vice versa but can be tricky to track down why.

[GillesDuvert]

@drmclem many many thanks for this detailed explanation. At the time we last looked into the build-gdl.sh script to make it work on Windows, UCRT did not appear in our field of view. Time has passed obviously. And the current maintainers of GDL are, if I'm not mistaken 😄 only unix or osx aficionados. No surprise that the Window port has been neglected.
We warmly welcome you to submit a PR with all changes needed to have a decent rebuild on Windows!
May I suggest, as hinted at in https://www.msys2.org/docs/environments/ that build-gdl.sh enforce the use of UCRT. I guess it will be easier to maintain only one 'flavour' especially for us non windozers.

[GillesDuvert]

@drmclem at least could you suggest text for the wiki instructions as mentioned?
Thanks in advance