mingw-users Mailing List for MinGW - Minimalist GNU for Windows

On 2017-05-29 00:38, DAVENPORT, MARC wrote:
> Is there any chance of clock_gettime being implemented in MinGW? MinGW64 has it but I don't like MinGW64. Source code is public domain. See link below. It would also need at least clockid_t and clock_getcpuclockid.
> 
> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109

Hmm, their CLOCK_MONOTONIC wraps, and rather quickly too on some machines [1]; it's
nothing more than a dirty hack as it's not monotonic at all.

Unless I'm missing something non-obvious...

Cheers,
Peter

[1] I've seen machines wrap the performance counter within the hour, albeit many
    years ago, but the non-handling of the fundamental timer wrap problem persists.

Is there any chance of clock_gettime being implemented in MinGW? MinGW64
has it but I don't like MinGW64. Source code is public domain. See link
below. It would also need at least clockid_t and clock_getcpuclockid.

https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

Marc

> From: Papa <pa...@ar...>
> Date: Fri, 26 May 2017 19:41:20 -0400
> 
> With all due respect, I'd like to start by changing the semantics of the conversation; for that I need to clear
> something up. I did not write any 'makefile', I just downloaded wxWidgets and proceeded to compile it
> entering, at the command prompt, the values shown in the OP. Thus, I think your statement should be 'The
> Makefile sets SHELL to an empty value.", or more accurately, 'wxWidgets's Makefile sets SHELL to an empty
> value.'
> 
> Having stated the above, how can I solve this problem or should I say, how should wxWidgets fix this
> problem?

You need to look into the Makefile and find its setting of the SHELL
variable.

The immediate problem is that the Makefile caused the Make utility to
invoke the following command:

  C:/ProgramData/Oracle/Java/javapath/ -c "if not exist ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll"

to which Windows rightfully objected, because
C:/ProgramData/Oracle/Java/javapath/ is a directory and cannot be
invoked as a program.  Judging by the command, the intent was to
invoke the cmd.exe Windows shell here, and do it with the /c switch,
not -c switch.  So looking into the Makefile for related commands and
variables will most probably find the culprit.

I cannot say anything more specific, sorry, because I don't have the
Makefile and the source tree you are using.  If the above doesn't help
you figure out the problem, maybe asking on the wxWidgets forum will
help.

Thanks Eli for your reply.

With all due respect, I'd like to start by changing the semantics of the 
conversation; for that I need to clear something up. I did not write any 
'makefile', I just downloaded wxWidgets and proceeded  to compile it 
entering, at the command prompt, the values shown in the OP. Thus, I 
think your statement should be 'The Makefile sets SHELL to an empty 
value.", or more accurately, 'wxWidgets's Makefile sets SHELL to an 
empty value.'

Having stated the above, how can I solve this problem or should I say, 
how should wxWidgets fix this problem?


Again, many thanks for taking the time.


On 2017-05-26 1:38 PM, Eli Zaretskii wrote:
>> From: Papa <pa...@ar...>
>> Date: Fri, 26 May 2017 11:53:37 -0400
>>
>> I am trying to compile using this:
>> mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11" BUILD=debug UNICODE=1 SHARED=1
>>
>> but I get this error:
>> process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ -c "if not exist gcc_mswuddll
>> mkdir gcc_mswuddll", ...) failed.
>> make (e=5): Access is denied.
>>
>> mingw32-make: [gcc_mswuddll] Error 5 (ignored)
>> process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ -c "if not exist ..\..\lib\gcc_dll
>> mkdir ..\..\lib\gcc_dll", ...) failed.
>> make (e=5): Access is denied.
> Your Makefile sets SHELL to an empty value.

> From: Papa <pa...@ar...>
> Date: Fri, 26 May 2017 11:53:37 -0400
> 
> I am trying to compile using this:
> mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11" BUILD=debug UNICODE=1 SHARED=1
> 
> but I get this error:
> process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ -c "if not exist gcc_mswuddll
> mkdir gcc_mswuddll", ...) failed.
> make (e=5): Access is denied.
> 
> mingw32-make: [gcc_mswuddll] Error 5 (ignored)
> process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ -c "if not exist ..\..\lib\gcc_dll
> mkdir ..\..\lib\gcc_dll", ...) failed.
> make (e=5): Access is denied.

Your Makefile sets SHELL to an empty value.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/05/17 15:58, Earnie wrote:
> On 5/26/2017 10:26 AM, Keith Marshall wrote:
>> Notwithstanding the above, and given that we want to keep msvcrt-xref 
>> fully comprehensive, while still generating libmsvcrt.a from the same 
>> symbol reference source, there are some symbols explicitly filtered 
>> out of the import libraries; we could extend the list of such symbols, 
>> if the user population deems it desirable.  I will be guided by the 
>> wishes of any significant number of users here; if you think we should 
>> exclude Microsoft's *_s() nonsense, please say so; if you think we 
>> should support it, please submit patches via the feature request 
>> tracker.
> 
> My vote is to keep them.

I don't have a problem with doing so; however...

> Some poor system might just be using these regardless.

Any such system must (currently) do so, without any dependence on 
prototypes in our headers, for such prototypes don't yet exist.

> I also think if someone wants to provide proper clean room patches
> with appropriate guards for these we shouldn't be glib about adding
> them.

Sure, provided the guards are appropriate, and the poster can cite 
direct MSDN references for content, or can demonstrate a clean room 
technique to fill in any undocumented content.  Hence my request to 
have such patches submitted via our tracker, where we can review, 
discuss, and appropriately vet them.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZKFYyAAoJEMCtNsY0flo/EC8P/A3vg6ghiubCtOU/II2EsgR5
LhMq/kyy2+CxjojaKCy+6k2EGX6KXw7iHujRhBgkAgnAndLfNppxwZVXJfkIj5Uz
sWjo81GA+4D4vgMY6xygI9F5FQHlwWHozQ6g1PcbEDeXPFdJmurAUZWrO5UuqW5S
UCEVAFGavs6TmdkOoJmIogzCy39gRzQe+LQRemo619z07Q9VidYIz+xsjGnkvhAm
fcVn5ohjYU6b9isXBNxawR0jaZsMVTAKIcIHH5+4oLTqFj4yhqtHr+Ivqd9nBK5w
5lEcbTrtrfVEMFgJrCW15tdK266q+rgehLCiQJXOgIR1bg9cS2LSV5kVmAtvZyJn
XDz88wbv7qmSFVl0XHEgggLv2EWHpAWjz6UlAuF2EZUwCgLILAottcjKXwaF+xVs
c9jl+vKelCec+1IyQ8f9fRkNxxUn4d65V+BuP1BSLCynMZ2vDjEvTqDBJ8fU2pPe
kBOfLxQFAIsfBy6dxYJHD448iAxYB2XgRxIBm9YW/XjHDivvgchmUd9PpTTeklte
LILshXkXRZSOw/N18SmyFC0zb3FbYd/Lhr7arH9csLzmWDCVMHiAyVwKjy15qnFl
GtTVXTxt5m5WIrGmXNoBQHi/UOLR1+dra4dih8tZYQR73GpEPzR5UIbuaFnZh3ly
PU5qasGbxK8RhIhXn7sV
=V9HQ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/05/17 16:53, Papa wrote:
> gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

You are asking on the wrong mailing list.  This compiler is distributed 
by a different project; we don't support it here.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZKFE1AAoJEMCtNsY0flo/hvMP/iLAt2QEbhkWBYYJUsFY7o8d
TLDncFXkjhmBegkG+ee8sG3RA69VpE1SndFXz0Zy5Z5dKCWTjhVydiJ38jvE3h6f
lVyUrccaOxzpMHnotfu8LiZQ3p4A1vzvYXWg2s783R9OMW/O3SCf02xKMxXbtc5T
IFLdfpk7M7z+jpVkIUQVu8eMjUic3aq0eWVRIxdDXg4H9bOrIAswDGAyKZwgRyxy
xBhp2wkYGCwI90BHXtERfpsKEjccPw7x/9sKADnP7YPhxydV/JA1wQ++00Z+5x+p
y8nDxMNtUUEvNN2JwJG7bGTmD1Qh1j6/nX0SZyv+7dTFbqFzy1cO2h1wDEbmgS9F
YY0STfst/B1ALsYpHiBh1Etlg3ovDdcUNkH8RnFbC8yPhofzWMZRbljOKXMUJRs2
YmFPrilxx78z+omaY8I2DRksblumhyeXUm/NU0btOPrD6WVkslVltiFIyjrsnkkX
hPxQRjmQgC4onh0/SfMwXUinC1KlIM2nexOJ2mQg9iNzAxHwHpX4bEmGdzG/ZbpL
jJiAPEva2tSPkQUakGtmOUx6CJ8A2l/TtlVIZsdo/rg5iBqR4SNuxTihK/pAhctA
NBo3IC0H9m8V9F+gsWoXc5FiI7m9lBlOf5fi4jxb20bVodAQrFlS2t6Ce8bRUdaH
ibkX5OsIEzF76RQPJR7X
=F8hZ
-----END PGP SIGNATURE-----

OS: Win8.1

GCC:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Program\ 
Files/mingw-w64/x86_64-7.1.0-posix-seh-rt_v5-rev0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --prefix=/mingw64 
--with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64 
--enable-shared --enable-static --disable-multilib 
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes 
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto 
--enable-graphite --enable-checking=release 
--enable-fully-dynamic-string --enable-version-specific-runtime-libs 
--enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch 
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath 
--disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona 
--with-tune=core2 --with-libiconv --with-system-zlib 
--with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static 
--with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static 
--with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static 
--with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static 
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' 
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 
-pipe -fno-ident 
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include 
-I/c/mingw710/prerequisites/x86_64-zlib-static/include 
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' 
CXXFLAGS='-O2 -pipe -fno-ident 
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include 
-I/c/mingw710/prerequisites/x86_64-zlib-static/include 
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' 
CPPFLAGS=' 
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include 
-I/c/mingw710/prerequisites/x86_64-zlib-static/include 
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' 
LDFLAGS='-pipe -fno-ident 
-L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib 
-L/c/mingw710/prerequisites/x86_64-zlib-static/lib 
-L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

WXWIDGET = Latest


I am trying to compile using this:
mingw32-make -f makefile.gcc CXXFLAGS="-std=gnu++11" BUILD=debug 
UNICODE=1 SHARED=1

but I get this error:
process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ 
-c "if not exist gcc_mswuddll mkdir gcc_mswuddll", ...) failed.
make (e=5): Access is denied.

mingw32-make: [gcc_mswuddll] Error 5 (ignored)
process_begin: CreateProcess(NULL, C:/ProgramData/Oracle/Java/javapath/ 
-c "if not exist ..\..\lib\gcc_dll mkdir ..\..\lib\gcc_dll", ...) failed.
make (e=5): Access is denied.

mingw32-make: *** [..\..\lib\gcc_dll] Error 5


Does anyone know why I get this error?

On 5/26/2017 10:26 AM, Keith Marshall wrote:
> 
> Notwithstanding the above, and given that we want to keep msvcrt-xref 
> fully comprehensive, while still generating libmsvcrt.a from the same 
> symbol reference source, there are some symbols explicitly filtered 
> out of the import libraries; we could extend the list of such symbols, 
> if the user population deems it desirable.  I will be guided by the 
> wishes of any significant number of users here; if you think we should 
> exclude Microsoft's *_s() nonsense, please say so; if you think we 
> should support it, please submit patches via the feature request 
> tracker.
> 

My vote is to keep them.  Some poor system might just be using these
regardless.  I also think if someone wants to provide proper clean room
patches with appropriate guards for these we shouldn't be glib about
adding them.

-- 
Earnie

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 23:40, John Brown wrote:
> On Thursday, May 25, 2017 1:45 PM, Keith Marshall wrote:
>> On 25/05/17 16:44, John Brown wrote:
>> I see that functions such as printf_s described at 
>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
>> are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
>> MinGW header file (at least not in /mingw/include/*.h). Is there a 
>> particular reason for that?
>>
>> Perhaps because no one has been sufficiently taken in by
>> Microsoft's lies, (in what way do such functions provide added
>> security?  What user authentication mechanisms do they provide?),
>> to be bothered to submit patches to add them.
> 
> The section entitled "Additional Security Features" at the link that I
> provided explains what is more secure about these functions. It seems
> to be mainly about avoiding buffer overruns as opposed to user
> authentication.

And Google will turn up any number of references, which explain why 
they are inappropriately described as security enhancing, and indeed 
if anything may actually be prejudicial to security; Microsoft have 
chosen to promote them thus, to engender and exploit FUD.

>> Realistically, the only security related aspect of the majority of
>> such functions is that they secure an increased level of Microsoft
>> lock-in; I am not enthusiastic about encouraging their use.
> 
> If you feel so strongly about it, then surely you should exclude these
> functions from the import libraries?  I only asked because they were
> in the libraries but not in the header files.

That's not an unreasonable suggestion.  However, right now the import 
libraries reflect what our pexports tool says is provided by the union 
of all currently support MSVCRT.DLL versions, as documented here:
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/msvcrt-xref/

Obviously, that union will necessarily be more comprehensive than the 
list of exports from any one version of MSVCRT.DLL, particularly in the 
case of the versions from older versions of Windows itself.  To support 
linking with any MSVCRT.DLL version, the import library must cover all 
eventualities -- there is no way to make a single implib selective for 
multiple similarly named DLLs; the only selectivity possible is that 
which is achievable by selective exposure of prototypes in headers.

Notwithstanding the above, and given that we want to keep msvcrt-xref 
fully comprehensive, while still generating libmsvcrt.a from the same 
symbol reference source, there are some symbols explicitly filtered 
out of the import libraries; we could extend the list of such symbols, 
if the user population deems it desirable.  I will be guided by the 
wishes of any significant number of users here; if you think we should 
exclude Microsoft's *_s() nonsense, please say so; if you think we 
should support it, please submit patches via the feature request 
tracker.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZKDr9AAoJEMCtNsY0flo/ENgQALk4qN8X6U1GTcygNDZYScbF
4P++2Qkis8uDuzeHSxKWV3gG5s1YhP9j3OS6GzHHGmy9iIEXX+UoStE94521e+aI
v7sVD3F1tKPP9/Q5rUK6Bk6LDhRuzX5Lzs5JJffMf7mh7pFxaBMgD9cNE8lptNYH
n8wW1fC2KxsgN8RRr/awlfzuKFgTBwVPTf1D/P/XrY0OcQsKGuPRf46DLXIeZQv2
m9SsXoThoiDjyze1D1W3ih9X9daJ6yywu5l69vJgOy1GWUvxTEUfuJGurWWlPoVz
KPRr9BUbACC6SAsSuEKDPtWjna4diGd314dsX8mBchbhgCCl0gpvr7iJY4CxvTnD
VE9MSoIgi34Crtdl+e8fZltJVA/+Yie23KmqQ7c1NbqC1FSJtWkXVP10AleWN00L
BEdVxtKFnvslRnXWq/87au62nBf7hrhw0lIu8FNroM62Ws87GMLsIrYhUbbpXUDL
3l/u5BZ10zf5DsIc4ZJkoseGfzNYNPfRjF0uOgZUSKObQzX9hXkTC4lTza6Sxj+X
dshiekHnbXcml0fwiz4Rg20mpWcZKew2HrX3bKiG+GjNfxjnnplFzMRZjiP5a1J1
5jCN5J25fdxreaRSpgySNs49PSY+F2oAadDWtganqaj0uJPIFdL4qVg9yVE5rQ4K
RaF/tGmxLON2kNBruvZH
=gUPd
-----END PGP SIGNATURE-----

On Thursday, May 25, 2017 1:45 PM, Keith Marshall wrote:
> On 25/05/17 16:44, John Brown wrote:
> I see that functions such as printf_s described at
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
> are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
> MinGW header file (at least not in /mingw/include/*.h). Is there a
> particular reason for that?
>
> Perhaps because no one has been sufficiently taken in by Microsoft's
> lies, (in what way do such functions provide added security?  What user
> authentication mechanisms do they provide?), to be bothered to submit
> patches to add them.

The section entitled "Additional Security Features" at the link that I
provided explains what is more secure about these functions. It seems
to be mainly about avoiding buffer overruns as opposed to user
authentication.

> Realistically, the only security related aspect of the majority of such
> functions is that they secure an increased level of Microsoft lock-in; I
> am not enthusiastic about encouraging their use.

If you feel so strongly about it, then surely you should exclude these
functions from the import libraries? I only asked because they were
in the libraries but not in the header files.

Regards,
John Brown.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 17:29, Emanuel Falkenauer wrote:
> Since they are MS functions, I would guess they are declared in one
> of the MS headers, which would make logical NOT to declare them again
> in MinGW headers.

Why would you think that?  MSDN is explicit about which headers should 
define them, and they are all CRT functions, *not* WinAPI functions.

> #include <windows.h>
> 
> should give you the declarations.

No, it should not!  In any case, <windows.h> is just as much a MinGW 
header, (from the w32api package), as any of the CRT headers from the 
mingwrt package.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJz+ZAAoJEMCtNsY0flo/UykP/1ROX1NUzTZNTciz0DvNctAa
HMOdxEhuCBc1TqXR9aP9pgfQc0h/ZD/YUfIYlpYpkSB/HJ3Shge4PEjq4Lhedjkl
wvT7bIkiPXU+Ehq8gQt3ISQpuTem17UsWQrhenwSoI6Kqk+Do+u4VLW4P0YqHngT
YFOBuhYjIBsHV4YQ9Lk9vfO9S71kZmrzd+43MnYDWitvsyxa3yM2EhTUa5tNPrCt
nL2gaXTvir/T+aVIO8oUdtioX8ZRufr9903HmZup0uG74BI+9No89FqXGFo3GtiU
s3uV5yNyjCJjFLtulMO5DETa5Cp5ilm70bVp20kWLQGHXMhwVsUWwxUmFQlu5efc
tkxAK8gZWdoEHPKnLcCdHWvJpZ3JtSgp2TUnRKOaJmY36OahYZCnjUZ4J0q1Z9E0
nr8/fXoH08aGWeGaNNapkWHVLcXTVA96Uq0LfxPP9fZROqBlpMEWkPG0hatSc/1f
qH1nb4WMuJ2pms9+SnLCuOnRmdgm4ubaQU4rGyDv2eQkU6r0Pa9NVLUO2W8kcc1Q
/aTH/qEThI2x9O0z+KNAsgEySy8nb7fGnOUs5IWmWckhegX8WVnPoXRpOpLw7hNQ
mBs+k4yJuDxHZ/Tf5HqkPdiVkVXinqWB9wRQwCV2XhTpD1Xb9rdUklRXdLl7/OPq
4b6Ar77cZvxQUw4mtGV7
=RyHa
-----END PGP SIGNATURE-----

On 5/25/2017 1:34 PM, Keith Marshall wrote:
> On 25/05/17 16:35, John Brown wrote:
>> Unfortunately [these] spaces (before a LF character) are not visible
>> in vim.  Consider a file <LF><SPACE><LF>.  Vim will tell you that it
>> has 2 lines and 3 characters when you open it.  If you move the cursor
>> to the start of the 2nd line (where the space is), vim will not let
>> you move the cursor to the right,
> 
> Yes, it will, provided you switch it into insert mode; however...
> 
>> leading you (or maybe just me) to believe that nothing is there.
> 
> ...I do agree that they can be difficult to spot.  Mercurial's "diff"
> function, (with colour view enabled), makes them VERY visible; (maybe
> git offers some similar capability ... since I don't use it, I don't
> know).  It may be useful, in vim, to invoke:
> 
>   :%s,[<SPACE><TAB>]*$,,
> 

:set list

https://stackoverflow.com/questions/1675688/make-vim-show-all-white-spaces-as-a-character

> (where <SPACE> and <TAB> represent the named characters), before you
> ultimately save any file.
> 
>> The space *is* there, above the cursor.  WordPad, Notepad++, emacs
>> and no doubt most other editors let you move to the right in that
>> situation.
> 
> AFAIK, each of those editors is non-modal in behaviour; when you move
> the cursor to the right, you are already in the equivalent of vim's
> insert mode.
> 

-- 
Earnie

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:44, John Brown wrote:
> I see that functions such as printf_s described at
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
> are present in /mingw/lib/libmsvcr80.a but I cannot find them in any 
> MinGW header file (at least not in /mingw/include/*.h). Is there a
> particular reason for that?

Perhaps because no one has been sufficiently taken in by Microsoft's 
lies, (in what way do such functions provide added security?  What user 
authentication mechanisms do they provide?), to be bothered to submit 
patches to add them.

Realistically, the only security related aspect of the majority of such 
functions is that they secure an increased level of Microsoft lock-in; I 
am not enthusiastic about encouraging their use.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJxgnAAoJEMCtNsY0flo/DAAP/0Kng+xz2JJAaHkDaHZDhAKG
ohDWm/Mcr2Qw8KXVnCm7JOuFUPg82ck2TlD0QbJQkpgbdwbg9DTJVcyLxaap9eVs
Bfjx3vZMXUGdIBbJNNvX3UykjjVomw+4q4RkqNJoBtkbdrwM/L+9WMwcc5mGYFIm
PgKtwCKtyLewXrxgQJqR3DeBGu7AEgkrPkYrKOz4RSmfBmKsqwGr/FrpL0vLgHLm
LXkThkeWnmR43+FhLdS7GWa6QU6vbinnHRFfh1jwBBom+oQzfkoLEbMOt5jmtmMy
TOg8u+q187/B9Jg37cgg6v3rAoR7pg4QYDwBufItQXqjnr0WatmzyuHOMS4FJ6Q6
4AW+0puZKZZd8J4XDXkCjF1o6Qd1qwnN31auXCJd1+nkBgLw8S0pBkb1scsvn/hW
oayCaCmk6uRtF0ZWmvshFQRJyufi/Ood3SL3rhIN3HjiQw1v0VPOcy9r3c/U7Jje
5Q960v+IuccBcdFUxcNgru4O8hm71qpXItKYciJWhB/gX7BTxXoK5rHhrSO7jnHI
gMJ9W56eG+htd2SVO2tzvHCGvbzbY2gbvGQWkHvf7p7AXaaw5PtZ43zbvyepzdou
GLuFnO28o+9cOME1OvXmHHWeiDbsLjCw6yKM8qsojiG68kCY0tSAvG+quOvMnAyo
pUfrKQAysBhoN6y6h5pd
=wrSZ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:35, John Brown wrote:
> Unfortunately [these] spaces (before a LF character) are not visible
> in vim.  Consider a file <LF><SPACE><LF>.  Vim will tell you that it
> has 2 lines and 3 characters when you open it.  If you move the cursor
> to the start of the 2nd line (where the space is), vim will not let
> you move the cursor to the right,

Yes, it will, provided you switch it into insert mode; however...

> leading you (or maybe just me) to believe that nothing is there.

...I do agree that they can be difficult to spot.  Mercurial's "diff" 
function, (with colour view enabled), makes them VERY visible; (maybe 
git offers some similar capability ... since I don't use it, I don't 
know).  It may be useful, in vim, to invoke:

  :%s,[<SPACE><TAB>]*$,,

(where <SPACE> and <TAB> represent the named characters), before you 
ultimately save any file.

> The space *is* there, above the cursor.  WordPad, Notepad++, emacs
> and no doubt most other editors let you move to the right in that
> situation.

AFAIK, each of those editors is non-modal in behaviour; when you move 
the cursor to the right, you are already in the equivalent of vim's 
insert mode.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJxWQAAoJEMCtNsY0flo/9/0P/RSjTibNIAWp8cOX6BSB2K5L
/CgF6Q5hKWnx3Y5d5MZjL9rciaxshiAF4mbT+1XRBBWLrdgROX+QegsiOr0QqwI9
v5X7aQn1PCfV3a603cgQX78comSDDDoX09Ih6XuWzoruJZG8M8FepLKCnTeUh/66
i94UqWTBmAA+yF1Od1xJXO4L+oBz9Qcm8Fmff/PlJ+iJhOiKeM+hJbngi9CpVME3
/tX6nKGWDGD8ZBe5dsVqi9sO/OZHPMVwGvi4WhIQX0QweSFGzj8B/0os2rRSuQRj
PNmix11HWvAlxaJ69rkNogEE5xe9j7Cd3VyB0f2tuZV6PNGOFK5uJsQ+w7GPtwPT
BaOFXqIVDtoNIyzyEUJP88UYspBx/PzmHtrkwd0vtvgIpiq4N0+x1RTwS7Q0wnwA
hAtDUhykjbjWeHSf2+QKUcU5OU4rO0hYBYkym4WPlZ/fRtkxn55I4M4gxij2Y4l3
K4i5bAuYNzexCSp4Jmfq21MMXKK4DnpWejX8sz5TBt+j8yFa/xeuAQR/YyR6OPGd
/QPCy3zklpLU/meJN26R/IGXGFQ+xG1ogYINEBNzIa91eEq88PA1AS9qbENLuORR
qi5yZmI9fH/s1q/djSOzpR8vzB88YXmV/3Kn8qbn66+9ysIQX4Kn83IjVqneq1Sr
0jl/5II26KT0BNdOlkds
=+jSL
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:35, John Brown wrote:
> Using a custom specs file may be overkill for one function, but once
> I have set it up, it is easier than modifying the source (which I
> didn't write), especially if I need more than one function that is
> not in MSVCRT.DLL.

True, but you then sacrifice freedom; by the strict letter of the EULA,
AIUI, you cannot redistribute MSVCR80.DLL, (unless you have a paid-for VS 
licence), so if you distribute your application, users may have to go 
look for it, as a separate download from Microsoft.

> By the way, my Windows 10 Version 1607 MSVCRT.DLL (7.0.14393.0) also
> does not have _ftelli64.

Thanks for that.  Presumably it does have _telli64 and _lseeki64, (which 
I believe have been present since Win95/WinNT3), so we could easily add 
an inline _ftelli64 emulation in <io.h>, so it could appear that it is 
available, without requiring non-free MSVCR80.DLL.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJw7sAAoJEMCtNsY0flo/GnwP/jkDD8eMQuK4f8Ut42HPj6Bj
4hsQHD0IShrS8i3LQ73wjc8RiAFOwx47M6X9QQb93SziGrwN2GEbQ6M7TeJHNlfh
I5BNepdd0jncBLiNhSbcy9kXH4Ty5xV4/lUOIpoKHPKYhsRlNTMiAStN837jTK9D
CwnMsA4niVce2bAVad3BvR9uuzOWu5bFzGF0zaXaCzJaeEuAD8pVxlN0Gu2Bhgso
lK5JMhcIO5CsrLXBsn1gMcYXmhx1toA0f66G2v9UMWRms4nv9L+OHbtVI2hLcwU7
1u/CCOK/e6vm2buf/rxPEl0VMStiKtlWHN15XLmNVAFoxrux+x7uVp06zVQxaM9P
lmZfuA1E7lAEobP//0HuAGIUrEk6WV+RmlPp2izhCKs/0s//xefCw1WVLkqJKn+x
hEDScZBd65iDcmebyu3AAoPB0Ex7wKfR84Um65T1pRilxj5YLt4lEDfAZX2Uonqc
sU+k9RFwYFtQ0PgT2XAAFHoiTQAnGGjWqk8A5vHVPZBucGJLYSTEz4lO0oiXZpht
+08ItGYrHmFU5jBltUV+kmfFKvCKMvejBrvgcSwWnKGMkEhX/108eWo9D7tTeVeN
hYim1osUuYUVHyjm1+HM07WG3TALTDBBuhjFPxWnBDxXEEDEVW7C32rsoLiAFpwK
CFEOiuihWpSy5KeuIdcW
=uJ3j
-----END PGP SIGNATURE-----

Hi John,

Since they are MS functions, I would guess they are declared in one of 
the MS headers, which would make logical NOT to declare them again in 
MinGW headers.

#include <windows.h>

should give you the declarations.

Best,

Emanuel

On 25-May-17 17:44, John Brown wrote:
> Hello All,
>
> I see that functions such as printf_s described at
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
> are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
> MinGW header file (at least not in /mingw/include/*.h). Is there a
> particular reason for that?
>
> Regards,
> John Brown.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>

Hello All, 

I see that functions such as printf_s described at
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
are present in /mingw/lib/libmsvcr80.a but I cannot find them in any 
MinGW header file (at least not in /mingw/include/*.h). Is there a
particular reason for that?

Regards,
John Brown.

On Thursday, May 25, 2017 7:43 AM, Keith Marshall wrote:

> I can't see anything obvious, but your hello.c compiles and links fine,
> for me, both with and without -specs=msvcr80, and with both my GCC-5.3.0
> mingw32-gcc cross-compiler, and the GCC-6.3.0 variant, with which I am
> currently experimenting.  Clutching at straws: check that your blank
> lines are REALLY blank ... no stray white space, and no rogue CR from
> CRLF line endings, (which I believe should be LF, as $DEITY mandates).
>
> Did you try adding -v to the GCC command line, to verify that your specs
> file modifications are being interpreted correctly?

$ gcc -v -specs=msvcr80 -o hello 2>&1  /tmp/hello.c |  grep specs
Reading specs from c:/mingw/bin/../lib/gcc/mingw32/5.3.0/specs
Reading specs from c:/mingw/bin/../lib/gcc/mingw32/5.3.0/msvcr80

The problem was a space (0x20)  at byte offsets 0x11 and 0x57.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2A 6D 73 76 63 72 74 3A 0A 6D 73 76 63 72 38 30  *msvcrt:.msvcr80
00000010  0A 20 0A 2A 6D 73 76 63 72 74 5F 76 65 72 73 69  . .*msvcrt_versi
00000020  6F 6E 3A 0A 2D 44 5F 5F 4D 53 56 43 52 54 5F 56  on:.-D__MSVCRT_V
00000030  45 52 53 49 4F 4E 5F 5F 3D 30 78 30 38 30 30 0A  ERSION__=0x0800.
00000040  0A 2A 6D 6F 6C 64 6E 61 6D 65 3A 0A 6D 6F 6C 64  .*moldname:.mold
00000050  6E 61 6D 65 38 30 0A 20 0A                       name80. .

Unfortunately these spaces (before a LF character) are not visible in
vim. Consider a file <LF><SPACE><LF>. Vim will tell you that it has 2 lines and
3 characters when you open it. If you move the cursor to the start of the 2nd
line (where the space is), vim will not let you move the cursor to the right,
leading you (or maybe just me) to believe that nothing is there. The space *is*
there, above the cursor. WordPad, Notepad++, emacs and no doubt most other
editors let you move to the right in that situation.

Using a custom specs file may be overkill for one function, but once I have set
it up, it is easier than modifying the source (which I didn't write), especially
if I need more than one function that is not in MSVCRT.DLL. By the way, my
Windows 10 Version 1607 MSVCRT.DLL (7.0.14393.0) also does not have
 _ftelli64.

Thanks.

Regards,
John Brown.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/17 11:10, John Brown wrote:
> I tried to follow the instructions at 
> http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
> to let me link to msvcr80 ...
> 
> /mingw/lib/gcc/mingw32/5.3.0/msvcr80 looks like this:
> *msvcrt:
> msvcr80
> [SINGLE BLANK LINE] 
> *msvcrt_version:
> -D__MSVCRT_VERSION__=0x0800
> [SINGLE BLANK LINE] 
> *moldname:
> moldname80
> [SINGLE BLANK LINE]
> 
> At the top of /mingw/lib/gcc/mingw32/5.3.0/specs (created by
> gcc -dumpspecs) I inserted the following lines:
> *msvcrt:
> msvcrt
> [SINGLE BLANK LINE]
> *msvcrt_version:
> [1st BLANK LINE]
> [2nd BLANK LINE]
> *moldname:
> moldname
> [SINGLE BLANK LINE]
> *asm:
> [1st BLANK LINE]
> [2nd BLANK LINE]
> 
> and changed the *cpp and *libgcc definitions as follows:
> *cpp:
> %(msvcrt_version) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: } 
> 
> *libgcc:
> %{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc -lgcc_eh}  %{!static:    %{!static-libgcc:      %{!shared:        %{!shared-libgcc:-lgcc -lgcc_eh}        %{shared-libgcc:-lgcc_s -lgcc}       }      %{shared:-lgcc_s -lgcc}     }   }     -l%(moldname) -lmingwex -l%(msvcrt)
> 
> I am running the latest  MinGW (gcc 5.3.0). Am I doing something wrong?

I can't see anything obvious, but your hello.c compiles and links fine, 
for me, both with and without -specs=msvcr80, and with both my GCC-5.3.0 
mingw32-gcc cross-compiler, and the GCC-6.3.0 variant, with which I am 
currently experimenting.  Clutching at straws: check that your blank 
lines are REALLY blank ... no stray white space, and no rogue CR from 
CRLF line endings, (which I believe should be LF, as $DEITY mandates).

Did you try adding -v to the GCC command line, to verify that your specs 
file modifications are being interpreted correctly?

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJsNxAAoJEMCtNsY0flo/KesP/iP6qdXYQgV1koQhMGNMn+lA
oW35tnWqGwutVtlxFODP/zEATFhnNbJJ9dt0evMk1R8xoihWOFozsKY7AfYO5pKY
06Tbuqb/znyIeRkEA8Q0EK3VC300nq6STyVPLEwIPAIRf3GD3Wt8PEMW9n2QfAEC
ylsq4fcZT9SgDdewHuyt6OCmUyV2A8HsHXz82EApr3viIww3G2STWZzYC84ryYuq
ec0Jngir8kuIdaERtLcPIqBCm/nYB3bgo6sdmW3XEZr8KAPyA4w0TZ8rhWkutShI
2imIOg4yz7i+QEgR4mhIeJryKX+/oIPxWVvtYcb2ZNHFmS612Q22FOKulmG3CUs3
jpqT5t3S5qwRB1/7Xkyk7TUK2Z9xHRuDYUqSWEBXiBPgwhm3APsfzg06BaCtw9+U
68C0TN3dS9RcGlK8w2JsvHxOyB/kdtnKRIxo1qb8k6gwvmEVqLer3NrqdW+09cYo
Ubouj8iVV7RTj9HMqLKp8CQ0HH/ML5k7HCVIsrnNMeRtiqqQP01aQbVVPQ3u/z7b
DNn2bYs63V7c4sibVwgxy4KVnR+ox/A5cFKFVgvbHluDW6jlOpknBeY5kVzjJ1RY
JjK0oKE6WGgcm1JI4KmfB2HNkkP5nQ0S/mnG3uzLGSPyim7wEC+6FAgv3/O+TsOQ
ti1La7/CWYI5IhJ/0m1u
=2bQd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/17 19:15, Eli Zaretskii wrote:
> From: Keith Marshall, Mon, 22 May 2017 19:30:19 +0100
>> Please try the attached (modified) stdio.h; it reverts the 
>> unsatisfactory function inlining, (so reverting to mingwrt-3.22 
>> behaviour), but also lays the groundwork for more appropriate
>> -Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).
> 
> Tried it.  It solves the problem;

Thanks for this confirmation.

> hope to see it soon in some mingwrt release near me.

I pushed it to:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/40982dff81a3c1dc0572cf2cd0a23156661ae98d/

so it will be in the next published release.

> Thanks!

You're welcome.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJgjiAAoJEMCtNsY0flo/XFkQALkhkBgRHHNhTqo4jqqZBOIj
sIqyf3AGfNNuFRm1+k62p8Lo9l7PI33sCqeQNB5qQxiQ69l/hRzMefSTpr+okCUi
6AOQEhVmv0mEa5v2IbfBl4MNWgq04AAQvjL7ACbgFrxKbY38UQnN3StqLz04tF8Y
X5YQdWGkQo/xuZTdppQ96HYpxK/urWUog/hEc4yvbtJy2MF6xjYEdfaDzOmflvJV
SYWScxUgBQcb5+zV6tZp/Lia0PUOnuqtWPjplEKve3eY16vCUJtW2DtNYS54OgEw
3ykxUoZ/waWNXZfT5o2Reuil7twMnlzW2w/o4jca51/0pBalCHm1HlQiHgJyu6cH
M02AE+K6aHfJ4GYEymRqi8d0u3HknYJwxMj3qvYPyIzJ8f8VV+6XfK5tYW4gcMHx
qcMxX4lLHk7fvUjwWUEvUm8Iq4TKEU9S71CxKnpimcPAoAD7HpvnmL4P6LuPG/sd
erMKGd4ul/9BQ3jSbRsfQ7vCuDah3lGTE2Kn3JBvNluVFb/ezQT7lttBYhKZbfwH
yBvrwt1bKZzCS3ornLhLoM66ddU/q7/hYSxMlH6Wto+tnIAmiGJdF3vq/bOJvmWT
C2VS4eS/lXWSaoUHEOw+zxf6hCyv0fSggtpnyhET+39PbaBUepj0VswOxiFeiOOn
oOUqFxVxaDOj5ORw7hYx
=St0e
-----END PGP SIGNATURE-----

> From: Keith Marshall <kei...@us...>
> Date: Mon, 22 May 2017 19:30:19 +0100
> 
> > Yes, I link libmingwex statically.
> > 
> > ...
> > 
> > So I hope you will find a solution that works for static linking as
> > well.
> 
> Please try the attached (modified) stdio.h; it reverts the 
> unsatisfactory function inlining, (so reverting to mingwrt-3.22 
> behaviour), but also lays the groundwork for more appropriate -Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).

Tried it.  It solves the problem; hope to see it soon in some mingwrt
release near me.

Thanks!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/17 11:10, John Brown wrote:
> I tried to follow the instructions at 
> http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
> to let me link to msvcr80 (to get access to _ftelli64).

Seems like overkill.  While _ftelli64() may not be available, in any 
version of MSVCRT.DLL, (at least up to and including Win7), _telli64(), 
_lseeki64(), and _fileno() are; surely for:

  __int64 ofs64 = _ftelli64 (foo);

you can substitute either:

  __int64 ofs64 = _lseeki64 (_fileno (foo), 0LL, SEEK_CUR);

or:

  __int64 ofs64 = _telli64 (_fileno (foo));

> When I run gcc -specs=msvcr80 -o hello hello.c, the result is:
> 
> $ gcc -specs=msvcr80 -o hello hello.c
> gcc.exe: internal compiler error: in execute, at gcc.c:2699
> libbacktrace could not find executable to open
> 
> [...snip...]
> 
> I am running the latest MinGW (gcc 5.3.0).  Am I doing something wrong?

I don't know.  The reference material relates to gcc-3.4.5; I'll need 
to play with it, to determine how relevant it may still be.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJbGEAAoJEMCtNsY0flo/cyAP/AuoNhOcktbPAqQ4Wid7ybl6
TLk2o/Y1ypSpxMnTdcJWSL3HT4q5VW/Db+2oSEds6NeHcSJsNZrJKqHp9KianUcl
tbLMKUoULeeejAWiiLJnIFDOuY7yw3kXX5dto9CsK6XN/FLGx62em/9pZPZUY+Xz
4FIjkbMdbg6SyYSkRmlZTqopEDRSCVkEsHb49IfQxnoGlz5FwX5tUCZqzGecCFqv
QYaITKgkWbeWnL7H8CfQwC0tJ81L3u+S2U2s9pVav9wKIbZX/rrvjBgtoi6KiNQg
VWmgMj+O9x4oBUTjRmEQYeFqWVLWXWIQlhT9K3oKeSWWwJQr0fSNgHcIVtnwJz4X
FFKKyM5E2tPGzHEvCq9+rj/bjABUWXxB+3DwbzIZ0/KeOvIgaO5GM43JXyNzwfvX
qpPolkgXBj6+otrtMcmcZMcTa3q85TGsXcsc3EPoV7rKmXqj7ENt6ckv5I/kiNLg
Zp0i13zkPhSugL2KAKZC6Fu8r7rVNKg5MxDOWa2g8EEshJTyBobF9I4U8BicUy5f
HZpmfOeroKTTmyCc/FByT/XIBPzbOOb4kSudZeZhSSAPbFuvG36CahlhKbl5MHuU
At5QB9XQLRZtrornfqmsINxbTTx9pv9zR1hIZYefyk2JXCASYyZe538UfkY+Y+Ht
GW1wXcrdtazu7lXjeazW
=aaww
-----END PGP SIGNATURE-----

Hello All,

I tried to follow the instructions at 
http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
to let me link to msvcr80 (to get access to _ftelli64). When I run
gcc -specs=msvcr80 -o hello hello.c, the result is:

$ gcc -specs=msvcr80 -o hello hello.c
gcc.exe: internal compiler error: in execute, at gcc.c:2699
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

hello.c looks like this:
// BEGIN hello.c
#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("Hello, world!\n");
  return 0;
}

// END hello.c

It can be compiled without -specs=msvcr80.

/mingw/lib/gcc/mingw32/5.3.0/msvcr80 looks like this:
*msvcrt:
msvcr80
[SINGLE BLANK LINE] 
*msvcrt_version:
-D__MSVCRT_VERSION__=0x0800
[SINGLE BLANK LINE] 
*moldname:
moldname80
[SINGLE BLANK LINE]

At the top of /mingw/lib/gcc/mingw32/5.3.0/specs (created by
gcc -dumpspecs) I inserted the following lines:
*msvcrt:
msvcrt
[SINGLE BLANK LINE]
*msvcrt_version:
[1st BLANK LINE]
[2nd BLANK LINE]
*moldname:
moldname
[SINGLE BLANK LINE]
*asm:
[1st BLANK LINE]
[2nd BLANK LINE]

and changed the *cpp and *libgcc definitions as follows:
*cpp:
%(msvcrt_version) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: } 


*libgcc:
%{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc -lgcc_eh}  %{!static:    %{!static-libgcc:      %{!shared:        %{!shared-libgcc:-lgcc -lgcc_eh}        %{shared-libgcc:-lgcc_s -lgcc}       }      %{shared:-lgcc_s -lgcc}     }   }     -l%(moldname) -lmingwex -l%(msvcrt)

I am running the latest  MinGW (gcc 5.3.0). Am I doing something wrong?

Regards,
John Brown.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/05/17 18:15, Eli Zaretskii wrote:
>> From: Keith Marshall
>> Date: Tue, 9 May 2017 22:59:12 +0100
>>  
>>   $ mingw32-g++ -std=gnu++11 -O2 ts.cpp -o ts.exe
>>   <success -- no diagnostic output>
>>
>> i.e. without doing anything, it appears that I am not reproducing the 
>> link failure you are reporting.  So, what is the difference between my 
>> link and yours?  Dynamic vs. static linking of libmingwex, perhaps?
> 
> Yes, I link libmingwex statically.
> 
> ...
> 
> So I hope you will find a solution that works for static linking as
> well.

Please try the attached (modified) stdio.h; it reverts the 
unsatisfactory function inlining, (so reverting to mingwrt-3.22 
behaviour), but also lays the groundwork for more appropriate -Wformat handling, (esp. with a local patch in upcoming GCC-6.3.0).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZIy47AAoJEMCtNsY0flo/v28P/1opmmbViak90jf2WASpVpXo
WAboPesvd2ZYaPtXIqqihUP2NcI0hDX4z/5yhfLKj0BiN3SsMD9NytTfHDMlNMCf
V7yco+POmgaLpUe9rIq27M9QeKeaMWO/AHGkvB1gA54paeM52jjb1xSGGAWHAiAv
JHdzvkArC+IHyPuGBJp9G0pt8rlxL7uZycXCIrlTbN7VM2stpRo0VAXA1buvtCuv
FMeJ92438/gL52/tgWHcHB6DyC0X6IHJqsOJcxzDo3E/wI3fkBw8wIaOiu/0DS8e
k39CpWKnKnbb5HGcWHR1dCwY5X5kqnHzBj43nEcSkV121iu1dGnw/KluDYod2Szi
mUnlkJoJCmvaahIhf+pxVA7GF65/r+uRlP1s6ijgf7TDadzdSpXzEIS/uRIv3XH3
HgjKV6CyXYteeEIYs+XOVKwrsIv+pjtZloUwQimhUDPt7jP+f+0qeyrNE0bUgPv1
iEXk/kXsdm/mBMu9GbCZRAa6RhkuP1S7iMHt5kWKbRVX5DOckEg+QcPMA2MedZrP
OyZc6Gm97tBR68LA2RsjBsjDFL75JDuLqMWjgY7d0U0BjWgEP9Yp2IFIHcM1cs6E
nxdA20fsc3XobgY7do940Q9tm6kGXzjqVUF/mNQ6JGKcVHhSsOhE95IhpLzbdqbg
66u27mOZ3ly/K/SpSIUW
=zVXr
-----END PGP SIGNATURE-----