On Tue, 19 Dec 2017, Liu Hao wrote:
On 2017/12/19 20:13, Martin Storsjö wrote:
This matches what MSVC does.
Signed-off-by: Martin Storsjö <[email protected]>
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++
mingw-w64-crt/lib-common/ucrtbase.def.in | 4 ++++
2 files changed, 6 insertions(+)
On my 64-bit Win7 only MSVCRT has this function exported. The x86 MSVCRT
in turn calls `utime32()` while the x64 one calls `_utime64()`. These
functions are not exported by any UCRTBASE.DLL here.
That's not what I said it does either. I said that MSVC has got similar
linker aliases in their CRT library:
$ cat test.c
void utime(void); int main(int argc, char* argv[]) { utime(); return 0; }
$ cl -nologo -c -MD test.c
test.c
$ dumpbin -symbols test.obj | grep utime
008 00000000 UNDEF notype () External | utime
$ cl -nologo test.obj -Fetest.exe
$ dumpbin -imports test.exe | grep utime
34 _utime32
(Tested with the x64 compiler; the x86 one is identical except the
decorated symbol name in the object file.)
Repeat the same test for utime, _utime, _futime and _wutime and see that
even if object files refer to them with an unsuffixed name, the linked
executable still ends up referring to the suffixed name with an underscore
- independently of what the headers do.
We could of course also redirect it in the headers as we do with a number
of other functions, but since MSVC even has got linker aliases for these
functions, thi approach gives us compatibility on a second level as well
all at once.
// Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
