Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
function. Therefore usage of snprintf() with this DLL library cause
application crash. Add simple fallback implementation of _vscprintf() just
for __ms_vsnprintf() to allow usage of snprintf() function also when using
original msvcr
Functions __ms_snprintf() and __ms_vsnprintf() contains same logic and code
around _vscprintf() and _vsnprintf() wrappers. Remove duplicated code from
__ms_snprintf() and redirects __ms_snprintf() to __ms_vsnprintf().
---
mingw-w64-crt/stdio/snprintf.c | 22 +-
1 file changed,
On Wednesday 29 December 2021 22:35:08 LIU Hao wrote:
> 在 2021-12-23 22:20, Pali Rohár 写道:
> > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > function. Therefore usage of snprintf() with this DLL library cause
> > application crash. Add simple fallb
On Friday 31 December 2021 00:30:37 Jacek Caban wrote:
> On 12/29/21 16:52, Martin Storsjö wrote:
> > On Wed, 29 Dec 2021, LIU Hao wrote:
> >
> > > 在 2021-12-23 22:20, Pali Rohár 写道:
> > > > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
Import library libcrtdll.a (for crtdll.dll runtime library) compiled during
mingw-w64 build process is currently broken and cannot be used for linking
executable applications.
Trying to do it results in following linker errors:
/usr/bin/i686-w64-mingw32-ld: .../i686-w64-mingw32/lib/crt2.o: in f
On Tuesday 11 January 2022 11:40:45 Martin Storsjö wrote:
> On Mon, 10 Jan 2022, LIU Hao wrote:
>
> > 在 2022-01-01 05:54, Pali Rohár 写道:
> > >
> > > Well, if you want from me any improvements in this patch, I can do it.
> > > Just let me know what is neede
Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
function. MinGW-w64 __ms_snprintf() and __ms_vsnprintf() implementations
call _vscprintf() function. So include fallback _vscprintf() implementation
into MinGW-w64 crt code to allow applications to use snprintf() with
original MSVC
Original MSVC 6.0 msvcrt.dll library does not provide _scprintf()
function. Add fallback _scprintf() implementation like for _vscprintf().
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/lib-common/msvcrt.def.in | 4 ++
mingw-w64-crt/misc/_scprintf.c | 52
On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> On Wed, 12 Jan 2022, Pali Rohár wrote:
>
> > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > function. MinGW-w64 __ms_snprintf() and __ms_vsnprintf() implementations
> > call _vscprint
On Friday 14 January 2022 13:45:38 Martin Storsjö wrote:
> On Fri, 14 Jan 2022, Pali Rohár wrote:
>
> > On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> > > On Wed, 12 Jan 2022, Pali Rohár wrote:
> > >
> > > > Original MSVC 6.0 msvc
On Friday 14 January 2022 01:36:10 Pali Rohár wrote:
> On Thursday 13 January 2022 23:22:10 Martin Storsjö wrote:
> > On Wed, 12 Jan 2022, Pali Rohár wrote:
> >
> > > Original MSVC 6.0 msvcrt.dll library does not provide _vscprintf()
> > > function. MinGW-w64 _
Currently v*scanf functions are broken and crash when are called with more
than 30 arguments in va_list. This is because va_list v*scanf functions are
redirected to variadic *scanf functions and this redirect implemented in
scanf.S file has fixed limit for 30 arguments.
Number of arguments for msv
On Monday 24 January 2022 13:41:27 Martin Storsjö wrote:
> On Sun, 16 Jan 2022, Pali Rohár wrote:
>
> > Currently v*scanf functions are broken and crash when are called with more
> > than 30 arguments in va_list. This is because va_list v*scanf functions are
> > redir
On Wednesday 26 January 2022 00:23:49 LIU Hao wrote:
> 在 2022-01-16 22:44, Pali Rohár 写道:
> > diff --git a/mingw-w64-crt/stdio/scanf2-argcount-template.c
> > b/mingw-w64-crt/stdio/scanf2-argcount-template.c
> > new file mode 100644
> > index ..c07e11797c39
crtdll.mri is used only for building 32-bit version of libcrtdll.a library.
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/{lib-common => lib32}/crtdll.mri | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/{lib-common => lib32}/crtdll.mri (100%)
d
Import library libcrtdll.a (for crtdll.dll runtime library) compiled during
mingw-w64 build process is currently broken and cannot be used for linking
executable applications.
Trying to do it results in following linker errors:
/usr/bin/i686-w64-mingw32-ld: .../i686-w64-mingw32/lib/crt2.o: in f
Currently v*scanf functions are broken and crash when are called with more
than 30 arguments in va_list. This is because va_list v*scanf functions are
redirected to variadic *scanf functions and this redirect implemented in
scanf.S file has fixed limit for 30 arguments.
Number of arguments for msv
MinGW-w64 has same startup files for crtdll.dll and msvcrt.dll and defining
-D__CRTDLL__ or -D__MSVCRT__ has no effect on built *crt*.o files, they are
same. So build startup files only once and create other as copy from the
first one. Also remove -D__CRTDLL__ and -D__MSVCRT__ as they are not used
Mark _vscprintf() and _scprintf() functions with attribute pure as their
return value depends only on passed arguments.
In function __ms_vsnprintf() check only for n==0 and move _vscprintf() call
at the end of function. This allows LTO to optimize out _vscprintf() call
from __ms_vsnprintf() functi
On Wednesday 26 January 2022 14:45:58 LIU Hao wrote:
> 在 1/26/22 04:05, Pali Rohár 写道:
> >
> > Yes, this is truth. However amd64 asm code already reads more pointers
> > from stack (when number of them is smaller then number of arguments
> > needed to pass via registe
On Tuesday 08 February 2022 11:22:12 Martin Storsjö wrote:
> On Tue, 8 Feb 2022, LIU Hao wrote:
>
> > 在 2/8/22 16:33, Martin Storsjö 写道:
> > > On Sun, 6 Feb 2022, Pali Rohár wrote:
> > >
> > > > Mark _vscprintf() and _scprintf() functions with attribute
On Tuesday 08 February 2022 11:25:43 Martin Storsjö wrote:
> On Sun, 6 Feb 2022, Pali Rohár wrote:
>
> > Currently v*scanf functions are broken and crash when are called with more
> > than 30 arguments in va_list. This is because va_list v*scanf functions are
> > redir
Object files in archive libcrtdll_extra.a (which are linked into import
library for crtdll.dll) cannot use msvcrt.h as it uses msvcrt.dll runtime
library.
So avoid using msvcrt.h and __mingw_get_msvcrt_handle() in crtdll.dll
runtime and directly use "setlocale_codepage_hack" implementation.
This
Currently macro __LIBMSVCRT__ is defined when building any libmsvcr*.a
import library. But header file msvcrt.h contains inline function
__mingw_get_msvcrt_handle() which should be used only from import library
for runtime msvcrt.dll (and not for any other runtime msvcr*.dll) as code
from that head
When assigning function pointer to variable, both function and variable
should have same signature. Fix it.
---
mingw-w64-crt/stdio/ucrt__vscprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_snprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_vsnprintf.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Redirect (v)snprintf() call with n==0 arg directly to _(v)scprintf() call
at compile time. With this change gcc can optimize out __ms_(v)snprintf()
call even when MinGW-w64 runtime was not compiled with LTO.
---
mingw-w64-headers/crt/stdio.h | 14 ++
1 file changed, 10 insertions(+), 4
Currently macro __LIBMSVCRT__ is defined when building any libmsvcr*.a
import library. But header file msvcrt.h contains inline function
__mingw_get_msvcrt_handle() which should be used only from import library
for runtime msvcrt.dll (and not for any other runtime msvcr*.dll) as code
from that head
Object files in archive libcrtdll_extra.a (which are linked into import
library for crtdll.dll) cannot use msvcrt.h as it tries to load symbols at
runtime from msvcrt.dll using GetProcAddress().
So avoid using msvcrt.h and __mingw_get_msvcrt_handle() in crtdll.dll
runtime and directly use "setloca
When gcc was compiled with crtdll config then it links binaries with
-lcrtdll instead of -lmsvcrt and predefines macro __CRTDLL__.
So when __MSVCRT_VERSION__ was not manually set and gcc is not going to use
-lmsvcrt then set __MSVCRT_VERSION__ to 0x00 to indicate that msvcrt.dll is
not used.
---
MinGW-w64 (v)snprintf() implementation uses windows functions _(v)snprintf()
and _(v)scprintf(). Runtime library crtdll.dll provides only _(v)snprintf(),
so include MinGW-w64 emulation of _(v)scprintf() functions into libcrtdll.a
import library.
As header file and __mingw_get_msvcrt_handle() func
crtdll.dll runtime does not suppport 64-bit printf/scanf modifiers. So when
targeting crtdll.dll runtime and not using MinGW-w64 stdio functions then
do not define any 64-bit modifier in inttypes.h header file.
crtdll.dll does not interpret %I64d modifier and does not read next
argument from varia
---
mingw-w64-headers/crt/stdio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index d96f5c96fc65..dd0f324db2be 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -721,6 +721,7 @@ int vsnprintf (
---
mingw-w64-headers/crt/stdio.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index dd0f324db2be..76fffa177b10 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -732,6 +732,7 @@ int vsnprintf (c
It would be used also in followup changes.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/crt/crtdll_compat.c | 5 -
mingw-w64-crt/misc/dummy__setusermatherr.c | 11 +++
3 files changed, 12 insertions(+), 5 deletions(-)
create mode 100644 mingw-w64-crt/
It would be used also in followup changes.
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/crt/crtdll_compat.c | 6 --
mingw-w64-crt/stdio/mingw_dummy__lock.c | 12
3 files changed, 13 insertions(+), 6 deletions(-)
create mode 100644 mingw-w64-crt/stdio/m
crtdll.dll and ucrt needs same implementation of __initenv and __winitenv
symbols. Deduplicate code and move it into a new misc/__initenv.c file.
---
mingw-w64-crt/Makefile.am | 2 ++
mingw-w64-crt/crt/crtdll_compat.c | 6 --
mingw-w64-crt/crt/ucrtbase_compat.c | 5 -
mingw-
2003 and it
supports loadable plugins, then new plugin may be developed and compiled
by mingw-w64 with linking to msvcr71.dll (Visual Studio 2003 CRT) via
libmsvcr71.a import library, which is build by this patch series.
Pali Rohár (7):
crt: Move implementation of __initenv and __winitenv to
This is CRT runtime library for Visual C++ 1.x (MSVC 8.00). It should be
distributed as a part of the application which use it. msvcrt10.def file
was generated from the original redistributable version of this library.
---
mingw-w64-crt/Makefile.am| 25 +-
mingw-w64-crt/lib32/msvcrt10.de
These are CRT runtime libraries for Visual Studio 2002 and 2003. These
libraries need to be installed separately via redistributable packages.
---
mingw-w64-crt/Makefile.am | 22 +-
mingw-w64-crt/lib32/msvcr70.def | 899
mingw-w64-crt/lib32/msvcr70.mri | 6
This is CRT runtime library for Visual C++ 4.0 (MSVC 10.00) and 4.1 (10.10).
It is present in every 32-bit x86 Windows as a system library.
msvcrt40.def file was generated from the original redistributable version
of Visual C++ 4.1 library.
---
mingw-w64-crt/Makefile.am| 18 +-
mingw-w6
This is CRT runtime library for Visual C++ 2.0 (MSVC 9.00) and is present
in every 32-bit x86 Windows as a system library.
---
mingw-w64-crt/Makefile.am| 20 +-
mingw-w64-crt/lib32/msvcrt20.def | 1570 ++
mingw-w64-crt/lib32/msvcrt20.mri |6 +
3 files chan
On Thursday 10 March 2022 15:01:20 Martin Storsjö wrote:
> Hi,
>
> On Mon, 7 Mar 2022, Pali Rohár wrote:
>
> > There are more variants of msvcrt runtime libraries and mingw-w64
> > currently does not build import library for each variant. Some variants
> > are ava
x86_64-w64-mingw32-gcc throws following -Wsign-compare warning when
compiling 64-bit NT kernel drivers which include ddk/ntddk.h file:
ddk/wdm.h: In function ‘RtlExtendedMagicDivide’:
ddk/wdm.h:9531:32: warning: operand of ?: changes signedness from ‘long long
int’ to ‘ULONG64’ {aka ‘long lon
On Thursday 10 March 2022 22:51:12 Pali Rohár wrote:
> On Thursday 10 March 2022 15:01:20 Martin Storsjö wrote:
> > Hi,
> >
> > On Mon, 7 Mar 2022, Pali Rohár wrote:
> >
> > > There are more variants of msvcrt runtime libraries and mingw-w64
> > > cur
---
mingw-w64-crt/crt/crtdll_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/crt/crtdll_compat.c
b/mingw-w64-crt/crt/crtdll_compat.c
index 0f0b8d4820da..7ab3a82984e0 100644
--- a/mingw-w64-crt/crt/crtdll_compat.c
+++ b/mingw-w64-crt/crt/crtdll_compat.c
@
Runtime library msvcrt10.dll like crtdll.dll does not provide support for
64-bit printf/scanf modifiers. So do not define them for msvcrt10.dll too.
---
mingw-w64-headers/crt/inttypes.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/crt/inttypes.h b/m
Import libraries for all these msvcrt versions are already as part of build
process.
---
mingw-w64-headers/configure.ac | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac
index 1307538ef480..d82280cd7515 100644
---
On Saturday 12 March 2022 19:14:49 Biswapriyo Nath wrote:
> Just curious. If you have compiled a kernel driver with mingw-w64,
> would you like to provide the project link? I am eager to learn it.
Yes, I successfully compiled NT kernel driver with mingw-w64.
But due to lot of bugs in GCC and GNU
---
mingw-w64-crt/Makefile.am| 3 +++
mingw-w64-crt/stdio/ucrt__scprintf.c | 21 +
mingw-w64-crt/stdio/ucrt__snprintf.c | 21 +
mingw-w64-crt/stdio/ucrt__snscanf.c | 21 +
4 files changed, 66 insertions(+)
create mode 10064
---
mingw-w64-headers/crt/stdio.h | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 76fffa177b10..1cebce723527 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@
---
mingw-w64-headers/crt/stdio.h | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 1cebce723527..45b21d2997fb 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/cr
#if condition does not contain _CRTBLD check
---
mingw-w64-headers/crt/float.h| 2 +-
mingw-w64-headers/crt/io.h | 2 +-
mingw-w64-headers/crt/memory.h | 2 +-
mingw-w64-headers/crt/sec_api/conio_s.h | 2 +-
mingw-w64-headers/crt/sec_api/stdio_s.h | 2 +-
ming
stdio/_vscprintf.c: In function ‘emu_vscprintf’:
stdio/_vscprintf.c:47:8: warning: ‘ret’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
if (ret < 0) {
^
---
mingw-w64-crt/stdio/_vscprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-
On Monday 19 September 2022 15:33:45 Martin Storsjö wrote:
> On Sat, 17 Sep 2022, Pali Rohár wrote:
>
> > ---
> > mingw-w64-crt/Makefile.am| 3 +++
> > mingw-w64-crt/stdio/ucrt__scprintf.c | 21 +
> > mingw-w64-c
On Monday 19 September 2022 16:50:33 Martin Storsjö wrote:
> On Mon, 19 Sep 2022, Pali Rohár wrote:
>
> > On Monday 19 September 2022 15:33:45 Martin Storsjö wrote:
> > > On Sat, 17 Sep 2022, Pali Rohár wrote:
> > >
> > > > ---
> > > > mingw
_HUGE global variable is available and exported from crtdll and msvcrt
libraries. So declare it explicitly via _CRTIMP as global variable and not
via __MINGW_IMP_SYMBOL pointer.
---
I'm really not sure what was the reason to define _HUGE via macro
__MINGW_IMP_SYMBOL poinster. So maybe there is a re
On Saturday 08 October 2022 20:07:56 LIU Hao wrote:
> 在 2022/10/8 19:10, Pali Rohár 写道:
> > _HUGE global variable is available and exported from crtdll and msvcrt
> > libraries. So declare it explicitly via _CRTIMP as global variable and not
> > via __MINGW_IMP_SYMBOL po
On Saturday 08 October 2022 23:57:06 LIU Hao wrote:
> 在 2022-10-08 21:15, Pali Rohár 写道:
> >
> > Is not _CRTIMP automatically marking variable with dllimport and
> > instruct compiler to convert variable name to __imp_name* pointer?
>
> Not always, at least. When bui
On Monday 10 October 2022 14:25:07 Martin Storsjö wrote:
> Historically, the _CRTIMP macro comes from how it is used in upstream
> msvcrt; you can link the CRT either statically or dynamically. If intending
> to link statically, _CRTIMP expands to nothing, while if intending to link
> dyanmically,
Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
But _MSVCRT_ is not defined neither by gcc nor mingw-w64 runtime.
So it is a dead code? Or is there any purpose for having those ifdefs?
Note that gcc defines macro __MSVCRT__ with double underscores.
_
On Tuesday 18 October 2022 12:01:34 LIU Hao wrote:
> 在 2022/10/13 00:50, Pali Rohár 写道:
> > Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
> > But _MSVCRT_ is not defined neither by gcc nor mingw-w64 runtime.
> > So it is a dead code? Or is the
Hello!
I tried to develop simple NT kernel driver and build it via GNU GCC, LD
and mingw-w64 ecosystem but due to issues with compiler and linker, it
is not possible to generate final .sys binary without adding workarounds
or postprocessing resulted PE .sys binary.
I'm sending this email to all p
On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > * GCC or LD (not sure who) sets memory alignment characteristics
> > (IMAGE_SCN_ALIGN_MASK) into the sections of PE executable binary.
> > These characterist
On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> > On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > > * GCC or LD (not sure who) sets memory alignment characteristics
> > > (IMAGE_SCN_ALIGN_MA
Original comment (from commit 7b77ca866ca99) was not moved correctly in commit
f9e8630d6f775.
---
mingw-w64-crt/crt/crtexe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 65303f818476..9093a2de29e7 100644
--- a
When application does not use WinMain() or wWinMain() entry point then
there is no need to compute arguments for these entry points.
So move WinMain/wWinMain specific code from crtexe.c file to crtexewin.c
file. This new crtexewin.c file compute arguments for WinMain/wWinMain
function and then dir
On Sunday 13 November 2022 14:04:58 LIU Hao wrote:
> 在 2022-11-12 21:36, Pali Rohár 写道:
> > When application does not use WinMain() or wWinMain() entry point then
> > there is no need to compute arguments for these entry points.
> >
> >
>
> This sounds great t
Usage of _TCHAR/_tmain/_tcslen simplify code as it avoids #ifdef.
Note that custom mingw-w64 wbytelen() function is replaced by
'sizeof(_TCHAR) * (_tcslen() + 1)' construction which expands to
2*(wcslen()+1) for unicode build.
---
mingw-w64-crt/crt/crtexe.c | 55 +++---
WPRFLAG is defined when _UNICODE is defined. So replace all usage of
WPRFLAG by _UNICODE and remove unused WPRFLAG macro.
---
mingw-w64-crt/crt/crtexe.c | 6 +++---
mingw-w64-crt/crt/dll_argv.c | 3 +--
mingw-w64-crt/crt/dllargv.c| 3 +--
mingw-w64-crt/crt/ucrtexe.c| 1 -
mingw-w64-c
---
mingw-w64-crt/crt/crt_handler.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/mingw-w64-crt/crt/crt_handler.c b/mingw-w64-crt/crt/crt_handler.c
index fe52cf4e2a0d..c49a2b3b573d 100644
--- a/mingw-w64-crt/crt/crt_handler.c
+++ b/mingw-w64-crt/crt/crt_handler.c
@@ -13,16 +13,6 @
GNU LD provides __ImageBase symbol since 2.19. This is standard windows
symbol and should be used instead of custom gnu _image_base__ symbol.
For compatibility with older GNU LD versions, define __ImageBase as weak
alias to _image_base__ symbol.
This allows to remove all #ifdef hacks for older GN
On Saturday 19 November 2022 17:12:12 LIU Hao wrote:
> 在 2022-11-18 23:40, Pali Rohár 写道:
> > GNU LD provides __ImageBase symbol since 2.19. This is standard windows
> > symbol and should be used instead of custom gnu _image_base__ symbol.
> >
> > For compatibility
On Saturday 19 November 2022 11:53:28 Pali Rohár wrote:
> On Saturday 19 November 2022 17:12:12 LIU Hao wrote:
> > 在 2022-11-18 23:40, Pali Rohár 写道:
> > > GNU LD provides __ImageBase symbol since 2.19. This is standard windows
> > > symbol and should be used instead
GNU LD provides __ImageBase symbol since 2.19. This is standard windows
symbol and should be used instead of custom gnu _image_base__ symbol.
Detect non-existence of __ImageBase symbol at ./configure time and for
compatibility with older GNU LD versions, define __ImageBase symbol as
alias to _imag
Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
allow specifying against which Windows C Runtime library should be
binary linked. On Windows there are more crt libraries and currently gcc
links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
(but can be changed,
On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> > On Monday 31 October 2022 10:55:59 Jan Beulich wrote:
> > > On 30.10.2022 02:06, Pali Rohár via Binutils wrote:
> > > > * GCC or LD (not s
On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > Date: Sun, 20 Nov 2022 13:53:48 +0100
> > From: Pali Rohár via Gcc
> >
> > Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> > allow specifying against which Windows C Runtime libra
On Sunday 20 November 2022 21:36:19 LIU Hao wrote:
> 在 2022-11-20 20:53, Pali Rohár 写道:
> > Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> > allow specifying against which Windows C Runtime library should be
> > binary linked. On Windows there are m
On Sunday 20 November 2022 17:23:15 Eli Zaretskii wrote:
> > Date: Sun, 20 Nov 2022 16:04:11 +0100
> > From: Pali Rohár
> > Cc: g...@gcc.gnu.org, mingw-w64-public@lists.sourceforge.net
> >
> > On Sunday 20 November 2022 16:45:55 Eli Zaretskii wrote:
> > >
On Sunday 20 November 2022 22:56:51 Martin Storsjö wrote:
> On Sun, 20 Nov 2022, LIU Hao wrote:
>
> > 在 2022-11-20 19:23, Pali Rohár 写道:
> > > GNU LD provides __ImageBase symbol since 2.19. This is standard windows
> > > symbol and should be used instead of c
On Sunday 20 November 2022 23:32:06 Martin Storsjö wrote:
> On Sun, 20 Nov 2022, Pali Rohár wrote:
> > > So at this point, do you think it's worth to add the complexity of
> > > manually
> > > expanding the linker test (like what was removed in
> > > 6
On Monday 21 November 2022 08:24:36 Jan Beulich wrote:
> On 20.11.2022 14:10, Pali Rohár wrote:
> > On Saturday 05 November 2022 02:26:52 Pali Rohár wrote:
> >> On Saturday 05 November 2022 01:57:49 Pali Rohár wrote:
> >>> On Monday 31 October 2022 10:55:59 Jan Beuli
On Monday 21 November 2022 13:21:53 LIU Hao wrote:
> 在 2022/11/20 23:06, Pali Rohár 写道:
> > Thank you for explaining more details. My simple patch takes this in
> > care and defines also __MSVCRT_VERSION__ to the correct value based on
> > -mcrtdll parameter.
>
>
Functions _atoi64, _strtoi64 and _strtoui64 are available since the first
release of msvcrt.dll as part of MS Visual C++ 4.2.
Define functions atoll, strtoll, strtoull, strtoimax and strtoumax as
aliases for msvcrt _atoi64, _strtoi64 and _strtoui64 functions directly in
def files. This would allow
Symbols _ctype and _mbctype are DATA, like in all other crt libraries.
Symbol _onexit is read-only function. And symbols _mkgmtime, _mkgmtime32
and _mkgmtime64 are not present in crtdll.dll at all. Calling gendef on
crtdll.dll from Win NT 3.50 and Win 7 confirms it.
---
mingw-w64-crt/lib32/crtdll.
On Sunday 20 November 2022 13:53:48 Pali Rohár wrote:
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libms
On Wednesday 21 September 2022 11:31:54 Martin Storsjö wrote:
> On Tue, 20 Sep 2022, Pali Rohár wrote:
>
> > > There are many, many different variants of inline behaviour - C89 inline,
> > > C99 inline, static inline, extern inline, gnu_inline, etc. There's a
> &
File msvcrt-common.def.in is included only in x86 32 and 64 bit msvcrt def
files and common msvcrt.def.in file. After moving longjmp, _daylight,
_timezone and _tzname out of the msvcrt-common.def.in file, this file would
contain only symbol aliases and not export symbols anymore. This makes
consist
moldname content is already included in all other msvcrt def files. This
allows applications to use moldname aliases defined in msvcrt-common.def.in
also when linking with other crt dll libraries.
---
mingw-w64-crt/Makefile.am | 3 ++-
mingw-w64-crt/lib32/{crtdll.def =>
Include file msvcrt-common.def.in contains moldname aliases and 4 export
symbols: longjmp, _daylight, _timezone, _tzname.
Move these 4 export symbols from msvcrt-common.def.in file into all files
which include msvcrt-common.def.in. So all msvcrt def files would contain
all exported symbols directl
It is unused since commit 99c69c2fe5d8 ("lib64/msvcrt.def: include moldname
contents") from April 2013.
---
mingw-w64-crt/lib64/moldname-msvcrt.def | 149
1 file changed, 149 deletions(-)
delete mode 100644 mingw-w64-crt/lib64/moldname-msvcrt.def
diff --git a/mingw-w64-c
These symbols are global read/write variables and therefore must be
declared with DATA keyword, even when they are just aliases to other
symbols. Otherwise GNU dlltool generates for each of those symbols also
function thunk code.
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 6 +++---
1 fil
On Thursday 20 October 2022 21:44:36 Pali Rohár wrote:
> On Tuesday 18 October 2022 12:01:34 LIU Hao wrote:
> > 在 2022/10/13 00:50, Pali Rohár 写道:
> > > Hello! More mingw-w64 header files contain '#ifdef _MSVCRT_' code.
> > > But _MSVCRT_ is not defined
Currently when linking target application with LTO builds of mingw-w64
libraries, it is needed to manually specify entry point of mingw-w64 crt
startup function via linker flag -Wl,-e,_mainCRTStartup (for console
executables) or -Wl,-e,_WinMainCRTStartup (for GUI executables) or
-Wl,-e,_DllMainCRTS
On Saturday 17 December 2022 23:01:10 LIU Hao wrote:
> 在 2022-12-17 22:22, Pali Rohár 写道:
> > Currently when linking target application with LTO builds of mingw-w64
> > libraries, it is needed to manually specify entry point of mingw-w64 crt
> > startup function v
mingw-w64-headers/crt/_mingw.h: In function ‘__fastfail’:
mingw-w64-headers/crt/_mingw.h:615:1: warning: ‘noreturn’ function does
return
}
^
---
mingw-w64-headers/crt/_mingw.h.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/crt/_mingw.h.in
b/mingw-w64-h
gdtoa/gethex.c: In function ‘__gethex_D2A’:
gdtoa/gethex.c:127:10: warning: this statement may fall through
[-Wimplicit-fallthrough=]
esign = 1;
~~^~~
gdtoa/gethex.c:129:5: note: here
case '+':
^~~~
gdtoa/dtoa.c: In function ‘__dtoa’:
gdtoa
stdio/mingw_pformat.c:2510:20: warning: this statement may fall through
[-Wimplicit-fallthrough=]
length = PFORMAT_LENGTH_LONG;
~~~^
stdio/mingw_pformat.c:2512:11: note: here
case 'c':
^~~~
stdio/mi
---
mingw-w64-tools/genstubdll/sample/ms.def | 1416 --
1 file changed, 1416 deletions(-)
delete mode 100644 mingw-w64-tools/genstubdll/sample/ms.def
diff --git a/mingw-w64-tools/genstubdll/sample/ms.def
b/mingw-w64-tools/genstubdll/sample/ms.def
deleted file mode 100644
ind
Function lldiv() is available since msvcr100.dll and function imaxdiv()
since msvcr120.dll. So for msvcr100.dll and msvcr110.dll define imaxdiv()
as alias to lldiv(). And for older msvcrt versions include mingw-w64
implementation from imaxdiv.c. Do not pack mingw-w64 implementation of
imaxdiv() int
1 - 100 of 566 matches
Mail list logo
