https://bugs.winehq.org/show_bug.cgi?id=51465
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- (In reply to algebro from comment #20)
I don't quite recall what the motivations for switching to ucrtbase were, but I suspect they were along the lines of "ucrtbase is newer and therefore objectively better". Which is true, but unfortunately it seems like we still need to use msvcrt...
Do you have any idea as to how open the other maintainers would be to a rollback like this? I'm working out some linker errors with that patch now but I didn't want to waste people's time if they're uncomfortable going back to a deprecated runtime
I don't really, no. I should probably have already added Jacek to CC already. Jacek, do you have thoughts on this? Are there reasons for the switch to ucrtbase that I missed or forgot?
(In reply to algebro from comment #22)
I'm a little confused because if I'm reading makedep.c correctly, the -mno-cygwin flag should automatically have this being built with msvcrt anyway:
make->use_msvcrt = strarray_exists( &make->extradllflags, "-mno-cygwin" );
When switching to ucrt with d0bf94, the `mno-cygwin` flag remained and they just added ucrtbase to the imports, and later removed ucrtbase in af12270. Was there some other change related to ucrt that would mess up the linking here?
"use_msvcrt" is meant here as in contrast to glibc. As far as that naming is concerned, ucrtbase is another version of msvcrt (specifically version 140).
lrintf() is a function exported by ucrtbase but not msvcrt. As such we'd need to import ucrtbase in dsound (or find some substitute for lrintf).