date:20171121

Re: [Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

2017-11-21 Thread Liu Hao

On 2017/11/17 11:36, Liu Hao wrote:
> On 2017/11/15 9:54, Liu Hao wrote:
>> This patches addresses the issue in 
>> .
>>
>> The C99 standard treats %s, %c, %ls and %lc identically in *scanf and 
>> w*scanf,
>> hence this patch is merely copy-pasting from 
>> 72d60c1a06490ec5937e6c620956b167bf0bf329.
>>
>> With this patch the problem in the original post no longer happens on i686 
>> and x86_64.
>>
>>
> 
> Ping ?
> 
> 
Ping 2 ?


-- 
Best regards,
LH_Mouse


--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

It seems the real problem is that the build tries to compile "pex-unix.c" in
the liberty sources instead
of "pex-win32.c". And this in a build stage where the new
x86_64-w64-mingw32-gcc & environment
is already used.
That points in the direction of a perhaps buggy configure script in the case
of a bootstrapping build
of gcc using libiberty.
Maybe Cygwin is more unix-like than mingw64 & this causes confusion during
the bootstrap stages...
Will check further along this path...

-Original Message-
From: Sven Kretzschmar [mailto:sven.kretzsch...@gmx.de] 
Sent: 21 November 2017 22:03
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

I have changed the gcc build mode from --disable-bootstrap to
--enable-bootstrap with the last build.
(That's normally the correct way, the --disable-bootstrap slipped in
accidentally from earlier tests.) The missing defines are nowhere in the
"raw" mingw64 distribution, so I assume libiberty would not build with
x86_64-w64-mingw32-gcc with or without ucrtbase (when using the correct
x86_64-w64-mingw32 CROSS include directory).

With bootstrapping enabled, the build process will use the newly built gcc
as soon as possible for following build steps, also using the CROSS include
dirs. with the missing defines in/via fcntl.h.

The reason it built before was that I did not enable bootstrapping, which
resulted in the new gcc being build completely with the Cygwin-gcc &
corresponding include dirs (as this is my build environment).
In the Cygwin /usr/include/fcntl.h header those symbols are indirectly
included via another header. 
So libiberty compiled without errors in this case.

libiberty.a was built in the very first step for binutils via Cygwin-gcc (as
there was no x86_64-w64-mingw32-gcc at that time). So I just have to bring
the bootstrapping build of gcc to use that one instead of trying to build a
new version.
There is an old discussion about that & the needed option in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780
I will try it that way & inform about my results.

(But I am still a bit uneasy about those missing fcntl.h defines in the
mingw64 source distribution.
I might also try to rebuild without ucrtbase, just to test if it really
fails too, as expected.)

Cheers
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st]
Sent: 21 November 2017 21:02
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Tue, 21 Nov 2017, Sven Kretzschmar wrote:

> Thanks - now the cross compilation goes much further resulting in the 
> below error (trying to cross-compile x86_64-w64-mingw32-gcc with 
> libiberty support & ucrtbase option, other options as before, 
> bootstrapping enabled).
>
> Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) 
> are declared in "fcntl.h" or in header files included from "fcntl.h".
> However, in the mingw64 distribution, "fcntl.h" does not contain or 
> include these symbols. Therefore the below errors result...
>
> Did I overlook something ? Is this a bug or a feature (intended) or 
> was it missed/postponed ?

No idea, I haven't touched any such headers wrt ucrtbase. So it sounds like
some other feature detection goes differently than before, which means that
it now tries to build this code. In the default build that succeeds (without
ucrtbase), does it try to build these files at all?

> Maybe I can get around this by trying to compile gcc without libiberty 
> support, but I am suspicious that the missing defines might cause 
> problems later in other places...

Nah, I'd recommend trying to dig into and see why you're running into this
issue instead of trying to sidestep it.

> Other subject:
> Using clang with mingw64 instead of gcc to compile Julia (The Julia
> language) sounds like an interesting alternative, however getting 
> Julia compiled with all its dependencies (including fortran sources) 
> with clang instead of gcc would be a huge effort, if at all possible.

Yes, the clang/llvm based toolchain is much less mature in all aspects, so I
wouldn't recommend it unless you have interest in it for another reason (my
reason is support for windows on non-x86 platforms).

// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

I have changed the gcc build mode from --disable-bootstrap to
--enable-bootstrap with the last build.
(That's normally the correct way, the --disable-bootstrap slipped in
accidentally from earlier tests.)
The missing defines are nowhere in the "raw" mingw64 distribution, so I
assume libiberty would not build
with x86_64-w64-mingw32-gcc with or without ucrtbase (when using the correct
x86_64-w64-mingw32 CROSS include directory).

With bootstrapping enabled, the build process will use the newly built gcc
as soon as possible for following build steps,
also using the CROSS include dirs. with the missing defines in/via fcntl.h.

The reason it built before was that I did not enable bootstrapping, which
resulted in the new gcc being build
completely with the Cygwin-gcc & corresponding include dirs (as this is my
build environment).
In the Cygwin /usr/include/fcntl.h header those symbols are indirectly
included via another header. 
So libiberty compiled without errors in this case.

libiberty.a was built in the very first step for binutils via Cygwin-gcc (as
there was no x86_64-w64-mingw32-gcc at
that time). So I just have to bring the bootstrapping build of gcc to use
that one instead of trying to build a new version.
There is an old discussion about that & the needed option in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780
I will try it that way & inform about my results.

(But I am still a bit uneasy about those missing fcntl.h defines in the
mingw64 source distribution.
I might also try to rebuild without ucrtbase, just to test if it really
fails too, as expected.)

Cheers
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 21 November 2017 21:02
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Tue, 21 Nov 2017, Sven Kretzschmar wrote:

> Thanks - now the cross compilation goes much further resulting in the 
> below error (trying to cross-compile x86_64-w64-mingw32-gcc with 
> libiberty support & ucrtbase option, other options as before, 
> bootstrapping enabled).
>
> Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) 
> are declared in "fcntl.h" or in header files included from "fcntl.h".
> However, in the mingw64 distribution, "fcntl.h" does not contain or 
> include these symbols. Therefore the below errors result...
>
> Did I overlook something ? Is this a bug or a feature (intended) or 
> was it missed/postponed ?

No idea, I haven't touched any such headers wrt ucrtbase. So it sounds like
some other feature detection goes differently than before, which means that
it now tries to build this code. In the default build that succeeds (without
ucrtbase), does it try to build these files at all?

> Maybe I can get around this by trying to compile gcc without libiberty 
> support, but I am suspicious that the missing defines might cause 
> problems later in other places...

Nah, I'd recommend trying to dig into and see why you're running into this
issue instead of trying to sidestep it.

> Other subject:
> Using clang with mingw64 instead of gcc to compile Julia (The Julia
> language) sounds like an interesting alternative, however getting 
> Julia compiled with all its dependencies (including fortran sources) 
> with clang instead of gcc would be a huge effort, if at all possible.

Yes, the clang/llvm based toolchain is much less mature in all aspects, so I
wouldn't recommend it unless you have interest in it for another reason (my
reason is support for windows on non-x86 platforms).

// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Martin Storsjö


On Tue, 21 Nov 2017, Sven Kretzschmar wrote:


Thanks - now the cross compilation goes much further resulting in the below
error
(trying to cross-compile x86_64-w64-mingw32-gcc with libiberty support &
ucrtbase option, other options as before, bootstrapping enabled).

Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) are
declared in "fcntl.h" or in header files included from "fcntl.h".
However, in the mingw64 distribution, "fcntl.h" does not contain or include
these symbols. Therefore the below errors result...

Did I overlook something ? Is this a bug or a feature (intended) or was it
missed/postponed ?


No idea, I haven't touched any such headers wrt ucrtbase. So it sounds 
like some other feature detection goes differently than before, which 
means that it now tries to build this code. In the default build that 
succeeds (without ucrtbase), does it try to build these files at all?



Maybe I can get around this by trying to compile gcc without libiberty
support, but I am suspicious that the missing defines might
cause problems later in other places...


Nah, I'd recommend trying to dig into and see why you're running into this 
issue instead of trying to sidestep it.



Other subject:
Using clang with mingw64 instead of gcc to compile Julia (The Julia
language) sounds like an interesting alternative, however
getting Julia compiled with all its dependencies (including fortran sources)
with clang instead of gcc would be a huge effort, if at all possible.


Yes, the clang/llvm based toolchain is much less mature in all aspects, so 
I wouldn't recommend it unless you have interest in it for another reason 
(my reason is support for windows on non-x86 platforms).


// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

Thanks - now the cross compilation goes much further resulting in the below
error
(trying to cross-compile x86_64-w64-mingw32-gcc with libiberty support &
ucrtbase option, other options as before, bootstrapping enabled).

Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) are
declared in "fcntl.h" or in header files included from "fcntl.h".
However, in the mingw64 distribution, "fcntl.h" does not contain or include
these symbols. Therefore the below errors result...

Did I overlook something ? Is this a bug or a feature (intended) or was it
missed/postponed ?

Maybe I can get around this by trying to compile gcc without libiberty
support, but I am suspicious that the missing defines might
cause problems later in other places...

Thanks for having a short look or any further hint :)


Other subject:
Using clang with mingw64 instead of gcc to compile Julia (The Julia
language) sounds like an interesting alternative, however
getting Julia compiled with all its dependencies (including fortran sources)
with clang instead of gcc would be a huge effort, if at all possible.
So I hope getting the gnu toolchain to work with mingw64 & ucrtbase will be
much easier & help other projects too - at least it
seems to be very close now (famous last words... ;).


ERROR msg in last step of cross build ("make" for gcc):

/home/sven/buildtmp/build/gcc/./prev-gcc/xgcc
-B/home/sven/buildtmp/build/gcc/./prev-gcc/
-B/CROSS64/x86_64-w64-mingw32/bin/ -L/CROSS64/x86_64-w64-mingw32/lib
-L/CROSS64/mingw/lib -isystem /CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/mingw/include -B/CROSS64/x86_64-w64-mingw32/bin/
-B/CROSS64/x86_64-w64-mingw32/lib/ -isystem
/CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/x86_64-w64-mingw32/sys-include-c -DHAVE_CONFIG_H -g -O2
-gtoggle  -I. -I../../../src/gcc/libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -D_GNU_SOURCE
../../../src/gcc/libiberty/pex-unix.c -o pex-unix.o
../../../src/gcc/libiberty/pex-unix.c: In function 'pex_wait':
../../../src/gcc/libiberty/pex-unix.c:257:14: warning: implicit declaration
of function 'wait' [-Wimplicit-function-declaration]
   cpid = wait (status);
  ^~~~
../../../src/gcc/libiberty/pex-unix.c: At top level:
../../../src/gcc/libiberty/pex-unix.c:326:3: warning: initialization from
incompatible pointer type [-Wincompatible-pointer-types]
   pex_unix_wait,
   ^
../../../src/gcc/libiberty/pex-unix.c:326:3: note: (near initialization for
'funcs.wait')
../../../src/gcc/libiberty/pex-unix.c: In function 'save_and_install_fd':
../../../src/gcc/libiberty/pex-unix.c:407:11: warning: implicit declaration
of function 'fcntl' [-Wimplicit-function-declaration]
   flags = fcntl (old_fd, F_GETFD);
   ^
../../../src/gcc/libiberty/pex-unix.c:407:26: error: 'F_GETFD' undeclared
(first use in this function)
   flags = fcntl (old_fd, F_GETFD);
  ^~~
../../../src/gcc/libiberty/pex-unix.c:407:26: note: each undeclared
identifier is reported only once for each function it appears in
../../../src/gcc/libiberty/pex-unix.c:420:20: error: 'FD_CLOEXEC' undeclared
(first use in this function)
   if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd, F_SETFD, FD_CLOEXEC)
< 0)
^~
../../../src/gcc/libiberty/pex-unix.c:420:55: error: 'F_SETFD' undeclared
(first use in this function)
   if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd, F_SETFD, FD_CLOEXEC)
< 0)
   ^~~
../../../src/gcc/libiberty/pex-unix.c:433:31: error: 'F_DUPFD' undeclared
(first use in this function)
   new_fd = fcntl (old_fd, F_DUPFD, 3);
   ^~~
../../../src/gcc/libiberty/pex-unix.c: In function 'restore_fd':
../../../src/gcc/libiberty/pex-unix.c:467:19: error: 'FD_CLOEXEC' undeclared
(first use in this function)
   if (flags & FD_CLOEXEC)
   ^~
../../../src/gcc/libiberty/pex-unix.c:469:29: error: 'F_SETFD' undeclared
(first use in this function)
   return fcntl (old_fd, F_SETFD, flags);

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 21 November 2017 09:14
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Mon, 20 Nov 2017, Sven Kretzschmar wrote:

> Hi,
>
> Thanks a lot for all your work on this project ! :)
>
> I am using the newest master branch of mingw64 from 
> https://github.com/mirror/mingw-w64/tree/master .
> GCC version used is:
> https://github.com/gcc-mirror/gcc/tree/gcc-6_4_0-release  (6.4.0) And 
> the newest version of all other needed libs.
> Also I am using cygwin64 with x86_64-pc-cygwin-gcc and the necessary 
> devel packages (except mingw64).
>
> I am trying to cross-compile targeting a mingw64 toolchain (binutils, 
> gcc,
> runtime,.) which is based on ucrtbase instead of msvcrt.
> Motivation is that

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 Thread Kai Tietz via Mingw-w64-public

2017-11-21 11:36 GMT+01:00 Martin Storsjö :
> On Tue, 21 Nov 2017, Martin Storsjö wrote:
>
>> On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote:
>>
>>> Hi,
>>>
>>> Why was 'DllGetVersion' removed? Otherwise patch is ok.
>>
>>
>> It wasn't present in the libarm32 version of this, and I thought it was
>> one of the runtime dll entry points that one didn't really want to link toso
>> that it wouldn't matter. But I can keep it just in case so it won't end up
>> as a surprise.
>
>
> Pushed with this function kept, thanks!
>
> // Martin

Thank you :)

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

2017-11-21 Thread Yuta Nakai

>__MINGW_IMPORT (which expands to dllimport)
ah, that's right. Sorry, I missed that. 
I thought these global variables was declared with extern(w/o dllimport) in the 
samy way as other global variables.

From: Martin Storsjö 
Sent: 21 November 2017 13:43
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Fix definitions of 
_daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

On Tue, 21 Nov 2017, Yuta Nakai wrote:

> Attached patch fixes the definitions of _daylight/_dstbias/_timezone/_tzname 
> for msvcr*.dll.
> These are global variables and exported as DATA symbols,  so we should use 
> __MINGW_IMP_SYMBOL.

In which case do you see an actual difference in behaviour compared to
now, when they are declared with __MINGW_IMPORT (which expands to
dllimport)? I did a quick test with msvcrt.dll and it seemed to work just
fine as it is right now.

// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

2017-11-21 Thread Martin Storsjö


On Tue, 21 Nov 2017, Yuta Nakai wrote:


Attached patch fixes the definitions of _daylight/_dstbias/_timezone/_tzname 
for msvcr*.dll.
These are global variables and exported as DATA symbols,  so we should use 
__MINGW_IMP_SYMBOL.


In which case do you see an actual difference in behaviour compared to 
now, when they are declared with __MINGW_IMPORT (which expands to 
dllimport)? I did a quick test with msvcrt.dll and it seemed to work just 
fine as it is right now.


// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

2017-11-21 Thread Yuta Nakai

Attached patch fixes the definitions of _daylight/_dstbias/_timezone/_tzname 
for msvcr*.dll.
These are global variables and exported as DATA symbols,  so we should use 
__MINGW_IMP_SYMBOL.From 7c414985d86ae49ba9d7a856201b8f1db103330e Mon Sep 17 00:00:00 2001
From: Yuta Nakai 
Date: Tue, 21 Nov 2017 22:07:25 +0900
Subject: [PATCH] Fix definitions of _daylight/_dstbias/_timezone/_tzname for
 msvcr*.dll

---
 mingw-w64-headers/crt/time.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index 886ec940..aaae20c2 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -119,10 +119,14 @@ extern "C" {
 #define _timezone (* __timezone())
 #define _tzname (__tzname())
 #else
-  __MINGW_IMPORT int _daylight;
-  __MINGW_IMPORT long _dstbias;
-  __MINGW_IMPORT long _timezone;
-  __MINGW_IMPORT char * _tzname[2];
+  __MINGW_IMPORT int  *__MINGW_IMP_SYMBOL(_daylight);
+  __MINGW_IMPORT long *__MINGW_IMP_SYMBOL(_dstbias);
+  __MINGW_IMPORT long *__MINGW_IMP_SYMBOL(_timezone);
+  __MINGW_IMPORT char * (* __MINGW_IMP_SYMBOL(_tzname))[2];
+#define _daylight (* __MINGW_IMP_SYMBOL(_daylight))
+#define _dstbias  (* __MINGW_IMP_SYMBOL(_dstbias))
+#define _timezone (* __MINGW_IMP_SYMBOL(_timezone))
+#define _tzname   (* __MINGW_IMP_SYMBOL(_tzname))
 #endif
 
   _CRTIMP errno_t __cdecl _get_daylight(int *_Daylight);
-- 
2.15.0

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

2017-11-21 Thread Martin Storsjö


On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote:


Patch is ok. Please go ahead and apply.


Pushed, thanks!

// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 Thread Martin Storsjö


On Tue, 21 Nov 2017, Martin Storsjö wrote:


On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote:


Hi,

Why was 'DllGetVersion' removed? Otherwise patch is ok.


It wasn't present in the libarm32 version of this, and I thought it was one 
of the runtime dll entry points that one didn't really want to link toso that 
it wouldn't matter. But I can keep it just in case so it won't end up as a 
surprise.


Pushed with this function kept, thanks!

// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 Thread Martin Storsjö


On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote:


Hi,

Why was 'DllGetVersion' removed? Otherwise patch is ok.


It wasn't present in the libarm32 version of this, and I thought it was 
one of the runtime dll entry points that one didn't really want to link 
toso that it wouldn't matter. But I can keep it just in case so it won't 
end up as a surprise.


// 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 Thread Kai Tietz via Mingw-w64-public

Hi,

Why was 'DllGetVersion' removed? Otherwise patch is ok.

Thanks,
Kai

2017-11-21 9:15 GMT+01:00 Martin Storsjö :
> Use the new shared def file for arm64 as well.
>
> Signed-off-by: Martin Storsjö 
> ---
>  mingw-w64-crt/{lib64 => lib-common}/shlwapi.def |  15 +-
>  mingw-w64-crt/libarm32/shlwapi.def  | 935 
> 
>  mingw-w64-crt/libarm64/Makefile.am  |   1 +
>  3 files changed, 13 insertions(+), 938 deletions(-)
>  rename mingw-w64-crt/{lib64 => lib-common}/shlwapi.def (96%)
>  delete mode 100644 mingw-w64-crt/libarm32/shlwapi.def
>
> diff --git a/mingw-w64-crt/lib64/shlwapi.def 
> b/mingw-w64-crt/lib-common/shlwapi.def
> similarity index 96%
> rename from mingw-w64-crt/lib64/shlwapi.def
> rename to mingw-w64-crt/lib-common/shlwapi.def
> index 7f5e88e..f8ef132 100644
> --- a/mingw-w64-crt/lib64/shlwapi.def
> +++ b/mingw-w64-crt/lib-common/shlwapi.def
> @@ -1,7 +1,7 @@
>  ;
>  ; Definition file of SHLWAPI.dll
>  ; Automatic generated by gendef
> -; written by Kai Tietz 2008
> +; written by Kai Tietz 2008-2014
>  ;
>  LIBRARY "SHLWAPI.dll"
>  EXPORTS
> @@ -24,6 +24,8 @@ StrCmpCA
>  StrCmpCW
>  StrCmpICA
>  StrCmpICW
> +IUnknown_QueryStatus
> +IUnknown_Exec
>  ConnectToConnectionPoint
>  IUnknown_AtomicRelease
>  IUnknown_GetWindow
> @@ -40,11 +42,16 @@ IStream_Reset
>  IStream_Size
>  SHAnsiToUnicode
>  SHUnicodeToAnsi
> +SHUnicodeToAnsiCP
>  QISearch
>  SHStripMneumonicW
> +SHPinDllOfCLSID
>  IUnknown_GetSite
> +GUIDFromStringW
>  WhichPlatform
> +SHCreateWorkerWindowW
>  SHRegGetIntW
> +SHPackDispParamsV
>  SHAnsiToAnsi
>  SHUnicodeToUnicode
>  SHFormatDateTimeA
> @@ -56,6 +63,7 @@ MLFreeLibrary
>  SHSendMessageBroadcastA
>  SHSendMessageBroadcastW
>  IsOS
> +PathFileExistsAndAttributesW
>  UrlFixupW
>  SHRunIndirectRegClientCommand
>  SHLoadIndirectString
> @@ -83,15 +91,16 @@ ColorHLSToRGB
>  IStream_ReadStr
>  IStream_WriteStr
>  ColorRGBToHLS
> -DllGetVersion
>  GetMenuPosFromID
>  HashData
> -IntlStrEqWorkerA
>  SHCreateThreadWithHandle
> +IntlStrEqWorkerA
>  IntlStrEqWorkerW
>  IsCharSpaceA
>  PathAddBackslashA
>  PathAddBackslashW
> +SHRegGetValueFromHKCUHKLM
> +SHRegGetBoolValueFromHKCUHKLM
>  PathAddExtensionA
>  PathAddExtensionW
>  PathAppendA
> diff --git a/mingw-w64-crt/libarm32/shlwapi.def 
> b/mingw-w64-crt/libarm32/shlwapi.def
> deleted file mode 100644
> index a2616f2..000
> diff --git a/mingw-w64-crt/libarm64/Makefile.am 
> b/mingw-w64-crt/libarm64/Makefile.am
> index 51d2ba1..735192c 100644
> --- a/mingw-w64-crt/libarm64/Makefile.am
> +++ b/mingw-w64-crt/libarm64/Makefile.am
> @@ -228,6 +228,7 @@ libarm64_DATA += %reldir%/libserwvdrv.a
>  #libarm64_DATA += %reldir%/libshell32.a# Handled by custom rule
>  libarm64_DATA += %reldir%/libshfolder.a
>  libarm64_DATA += %reldir%/libshimgvw.a
> +libarm64_DATA += %reldir%/libshlwapi.a
>  libarm64_DATA += %reldir%/libshsvcs.a
>  libarm64_DATA += %reldir%/libsisbkup.a
>  libarm64_DATA += %reldir%/libslcext.a
> --
> 2.7.4
>
>
> --
> 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
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

2017-11-21 Thread Kai Tietz via Mingw-w64-public

Patch is ok. Please go ahead and apply.

Thanks,
Kai

2017-11-21 9:14 GMT+01:00 Martin Storsjö :
> GCC throws an error when faced with "static static", while clang
> handles it fine.
>
> _mingw_mac.h defines __mingw_static_ovr to be a version of __mingw_ovr
> that always is static (the normal __mingw_ovr is plain "inline __cdecl"
> in C++, while it does include "static" in C).
>
> However, swprintf.inl and wchar.h redefine __mingw_ovr to also include
> static even for C++, for GCC (and anything defining __GNUC__), leading
> to a double "static static" in C++ mode, if these headers are included
> last.
> ---
>  mingw-w64-headers/crt/swprintf.inl | 4 
>  mingw-w64-headers/crt/wchar.h  | 4 
>  2 files changed, 8 insertions(+)
>
> diff --git a/mingw-w64-headers/crt/swprintf.inl 
> b/mingw-w64-headers/crt/swprintf.inl
> index d7db2ad..f96be98 100644
> --- a/mingw-w64-headers/crt/swprintf.inl
> +++ b/mingw-w64-headers/crt/swprintf.inl
> @@ -12,6 +12,10 @@
>  #undef __mingw_ovr
>  #if defined (__GNUC__)
>  #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
> +#ifdef __mingw_static_ovr
> +#undef __mingw_static_ovr
> +#define __mingw_static_ovr __mingw_ovr
> +#endif
>  #elif defined(__cplusplus)
>  #define __mingw_ovr inline __cdecl
>  #else
> diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
> index 61c0a41..6783a22 100644
> --- a/mingw-w64-headers/crt/wchar.h
> +++ b/mingw-w64-headers/crt/wchar.h
> @@ -507,6 +507,10 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A 
> pointer to an array of FILE */
>  #undef __mingw_ovr
>  #if defined (__GNUC__)
>  #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
> +#ifdef __mingw_static_ovr
> +#undef __mingw_static_ovr
> +#define __mingw_static_ovr __mingw_ovr
> +#endif
>  #elif defined(__cplusplus)
>  #define __mingw_ovr inline __cdecl
>  #else
> --
> 2.7.4
>
>
> --
> 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
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 Thread Martin Storsjö

Use the new shared def file for arm64 as well.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/{lib64 => lib-common}/shlwapi.def |  15 +-
 mingw-w64-crt/libarm32/shlwapi.def  | 935 
 mingw-w64-crt/libarm64/Makefile.am  |   1 +
 3 files changed, 13 insertions(+), 938 deletions(-)
 rename mingw-w64-crt/{lib64 => lib-common}/shlwapi.def (96%)
 delete mode 100644 mingw-w64-crt/libarm32/shlwapi.def

diff --git a/mingw-w64-crt/lib64/shlwapi.def 
b/mingw-w64-crt/lib-common/shlwapi.def
similarity index 96%
rename from mingw-w64-crt/lib64/shlwapi.def
rename to mingw-w64-crt/lib-common/shlwapi.def
index 7f5e88e..f8ef132 100644
--- a/mingw-w64-crt/lib64/shlwapi.def
+++ b/mingw-w64-crt/lib-common/shlwapi.def
@@ -1,7 +1,7 @@
 ;
 ; Definition file of SHLWAPI.dll
 ; Automatic generated by gendef
-; written by Kai Tietz 2008
+; written by Kai Tietz 2008-2014
 ;
 LIBRARY "SHLWAPI.dll"
 EXPORTS
@@ -24,6 +24,8 @@ StrCmpCA
 StrCmpCW
 StrCmpICA
 StrCmpICW
+IUnknown_QueryStatus
+IUnknown_Exec
 ConnectToConnectionPoint
 IUnknown_AtomicRelease
 IUnknown_GetWindow
@@ -40,11 +42,16 @@ IStream_Reset
 IStream_Size
 SHAnsiToUnicode
 SHUnicodeToAnsi
+SHUnicodeToAnsiCP
 QISearch
 SHStripMneumonicW
+SHPinDllOfCLSID
 IUnknown_GetSite
+GUIDFromStringW
 WhichPlatform
+SHCreateWorkerWindowW
 SHRegGetIntW
+SHPackDispParamsV
 SHAnsiToAnsi
 SHUnicodeToUnicode
 SHFormatDateTimeA
@@ -56,6 +63,7 @@ MLFreeLibrary
 SHSendMessageBroadcastA
 SHSendMessageBroadcastW
 IsOS
+PathFileExistsAndAttributesW
 UrlFixupW
 SHRunIndirectRegClientCommand
 SHLoadIndirectString
@@ -83,15 +91,16 @@ ColorHLSToRGB
 IStream_ReadStr
 IStream_WriteStr
 ColorRGBToHLS
-DllGetVersion
 GetMenuPosFromID
 HashData
-IntlStrEqWorkerA
 SHCreateThreadWithHandle
+IntlStrEqWorkerA
 IntlStrEqWorkerW
 IsCharSpaceA
 PathAddBackslashA
 PathAddBackslashW
+SHRegGetValueFromHKCUHKLM
+SHRegGetBoolValueFromHKCUHKLM
 PathAddExtensionA
 PathAddExtensionW
 PathAppendA
diff --git a/mingw-w64-crt/libarm32/shlwapi.def 
b/mingw-w64-crt/libarm32/shlwapi.def
deleted file mode 100644
index a2616f2..000
diff --git a/mingw-w64-crt/libarm64/Makefile.am 
b/mingw-w64-crt/libarm64/Makefile.am
index 51d2ba1..735192c 100644
--- a/mingw-w64-crt/libarm64/Makefile.am
+++ b/mingw-w64-crt/libarm64/Makefile.am
@@ -228,6 +228,7 @@ libarm64_DATA += %reldir%/libserwvdrv.a
 #libarm64_DATA += %reldir%/libshell32.a# Handled by custom rule
 libarm64_DATA += %reldir%/libshfolder.a
 libarm64_DATA += %reldir%/libshimgvw.a
+libarm64_DATA += %reldir%/libshlwapi.a
 libarm64_DATA += %reldir%/libshsvcs.a
 libarm64_DATA += %reldir%/libsisbkup.a
 libarm64_DATA += %reldir%/libslcext.a
-- 
2.7.4


--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

2017-11-21 Thread Martin Storsjö

GCC throws an error when faced with "static static", while clang
handles it fine.

_mingw_mac.h defines __mingw_static_ovr to be a version of __mingw_ovr
that always is static (the normal __mingw_ovr is plain "inline __cdecl"
in C++, while it does include "static" in C).

However, swprintf.inl and wchar.h redefine __mingw_ovr to also include
static even for C++, for GCC (and anything defining __GNUC__), leading
to a double "static static" in C++ mode, if these headers are included
last.
---
 mingw-w64-headers/crt/swprintf.inl | 4 
 mingw-w64-headers/crt/wchar.h  | 4 
 2 files changed, 8 insertions(+)

diff --git a/mingw-w64-headers/crt/swprintf.inl 
b/mingw-w64-headers/crt/swprintf.inl
index d7db2ad..f96be98 100644
--- a/mingw-w64-headers/crt/swprintf.inl
+++ b/mingw-w64-headers/crt/swprintf.inl
@@ -12,6 +12,10 @@
 #undef __mingw_ovr
 #if defined (__GNUC__)
 #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
+#ifdef __mingw_static_ovr
+#undef __mingw_static_ovr
+#define __mingw_static_ovr __mingw_ovr
+#endif
 #elif defined(__cplusplus)
 #define __mingw_ovr inline __cdecl
 #else
diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 61c0a41..6783a22 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -507,6 +507,10 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A 
pointer to an array of FILE */
 #undef __mingw_ovr
 #if defined (__GNUC__)
 #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
+#ifdef __mingw_static_ovr
+#undef __mingw_static_ovr
+#define __mingw_static_ovr __mingw_ovr
+#endif
 #elif defined(__cplusplus)
 #define __mingw_ovr inline __cdecl
 #else
-- 
2.7.4


--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Martin Storsjö


On Mon, 20 Nov 2017, Sven Kretzschmar wrote:


Hi,

Thanks a lot for all your work on this project ! :)

I am using the newest master branch of mingw64 from
https://github.com/mirror/mingw-w64/tree/master .
GCC version used is:
https://github.com/gcc-mirror/gcc/tree/gcc-6_4_0-release  (6.4.0)
And the newest version of all other needed libs.
Also I am using cygwin64 with x86_64-pc-cygwin-gcc and the necessary devel
packages (except mingw64).

I am trying to cross-compile targeting a mingw64 toolchain (binutils, gcc,
runtime,.) which is based on ucrtbase instead of msvcrt.
Motivation is that I want to compile Julia ( https://julialang.org/ ) so
that the compiled dlls and binaries are dependent on ucrtbase.dll
and not on msvcrt.dll which enables for easier embedding in another program
which was compiled with MS VS 2015.
(-> no trouble with incompatible file descriptors, stdin/out/err, memory
management, etc.)
Julia: https://github.com/JuliaLang/julia/tree/v0.6.1

Julia is best compiled on Windows with cygwin64 (Compilation via MSYS2 seems
to be broken currently & MS VC not possible)

When targeting ucrtbase, I get 3 errors & am unable to finish the build.


Questions:
--
==> Are there any ideas on how to fix this, or is an ucrtbase build not yet
usable/possible with Mingw64 ?
==> Can you indicate which versions of gcc / binutils you are using
to test the ucrtbase build option and post which configure options you are
using for:
- gcc
- mingw64-headers
- mingw64.crt
- binutils
This could help a lot to check/debug & get a successful ming64 cross build
with ucrtbase option. Thanks :))


Here are my configures for
Mingw64-headers:
../../src/mingw-w64/mingw-w64-headers/configure
--prefix=/CROSS64/x86_64-w64-mingw32 --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --enable-sdk=all --enable-secure-api
--enable-idl --without-widl --with-default-msvcrt=ucrtbase

Mingw64-crt:
../../src/mingw-w64/mingw-w64-crt/configure
--prefix=/CROSS64/x86_64-w64-mingw32
--with-sysroot=/CROSS64/x86_64-w64-mingw32 --build=x86_64-pc-cygwin
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-lib64
--disable-lib32 --enable-wildcard --with-default-msvcrt=ucrtbase

Gcc:
../../src/gcc/configure --prefix=/CROSS64 --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --with-sysroot=/CROSS64 --with-gmp=/support
--with-mpfr=/support --with-mpc=/support
--enable-languages=c,c++,fortran,lto --disable-multilib
--disable-win32-registry --enable-fully-dynamic-string --enable-graphite
--enable-libgomp --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-version-specific-runtime-libs --enable-libgomp
--with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic
--with-system-zlib --enable-threads=posix --disable-bootstrap
--with-native-system-header-dir=/x86_64-w64-mingw32/include
--with-arch=x86-64 --enable-shared --enable-static --enable-libatomic
--enable-libstdcxx-time=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --disable-isl-version-check --enable-lto
--enable-checking=release --disable-rpath --disable-nls --disable-werror
--with-libiconv --disable-symvers --enable-linker-build-id

Binutils:
../../src/binutils/configure --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --prefix=/CROSS64 --with-sysroot=/CROSS64
--disable-multilib --disable-werror --enable-lto --enable-64-bit-bfd
--enable-nls --disable-rpath --enable-install-libiberty --enable-plugins
--enable-gold --disable-shared --with-libiconv-prefix=/CROSS64

When I use the above configures _without_ the
"--with-default-msvcrt=ucrtbase" options, I can generate the whole toolchain
without problems & compile Julia.but with msvcrt.dll dependency.

When I use the above configure options, the following errors occur in the
last step of the cross-compile (roughly following the build recipe given
at:
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-doc/howto-build/mi
ngw-w64-howto-build-adv.txt & others )

ERROR #1:
--
(executing "make" for gcc ):
Include dir: \x86_64-w64-mingw32\include:
Conflicting specifiers in declarations in time.h:  for difftime, ctime,
gmtime, ., time.
Conflicting specifiers in declarations in stdio.h: for fseek, fseeko, .,
ftelli64.
Conflicting specifiers in declarations in wchar.h: for _snwprintf.

=>It seems that the "__mingw_static_ovr" define is not expanded correctly.


I was able to reproduce this issue - the issue is that __mingw_static_ovr 
is defined as "static __mingw_ovr" in cases where __mingw_ovr doesn't 
contain the "static" keyword. But then later another header redefines 
__mingw_ovr to include the static keyword. I'll send a patch to fix this.


// 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
Mingw-w64-public@lists.sourceforge.net

Re: [Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

[Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

[Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

[Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

17 matches

Site Navigation

Mail list logo

Footer information