Hi, If anyone is interested in that configuration, please clone CLN from git, read INSTALL.windows, then check out 0562f5d42f64, and report back to this list how it works (make check) what exactly they did and what their environment was. We've had a self-contradictory AI-generated problem report and "solution description" here: https://codeberg.org/ginac/cln/issues/1 We do appreciate if people are being helpful and let AI generate problem reports and solutions. But we also expect the people commanding the AI to turn the AI results into concise bug reports and, if possible, patches. Thanks. Happy hacking, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Richard B. Kreckel wrote:
If anyone is interested in that configuration, please clone CLN from git, read INSTALL.windows, then check out 0562f5d42f64, and report back to this list how it works (make check) what exactly they did and what their environment was.
Since I still have a VM with Windows, Cygwin, MSVC around, I gave it a try. Although we did support MSVC in the past, some changes in the environment or tools lead to failure. I see two problems: - In the 64-bit MSVC build, include/cln/host_cpu.h define __i386__, not __x86_64__. - Since GMP does not build out of the box on MSVC, I'm using the configure option --without-gmp. The compiler ignores the file cl_asm.S, and the link command then fails because base/digitseq/cl_asm.obj does not exist. Before I come to solving these, I'm pushing a couple of build system improvements. Then, later, I'll try some newer MSVC too. Bruno
- In the 64-bit MSVC build, include/cln/host_cpu.h define __i386__, not __x86_64__.
This is now fixed. The problem was in the CL_CANONICAL_HOST_CPU macro, that had not been updated for many years. The corresponding macro gl_HOST_CPU_C_ABI from Gnulib is better maintained, so I changed configure.ac to use that. Bruno
Richard B. Kreckel wrote:
We've had a self-contradictory AI-generated problem report and "solution description" here: https://codeberg.org/ginac/cln/issues/1
I've pushed a fix for the mulu32_ / divu_6432_3232_ part of this report. More to come... Bruno
participants (2)
-
Bruno Haible
-
Richard B. Kreckel