Re: [Mingw-w64-public] [PATCH] crt: Reimplement `dirname()` and `basename()`

[Corinna Vinschen]

On Mar 29 22:19, LIU Hao wrote:
> 在 2023-03-29 21:33, Corinna Vinschen 写道:
> > I don't think this is correct.  Multiple backslashes are folded into a
> > single backslash by the Windows API layer.  Thus \\host\\share is not
> > equivalent to
> > 
> >\\host\\
> > 
> > but to
> > 
> >\\host\share
> > 
> > Try this example, please:
> 
> Well, I didn't use `GetFinalPathNameByHandle()`, but examined these paths in 
> CMD:
> 
>C:\>dir \\192.168.1.8\\temp_share
>The specified path is invalid.
> 
>C:\>dir \\192.168.1.8\temp_share
>(... directory contents follow ...)
> 
> 
> As you can see, if we assume that CMD doesn't do path resolution itself, 
> these paths are not equivalent.

Well, CMD is just one application and, given how the Windows API
works, is not free from bugs...


Corinna


___
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: Reimplement `dirname()` and `basename()`

[Corinna Vinschen]

On Mar 29 19:34, LIU Hao wrote:
> 在 2023/3/29 16:40, Corinna Vinschen 写道:
> > > > No, this would allow splitting `\\host\\share` as `host` and `share`. In
> > > > this path the share name is `\share`, and does not match `share`.
> > 
> > I was just pointing out that "\foo" can't be a share name, because
> > backslashes can't be part of a name.
> > 
> > On second thought, maybe I don't understand what you were trying to say.
> > Can you rephrase, please?
> 
> Apologies for the confusion.
> 
> There was a mistake in the quote above, but the point in that message holds:
> `\\host\\share` is not a valid UNC path. If we allowed `dirname()` to remove
> the share name as a plain component, then, because `dirname()` treats
> consecutive separators as a single one, the result would be
> 
>dirname("\\host\\share")   = "\\host"
>basename("\\host\\share")  = "share"
> 
> which would be incorrect. "\\host\\share" is a UNC path with an empty share
> name (that's why it's invalid),

I don't think this is correct.  Multiple backslashes are folded into a
single backslash by the Windows API layer.  Thus \\host\\share is not
equivalent to

  \\host\\

but to

  \\host\share

Try this example, please:

$ cat > gfp.c <
#include 

int
main (int argc, char **argv)
{
  char buf[256];

  GetFullPathNameA (argv[1], 256, buf, NULL);
  printf ("%s\n", buf);
}
EOF
$ gcc -g -o gfp gfp.c
$ ./gfp '\\host\share'
\\host\share
$ ./gfp '\\host\\share'
\\host\share
$ ./gfp '\\host\\\share'
\\host\share

And here's the same for an existing share:

$ cat > gfp2.c <
#include 

int
main (int argc, char **argv)
{
  char buf[256];
  HANDLE h;

  h = CreateFileA (argv[1], GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,
   NULL, OPEN_ALWAYS, FILE_FLAG_BACKUP_SEMANTICS, NULL);
  if (h != INVALID_HANDLE_VALUE)
{
  GetFinalPathNameByHandleA (h, buf, 256,
 FILE_NAME_NORMALIZED | VOLUME_NAME_DOS);
  printf ("%s\n", buf);
  CloseHandle (h);
}
}
EOF
$ gcc -g -o gfp2 gfp2.c
$ ./gfp '\\calimero\corinna'
\\?\UNC\calimero\corinna
$ ./gfp '\\calimero\\corinna'
\\?\UNC\calimero\corinna
$ ./gfp '\\calimero\\\corinna'
\\?\UNC\calimero\corinna

> and we probably shouldn't make it
> indistinguishable from `\\host\share`. So it should be
> 
>dirname("\\host\\share")   = "\\host\"
>basename("\\host\\share")  = "share"
> 
> 
> > Actually, the dirname function is not supposed to fold slashes (or
> > backslashes) at all, except at the start of the path.  It's also not
> > supposed to throw any errors.  It just cuts the path so that the last
> > path component is dropped.
> 
> My point is that `\\host\share` is a volume name (the 'prefix', like `C:`)
> and is not made up of two components. `dirname()` is supposed to remove the
> last component, but there is no such component to remove.

Yes, that's a valid point.  My point of view differs, but ultimately that
doesn't matter much.


Corinna


___
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: Reimplement `dirname()` and `basename()`

[Corinna Vinschen]

On Mar 29 09:14, LIU Hao wrote:
> 在 2023/3/29 01:53, Corinna Vinschen 写道:
> > Backslahs is one of the characters not allowed as part of a share
> > name, just as it is not allowed as part of a filename.  I. e.
> > 
> >\\host\share is ok
> >\\host\\share can't exist
> 
> Yes, so the backslash between the host name and share name is special,
> right? By convention `dirname()` removes consecutive slashes, but it should
> not remove this special one?

Uhm, no.  You wrote

> > No, this would allow splitting `\\host\\share` as `host` and `share`. In
> > this path the share name is `\share`, and does not match `share`.

I was just pointing out that "\foo" can't be a share name, because
backslashes can't be part of a name.

On second thought, maybe I don't understand what you were trying to say.
Can you rephrase, please?

> > Hmm, ok.  But \\host\ is just as invalid as \\host...
> 
> Because these two functions can't report errors, maybe an invalid output
> from an invalid input is acceptable, but a valid output from an invalid
> input (e.g. `\\host\share` from `\\host\\share`) or an invalid output from a
> valid input (e.g. `\\host` from `\\host\share`) is not acceptable?

Actually, the dirname function is not supposed to fold slashes (or
backslashes) at all, except at the start of the path.  It's also not
supposed to throw any errors.  It just cuts the path so that the last
path component is dropped.

  dirname("/a///b///c///") --> /a///b
  dirname("/a///b") --> /a
  dirname("/a") --> /

In terms of the double (back)slashes, they are only special at the start
of the path.  Per POSIX:

 "A pathname that begins with two successive slashes may be interpreted
  in an implementation-defined manner, although more than two leading
  slashes shall be treated as a single slash."

I.e.:

  dirname("///a") --> /
  dirname("//a") --> //
  dirname("/a") --> /


Corinna


___
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: Reimplement `dirname()` and `basename()`

[Corinna Vinschen]

On Mar 28 22:31, LIU Hao wrote:
> 在 2023-03-28 21:41, Corinna Vinschen 写道:
> > Either you allow to split the *entire* share path, so you can use
> > dirname/basename to split \\host\share into the host and the share path,
> > and also to split \\ and host.  That would allow to inspect the host and
> > share components using the same functions.
> 
> No, this would allow splitting `\\host\\share` as `host` and `share`. In
> this path the share name is `\share`, and does not match `share`.

Backslahs is one of the characters not allowed as part of a share
name, just as it is not allowed as part of a filename.  I. e.

  \\host\share is ok
  \\host\\share can't exist

> > Or you value the fact that the resulting path is still valid higher,
> > then you have to stop dirname at \\host\share and never split these
> > paths.
> > 
> > One problem you have with the latter approach is this: What do you do
> > with input paths of the form "\\host"?  In other words, what do you
> > return if the input is invalid?  In theory it should stay unchanged,
> > so dirname should just return the invalid path verbatim.
> 
> The current algorithm has a concept about 'volume prefix'. This path is
> taking as a sole prefix and an empty component, and is absolute. Hence,
> `dirname()` returns the prefix with a backslash appended i.e. `\\host\`, and
> `basename()` returns `\`.

Hmm, ok.  But \\host\ is just as invalid as \\host...


Corinna


___
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: Reimplement `dirname()` and `basename()`

[Corinna Vinschen]

On Mar 28 19:18, LIU Hao wrote:
> 在 2023/3/28 10:49, LIU Hao 写道:
> > > According to Microsoft documentation about paths, which I linked
> > > yesterday, the `\\host\share` part
> > is the name of a volume, so I think only the CMD behavior is right:
> > `dirname()` should not remove `..` which would move to a different
> > volume. And here is the alternative patch.
> 
> I had some discussion with Corinna Vinschen about these implementation
> details: The behavior of Cygwin about `\\host` is emulated, so it looks like
> Explorer. Our conclusion is that `\\host\` without a share name is not a
> valid UNC path.

Just for the records, Cygwin implementes virtual directories for // and
//host.  You can enumerate locale SMB servers with `ls -l //', and
you can enumerate shares hosted by "host" by running `ls -l //host'.
Internally we use the WNet functions and `ls //' is just as slow and
spotty as the Explorer "Network' view...

> So far the question is all about whether `dirname()` is allowed to remove
> the shared name from a UNC path. I suspect not, mainly due to the following
> reasons:
> 
> 1. `\\host` is valid for Cygwin because of the aforementioned emulation. It is
>however not a valid path for mingw-w64, and `dirname()` should not provide
>invalid paths.
> 2. As its consequence, `basename("\\host\share")` would yield `share` as if
>it was a directory. It is not.
> 3. It would be confusing that `dirname("\\host\share")` and 
> `"\\host\share\.."`
>do not designate the same location. [Note in the latest patch
>`basename("\\host\share")` yields `"\"`.]

My POV is this:

Either you allow to split the *entire* share path, so you can use
dirname/basename to split \\host\share into the host and the share path,
and also to split \\ and host.  That would allow to inspect the host and
share components using the same functions.

Or you value the fact that the resulting path is still valid higher,
then you have to stop dirname at \\host\share and never split these
paths.

One problem you have with the latter approach is this: What do you do
with input paths of the form "\\host"?  In other words, what do you
return if the input is invalid?  In theory it should stay unchanged,
so dirname should just return the invalid path verbatim.


Corinna


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default library order breaks backward compatibility with older versions of Windows

[Corinna Vinschen]

On Apr 28 17:34, Corinna Vinschen wrote:
> Hi Christian,
> 
> On Apr 28 17:24, Christian Franke wrote:
> > For some unknown reason, certain functions from advapi32.dll are now also
> > exported by the kernel32.dll of recent Windows versions. To provide backward
> > compatibility, -ladvapi32 must occur before -lkernel32 in the linker
> > command, but this is not the case by default:
> > [...]
> > A modified specs file with '... -ladvapi32 -lkernel32' in the libgcc rule
> > would fix the problem.
> > 
> > I could add a report to gcc bugzilla if desired.
> 
> That would be great, especially given both platforms are affected.

But then again, this seems to be a bug in the w32api import libs,
rather than a problem with the toolchain, no?


Corinna


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default library order breaks backward compatibility with older versions of Windows

[Corinna Vinschen]

Hi Christian,

On Apr 28 17:24, Christian Franke wrote:
> For some unknown reason, certain functions from advapi32.dll are now also
> exported by the kernel32.dll of recent Windows versions. To provide backward
> compatibility, -ladvapi32 must occur before -lkernel32 in the linker
> command, but this is not the case by default:
> [...]
> A modified specs file with '... -ladvapi32 -lkernel32' in the libgcc rule
> would fix the problem.
> 
> I could add a report to gcc bugzilla if desired.

That would be great, especially given both platforms are affected.


Thanks,
Corinna


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Add status and error codes for case sensitive dirs

[Corinna Vinschen]

Removing the "case-sensitive" flag from a directory containing files
which only differ by case (e.g.  "foo" and "Foo") is refused with the
status code STATUS_CASE_DIFFERING_NAMES_IN_DIR.  This patch adds the
status code and it's Windows subsystem error code.

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/include/ntstatus.h | 1 +
 mingw-w64-headers/include/winerror.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mingw-w64-headers/include/ntstatus.h 
b/mingw-w64-headers/include/ntstatus.h
index eace03e9f809..c511d2e9c890 100644
--- a/mingw-w64-headers/include/ntstatus.h
+++ b/mingw-w64-headers/include/ntstatus.h
@@ -1002,6 +1002,7 @@
 #define STATUS_SYSTEM_DEVICE_NOT_FOUND ((NTSTATUS)0xC452)
 #define STATUS_RESTART_BOOT_APPLICATION ((NTSTATUS)0xC453)
 #define STATUS_INSUFFICIENT_NVRAM_RESOURCES ((NTSTATUS)0xC454)
+#define STATUS_CASE_DIFFERING_NAMES_IN_DIR ((NTSTATUS)0xC4B3)
 #define STATUS_INVALID_TASK_NAME ((NTSTATUS)0xC500)
 #define STATUS_INVALID_TASK_INDEX ((NTSTATUS)0xC501)
 #define STATUS_THREAD_ALREADY_IN_TASK ((NTSTATUS)0xC502)
diff --git a/mingw-w64-headers/include/winerror.h 
b/mingw-w64-headers/include/winerror.h
index 609172d1a637..e2ccfc75d53d 100755
--- a/mingw-w64-headers/include/winerror.h
+++ b/mingw-w64-headers/include/winerror.h
@@ -247,6 +247,7 @@
 #define ERROR_OBJECT_NOT_EXTERNALLY_BACKED __MSABI_LONG(342)
 #define ERROR_EXTERNAL_BACKING_PROVIDER_UNKNOWN __MSABI_LONG(343)
 #define ERROR_COMPRESSION_NOT_BENEFICIAL __MSABI_LONG(344)
+#define ERROR_CASE_DIFFERING_NAMES_IN_DIR __MSABI_LONG(424)
 #define ERROR_INVALID_ADDRESS __MSABI_LONG(487)
 #define ERROR_ARITHMETIC_OVERFLOW __MSABI_LONG(534)
 #define ERROR_PIPE_CONNECTED __MSABI_LONG(535)
-- 
2.31.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2 v2] headers: add missing PARTITION_INFORMATION_MBR member

[Corinna Vinschen]

From: Corinna Vinschen 

Per 
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_mbr
the PARTITION_INFORMATION_MBR struct contains a GUID member called
PartitionId.  Add it.

v2: add NTDDI_WINBLUE feature test

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/include/ntdddisk.h | 3 +++
 mingw-w64-headers/include/winioctl.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/mingw-w64-headers/include/ntdddisk.h 
b/mingw-w64-headers/include/ntdddisk.h
index 90e4e98725f9..ed032370383e 100644
--- a/mingw-w64-headers/include/ntdddisk.h
+++ b/mingw-w64-headers/include/ntdddisk.h
@@ -366,6 +366,9 @@ typedef struct _PARTITION_INFORMATION_MBR {
   BOOLEAN  BootIndicator;
   BOOLEAN  RecognizedPartition;
   ULONG  HiddenSectors;
+#if NTDDI_VERSION > NTDDI_WINBLUE
+  GUID PartitionId;
+#endif
 } PARTITION_INFORMATION_MBR, *PPARTITION_INFORMATION_MBR;
 
 typedef struct _PARTITION_INFORMATION_EX {
diff --git a/mingw-w64-headers/include/winioctl.h 
b/mingw-w64-headers/include/winioctl.h
index 9c8f57ee66a9..68982c76dba3 100644
--- a/mingw-w64-headers/include/winioctl.h
+++ b/mingw-w64-headers/include/winioctl.h
@@ -705,6 +705,9 @@ typedef struct _PARTITION_INFORMATION_MBR {
   BOOLEAN BootIndicator;
   BOOLEAN RecognizedPartition;
   DWORD HiddenSectors;
+#if NTDDI_VERSION > NTDDI_WINBLUE
+  GUID PartitionId;
+#endif
 } PARTITION_INFORMATION_MBR,*PPARTITION_INFORMATION_MBR;
 
 typedef SET_PARTITION_INFORMATION SET_PARTITION_INFORMATION_MBR;
-- 
2.31.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/2 v2] headers: add missing PARTITION_INFORMATION_EX member

[Corinna Vinschen]

From: Corinna Vinschen 

Per 
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_ex
the PARTITION_INFORMATION_EX struct contains a BOOLEAN member called
IsServicePartition.  Add it.

v2: add NTDDI_WIN10_RS3 feature test

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/include/ntdddisk.h | 3 +++
 mingw-w64-headers/include/winioctl.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/mingw-w64-headers/include/ntdddisk.h 
b/mingw-w64-headers/include/ntdddisk.h
index fa0b7865e2fe..90e4e98725f9 100644
--- a/mingw-w64-headers/include/ntdddisk.h
+++ b/mingw-w64-headers/include/ntdddisk.h
@@ -374,6 +374,9 @@ typedef struct _PARTITION_INFORMATION_EX {
   LARGE_INTEGER  PartitionLength;
   ULONG  PartitionNumber;
   BOOLEAN  RewritePartition;
+#if NTDDI_VERSION >= NTDDI_WIN10_RS3
+  BOOLEAN  IsServicePartition;
+#endif
   _ANONYMOUS_UNION union {
 PARTITION_INFORMATION_MBR  Mbr;
 PARTITION_INFORMATION_GPT  Gpt;
diff --git a/mingw-w64-headers/include/winioctl.h 
b/mingw-w64-headers/include/winioctl.h
index 76664e577d7a..9c8f57ee66a9 100644
--- a/mingw-w64-headers/include/winioctl.h
+++ b/mingw-w64-headers/include/winioctl.h
@@ -745,6 +745,9 @@ typedef struct _PARTITION_INFORMATION_EX {
   LARGE_INTEGER PartitionLength;
   DWORD PartitionNumber;
   BOOLEAN RewritePartition;
+#if NTDDI_VERSION >= NTDDI_WIN10_RS3
+  BOOLEAN  IsServicePartition;
+#endif
   __C89_NAMELESS union {
 PARTITION_INFORMATION_MBR Mbr;
 PARTITION_INFORMATION_GPT Gpt;
-- 
2.31.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 0/2 v2] headers: add two members missing in partition info

[Corinna Vinschen]

From: Corinna Vinschen 

MSDN documents struct members in partition info not defined in the
mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.

v2: Add feature tests

Corinna Vinschen (2):
  headers: add missing PARTITION_INFORMATION_EX member
  headers: add missing PARTITION_INFORMATION_MBR member

 mingw-w64-headers/include/ntdddisk.h | 2 ++
 mingw-w64-headers/include/winioctl.h | 2 ++
 2 files changed, 4 insertions(+)

-- 
2.31.1



___
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 0/2] headers: add two members missing in partition info

[Corinna Vinschen]

On Aug 20 15:46, Ozkan Sezer wrote:
> On 8/20/21, Corinna Vinschen  wrote:
> > From: Corinna Vinschen 
> >
> > MSDN documents struct members in partition info not defined in the
> > mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.
> >
> > Corinna Vinschen (2):
> >   headers: add missing PARTITION_INFORMATION_EX member
> >   headers: add missing PARTITION_INFORMATION_MBR member
> 
> Those members do not exist in win7 versions of ddk headers.
> Are they added for newer windows versions support?

The documentation doesn't mention that, but I guess they have
been added in W10 or so.


Corinna


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 0/2] headers: add two members missing in partition info

[Corinna Vinschen]

From: Corinna Vinschen 

MSDN documents struct members in partition info not defined in the
mingw-w64 headers ntdddisk.h and winioctl.h.  Add them.

Corinna Vinschen (2):
  headers: add missing PARTITION_INFORMATION_EX member
  headers: add missing PARTITION_INFORMATION_MBR member

 mingw-w64-headers/include/ntdddisk.h | 2 ++
 mingw-w64-headers/include/winioctl.h | 2 ++
 2 files changed, 4 insertions(+)

-- 
2.31.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/2] headers: add missing PARTITION_INFORMATION_EX member

[Corinna Vinschen]

From: Corinna Vinschen 

Per 
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_ex
the PARTITION_INFORMATION_EX struct contains a BOOLEAN member called
IsServicePartition.  Add it.

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/include/ntdddisk.h | 1 +
 mingw-w64-headers/include/winioctl.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mingw-w64-headers/include/ntdddisk.h 
b/mingw-w64-headers/include/ntdddisk.h
index fa0b7865e2fe..7e42af4a7a18 100644
--- a/mingw-w64-headers/include/ntdddisk.h
+++ b/mingw-w64-headers/include/ntdddisk.h
@@ -374,6 +374,7 @@ typedef struct _PARTITION_INFORMATION_EX {
   LARGE_INTEGER  PartitionLength;
   ULONG  PartitionNumber;
   BOOLEAN  RewritePartition;
+  BOOLEAN  IsServicePartition;
   _ANONYMOUS_UNION union {
 PARTITION_INFORMATION_MBR  Mbr;
 PARTITION_INFORMATION_GPT  Gpt;
diff --git a/mingw-w64-headers/include/winioctl.h 
b/mingw-w64-headers/include/winioctl.h
index 76664e577d7a..b64afc5e890a 100644
--- a/mingw-w64-headers/include/winioctl.h
+++ b/mingw-w64-headers/include/winioctl.h
@@ -745,6 +745,7 @@ typedef struct _PARTITION_INFORMATION_EX {
   LARGE_INTEGER PartitionLength;
   DWORD PartitionNumber;
   BOOLEAN RewritePartition;
+  BOOLEAN  IsServicePartition;
   __C89_NAMELESS union {
 PARTITION_INFORMATION_MBR Mbr;
 PARTITION_INFORMATION_GPT Gpt;
-- 
2.31.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] headers: add missing PARTITION_INFORMATION_MBR member

[Corinna Vinschen]

From: Corinna Vinschen 

Per 
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_mbr
the PARTITION_INFORMATION_MBR struct contains a GUID member called
PartitionId.  Add it.

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/include/ntdddisk.h | 1 +
 mingw-w64-headers/include/winioctl.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mingw-w64-headers/include/ntdddisk.h 
b/mingw-w64-headers/include/ntdddisk.h
index 7e42af4a7a18..78c09ddf216c 100644
--- a/mingw-w64-headers/include/ntdddisk.h
+++ b/mingw-w64-headers/include/ntdddisk.h
@@ -366,6 +366,7 @@ typedef struct _PARTITION_INFORMATION_MBR {
   BOOLEAN  BootIndicator;
   BOOLEAN  RecognizedPartition;
   ULONG  HiddenSectors;
+  GUID PartitionId;
 } PARTITION_INFORMATION_MBR, *PPARTITION_INFORMATION_MBR;
 
 typedef struct _PARTITION_INFORMATION_EX {
diff --git a/mingw-w64-headers/include/winioctl.h 
b/mingw-w64-headers/include/winioctl.h
index b64afc5e890a..6aa89bf50e35 100644
--- a/mingw-w64-headers/include/winioctl.h
+++ b/mingw-w64-headers/include/winioctl.h
@@ -705,6 +705,7 @@ typedef struct _PARTITION_INFORMATION_MBR {
   BOOLEAN BootIndicator;
   BOOLEAN RecognizedPartition;
   DWORD HiddenSectors;
+  GUID PartitionId;
 } PARTITION_INFORMATION_MBR,*PPARTITION_INFORMATION_MBR;
 
 typedef SET_PARTITION_INFORMATION SET_PARTITION_INFORMATION_MBR;
-- 
2.31.1



___
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: Increase precision of gettimeofday() if possible.

[Corinna Vinschen]

On Apr 26 20:00, Christian Franke wrote:
> System calls and resolutions of C++11 clocks:
> 
>    Mingw-w64 MSVC16  Cygwin
> system_clock::now()   1    2   2
> steady_clock::now()   1    3   3
> high_resolution_clock::now()  1    3   3
> 
> where
> 1: GetSystemTimeAsFileTime: >15ms to 1ms (unpredictable)
> 2: GetSystemTimePreciseAsFileTime: <1us
> 3: QueryPerformanceCounter: <500ns

Not quite.  Newer Windows versions support better alternatives compared
to QueryPerformanceCounter.  Thus on newer systems Cygwin uses

  QueryUnbiasedInterruptTimePrecise for CLOCK_MONOTONIC{_RAW}
  QueryUnbiasedInterruptTimefor CLOCK_MONOTONIC_COARSE
  QueryInterruptTimePrecise for CLOCK_BOOTTIME{_ALARM}

and, of course

  GetSystemTimePreciseAsFileTimefor CLOCK_REALTIME
  GetSystemTimeAsFileTime   for CLOCK_REALTIME_COARSE

Apart from style issues, I vote for using GetSystemTimePreciseAsFileTime
for CLOCK_REALTIME and only fall back to GetSystemTimeAsFileTime for
CLOCK_REALTIME_COARSE or if the OS doesn't support the precise call.

Please do keep in mind that there are assumptions of a minimum 
precision of gettimeofday in the wild, which are not really in our
hands.  If we can avoid upstream code to #ifdef time computations
for Mingw separately, rather than just using gettimeofday on all
supported platforms, it's certainly a win-win, isn't it?


Corinna



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH v2] SID_NAME_USE: add SidTypeLogonSession

[Corinna Vinschen]

This is a Windows 10 addition.  For reference, see
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ne-winnt-_sid_name_use

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/ddk/include/ddk/ntifs.h | 3 ++-
 mingw-w64-headers/include/winnt.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/ddk/include/ddk/ntifs.h 
b/mingw-w64-headers/ddk/include/ddk/ntifs.h
index 01ab6c9def09..e2dc95947a0b 100644
--- a/mingw-w64-headers/ddk/include/ddk/ntifs.h
+++ b/mingw-w64-headers/ddk/include/ddk/ntifs.h
@@ -94,7 +94,8 @@ typedef enum _SID_NAME_USE {
   SidTypeInvalid,
   SidTypeUnknown,
   SidTypeComputer,
-  SidTypeLabel
+  SidTypeLabel,
+  SidTypeLogonSession
 } SID_NAME_USE, *PSID_NAME_USE;
 
 typedef struct _SID_AND_ATTRIBUTES {
diff --git a/mingw-w64-headers/include/winnt.h 
b/mingw-w64-headers/include/winnt.h
index b5d84ef15c82..1bc0a7ab37d8 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -2943,7 +2943,7 @@ __buildmemorybarrier()
 #define SID_HASH_SIZE 32
 
 typedef enum _SID_NAME_USE {
-  SidTypeUser = 
1,SidTypeGroup,SidTypeDomain,SidTypeAlias,SidTypeWellKnownGroup,SidTypeDeletedAccount,SidTypeInvalid,SidTypeUnknown,SidTypeComputer,SidTypeLabel
+  SidTypeUser = 
1,SidTypeGroup,SidTypeDomain,SidTypeAlias,SidTypeWellKnownGroup,SidTypeDeletedAccount,SidTypeInvalid,SidTypeUnknown,SidTypeComputer,SidTypeLabel,SidTypeLogonSession
 } SID_NAME_USE,*PSID_NAME_USE;
 
 typedef struct _SID_AND_ATTRIBUTES {
-- 
2.14.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] SID_NAME_USE: add SidTypeLogonSession

[Corinna Vinschen]

This is a Windows 10 addition.  For reference, see
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ne-winnt-_sid_name_use

Signed-off-by: Corinna Vinschen 
---
 mingw-w64-headers/ddk/include/ddk/ntifs.h | 3 ++-
 mingw-w64-headers/include/winnt.h | 2 +-
 mingw-w64-tools/widl/include/winnt.h  | 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/mingw-w64-headers/ddk/include/ddk/ntifs.h 
b/mingw-w64-headers/ddk/include/ddk/ntifs.h
index 01ab6c9def09..e2dc95947a0b 100644
--- a/mingw-w64-headers/ddk/include/ddk/ntifs.h
+++ b/mingw-w64-headers/ddk/include/ddk/ntifs.h
@@ -94,7 +94,8 @@ typedef enum _SID_NAME_USE {
   SidTypeInvalid,
   SidTypeUnknown,
   SidTypeComputer,
-  SidTypeLabel
+  SidTypeLabel,
+  SidTypeLogonSession
 } SID_NAME_USE, *PSID_NAME_USE;
 
 typedef struct _SID_AND_ATTRIBUTES {
diff --git a/mingw-w64-headers/include/winnt.h 
b/mingw-w64-headers/include/winnt.h
index b5d84ef15c82..1bc0a7ab37d8 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -2943,7 +2943,7 @@ __buildmemorybarrier()
 #define SID_HASH_SIZE 32
 
 typedef enum _SID_NAME_USE {
-  SidTypeUser = 
1,SidTypeGroup,SidTypeDomain,SidTypeAlias,SidTypeWellKnownGroup,SidTypeDeletedAccount,SidTypeInvalid,SidTypeUnknown,SidTypeComputer,SidTypeLabel
+  SidTypeUser = 
1,SidTypeGroup,SidTypeDomain,SidTypeAlias,SidTypeWellKnownGroup,SidTypeDeletedAccount,SidTypeInvalid,SidTypeUnknown,SidTypeComputer,SidTypeLabel,SidTypeLogonSession
 } SID_NAME_USE,*PSID_NAME_USE;
 
 typedef struct _SID_AND_ATTRIBUTES {
diff --git a/mingw-w64-tools/widl/include/winnt.h 
b/mingw-w64-tools/widl/include/winnt.h
index a9d718a773c6..f8fbb52d669a 100644
--- a/mingw-w64-tools/widl/include/winnt.h
+++ b/mingw-w64-tools/widl/include/winnt.h
@@ -4718,7 +4718,8 @@ typedef enum tagSID_NAME_USE {
SidTypeWellKnownGroup,
SidTypeDeletedAccount,
SidTypeInvalid,
-   SidTypeUnknown
+   SidTypeUnknown,
+   SidTypeLogonSession
 } SID_NAME_USE,*PSID_NAME_USE;
 
 #define ACE_OBJECT_TYPE_PRESENT 0x1
-- 
2.14.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] [PATCH v3] Make isatty Cygwin-compatible

[Corinna Vinschen]

On Nov 14 05:00, Mihail Konev wrote:
> On Sun, Nov 13, 2016 at 09:44:49PM +0100, Corinna Vinschen wrote:
> > On Nov 14 00:31, Mihail Konev wrote:
> > 
> > I'm opposed to checking the pipes for *-msys-* additionally to
> > *-cygwin-* for no good reason.  You're adding just another test to the
> > checking code and potentially introduce hard to track down backward
> > incompatibilities.  There's really no gain for MSYS2 to rename the
> > pipes, except breaking interoperability, so hopefully this will never
> > happen anyway.
> > 
> Do you want MSYS to rename the pipes back?
> 
> https://github.com/Alexpux/MSYS2-packages/search?utf8=%E2%9C%93=PIPE_INTRO
> 
> Because of msys runtime 2.5.2-2, it is a necessity.

  This is really just renaming for no gain at all.  I do hope
this isn't just for the sake of "brand".  If it's about isolation, that
doesn't matter anyway since isolation is already performed by adding the
installation key to the name of such objects.


Corinna


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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 v3] Make isatty Cygwin-compatible

[Corinna Vinschen]

On Nov 14 00:31, Mihail Konev wrote:
> +/* Cygwin-compatible isatty.
> + *
> + * Cygwin pty is a specially-named named pipe.
> + * Fetch absolute device namespace path to fd (if any),
> + * and check it for the following pattern:
> + *
> + *   
> \Device\NamedPipe\(cygwin|msys)-[a-fA-F0-9]{16}-pty[0-9]{1,4}-(from-master|to-master|to-master-cyg)
> + *
> + * [a-fA-F0-9] is the cygwin installation key, 16 characters long.
> + * pty[0-9] is the pty name. Its index is of type int, but is safe to be 
> limited to 4 characters.
> + *
> + * */
> +
> +static int __cdecl isatty(int fd) {
> +  wchar_t const expect_dev[] = L"\\Device\\NamedPipe\\";
> +  wchar_t const expect_cyg[] = L"cygwin-";
> +  wchar_t const expect_msy[] = L"msys-";

I'm opposed to checking the pipes for *-msys-* additionally to
*-cygwin-* for no good reason.  You're adding just another test to the
checking code and potentially introduce hard to track down backward
incompatibilities.  There's really no gain for MSYS2 to rename the
pipes, except breaking interoperability, so hopefully this will never
happen anyway.


Corinna


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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 v5] Add include/iscygtty.c

[Corinna Vinschen]

On Nov 13 11:01, Corinna Vinschen wrote:
> On Nov 12 23:10, Ray Donnelly wrote:
> > MSYS2 is a software distribution with both (extremely) Cygwin-like and also
> > native Windows software, all (usually) launched from mintty.
> 
> MSYS2 is a slightly tweaked Cygwin DLL in the first place.
> 
> There are applications linked against it, thus using the POSIX
> emulation.  Those don't need this function at all.
> 
> And there are applications not linked against it, what we refer to as
> "native" applications.  Those would profit from this function.
> 
> But that's not the major point.  The major point is:
> 
>   2. Why include a non-standard API?  Why not provide this as isatty
>  function as a replacement for the system isatty?  I'd wager your
>  boots on this function going mostly unused, otherwise.
> 
> This would only (correctly) affect native applications, but then *all*
> of them would see mintty as a tty.

s/all of them/all of them using the isatty function/


Corinna


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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 v5] Add include/iscygtty.c

[Corinna Vinschen]

On Nov 12 23:10, Ray Donnelly wrote:
> MSYS2 is a software distribution with both (extremely) Cygwin-like and also
> native Windows software, all (usually) launched from mintty.

MSYS2 is a slightly tweaked Cygwin DLL in the first place.

There are applications linked against it, thus using the POSIX
emulation.  Those don't need this function at all.

And there are applications not linked against it, what we refer to as
"native" applications.  Those would profit from this function.

But that's not the major point.  The major point is:

  2. Why include a non-standard API?  Why not provide this as isatty
 function as a replacement for the system isatty?  I'd wager your
 boots on this function going mostly unused, otherwise.

This would only (correctly) affect native applications, but then *all*
of them would see mintty as a tty.


Corinna

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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 v5] Add include/iscygtty.c

[Corinna Vinschen]

On Nov 12 14:52, Ray Donnelly wrote:
> On Nov 12, 2016 1:30 PM, "Corinna Vinschen" <vinsc...@redhat.com> wrote:
> >
> > On Nov 12 12:27, JonY wrote:
> > > On 11/12/2016 11:57, Mihail Konev wrote:
> > > > Applications now could call iscygtty(STDIN_FILENO)
> > > > in order to detect whether they are running from
> > > > Cygwin/MSys terminal.
> > > >
> > > > Without that, they have no choice but to think that
> > > > stdin is redirected from a named pipe.
> > > >
> > > > Signed-off-by: Mihail Konev <k@ya.ru>
> > > > Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> > >
> > > I don't really have any big objections other than on style.
> >
> > 1. This should be *strictly* non-Cygwin/non-MSYS.  Only native Windows
> >applications will have a problem to recognize Cygwin ptys, thus this
> >functions makes no sense at all for applications linked against
> >Cygwin or MSYS.
> >
> > 2. Why include a non-standard API?  Why not provide this as isatty
> >function as a replacement for the system isatty?  I'd wager your
> >boots on this function going mostly unused, otherwise.
> 
> MSYS2 will use it extensively.

If MSYS2 uses it there's something wrong.  MSYS2 is Cygwin, so it
doesn't need this function at all;  It has everything already builtin.

Again:  Only non-Cygwin applications will need this function.


Corinna


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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 v5] Add include/iscygtty.c

[Corinna Vinschen]

On Nov 12 12:27, JonY wrote:
> On 11/12/2016 11:57, Mihail Konev wrote:
> > Applications now could call iscygtty(STDIN_FILENO)
> > in order to detect whether they are running from
> > Cygwin/MSys terminal.
> > 
> > Without that, they have no choice but to think that
> > stdin is redirected from a named pipe.
> > 
> > Signed-off-by: Mihail Konev 
> > Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> 
> I don't really have any big objections other than on style.

1. This should be *strictly* non-Cygwin/non-MSYS.  Only native Windows
   applications will have a problem to recognize Cygwin ptys, thus this
   functions makes no sense at all for applications linked against
   Cygwin or MSYS.

2. Why include a non-standard API?  Why not provide this as isatty
   function as a replacement for the system isatty?  I'd wager your
   boots on this function going mostly unused, otherwise.


Corinna


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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] Change check for _WIN64 to check for __x86_64__ in assembler

[Corinna Vinschen]

Hi Kai,

On Aug 22 17:34, Kai Tietz wrote:
> Hi Corinna,
> 
> 2016-08-22 17:23 GMT+02:00 Corinna Vinschen <vinsc...@redhat.com>:
> > Lots of assembler files in the math subdir check for _WIN64 when they
> > actually mean to check for the x86_64 target CPU, rather than the target
> > OS.  This patch fixes it.  This helps Cygwin in the first place because
> > __x86_64__ is defined in both toolchains, while _WIN64 is only defined
> > on Mingw-w64 for x86_64.
> >
> >
> > Is that ok to apply?
> 
> Patch is ok. Please apply.

Done, thanks!

> PS: Does this mean you use these math functions on cywin?

Not all of them but, yes, Cygwin does.  The problem was that newlib only
provided float and double, but no long double, so Cygwin is using the
long double functions from Mingw-w64 and a few others for simplicity.

Btw., we had to apply two Cygwin-specific patches to the math functions.
I don't know if that's something we should share, but please have a
look.  I'm curious if that's stuff which should go upstream one way or
the other:

https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=929be80
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=71df3bf


Thanks,
Corinna

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Change check for _WIN64 to check for __x86_64__ in assembler

[Corinna Vinschen]

Hi folks,


Lots of assembler files in the math subdir check for _WIN64 when they
actually mean to check for the x86_64 target CPU, rather than the target
OS.  This patch fixes it.  This helps Cygwin in the first place because
__x86_64__ is defined in both toolchains, while _WIN64 is only defined
on Mingw-w64 for x86_64.


Is that ok to apply?


Thanks,
Corinna
From 40f03bb9ebc8c43235871329466b1b8a5794a27b Mon Sep 17 00:00:00 2001
From: Corinna Vinschen <vinsc...@redhat.com>
Date: Mon, 22 Aug 2016 14:30:39 +0200
Subject: [PATCH] Change check for _WIN64 to check for __x86_64__ in assembler
 files

Lots of assembler files in the math subdir check for _WIN64 when they
actually mean to check for the x86_64 target CPU, rather than the target
OS.  This patch fixes it.  This helps Cygwin in the first place because
__x86_64__ is defined in both toolchains, while _WIN64 is only defined
on Mingw-w64 for x86_64.

Signed-off-by: Corinna Vinschen <vinsc...@redhat.com>
---
 mingw-w64-crt/math/_chgsignl.S | 2 +-
 mingw-w64-crt/math/ceil.S  | 2 +-
 mingw-w64-crt/math/ceilf.S | 2 +-
 mingw-w64-crt/math/ceill.S | 2 +-
 mingw-w64-crt/math/cephes_mconf.h  | 2 +-
 mingw-w64-crt/math/copysignl.S | 2 +-
 mingw-w64-crt/math/cosl_internal.S | 4 ++--
 mingw-w64-crt/math/exp.def.h   | 2 +-
 mingw-w64-crt/math/exp2.S  | 4 ++--
 mingw-w64-crt/math/exp2f.S | 4 ++--
 mingw-w64-crt/math/exp2l.S | 4 ++--
 mingw-w64-crt/math/floor.S | 2 +-
 mingw-w64-crt/math/floorf.S| 2 +-
 mingw-w64-crt/math/floorl.S| 2 +-
 mingw-w64-crt/math/fma.S   | 2 +-
 mingw-w64-crt/math/fmaf.S  | 2 +-
 mingw-w64-crt/math/frexpl.S| 4 ++--
 mingw-w64-crt/math/ilogb.S | 4 ++--
 mingw-w64-crt/math/ilogbf.S| 4 ++--
 mingw-w64-crt/math/ilogbl.S| 4 ++--
 mingw-w64-crt/math/internal_logl.S | 4 ++--
 mingw-w64-crt/math/log10l.S| 6 +++---
 mingw-w64-crt/math/log1p.S | 4 ++--
 mingw-w64-crt/math/log1pf.S| 4 ++--
 mingw-w64-crt/math/log1pl.S| 4 ++--
 mingw-w64-crt/math/log2.S  | 4 ++--
 mingw-w64-crt/math/log2f.S | 4 ++--
 mingw-w64-crt/math/log2l.S | 4 ++--
 mingw-w64-crt/math/nearbyint.S | 2 +-
 mingw-w64-crt/math/nearbyintf.S| 2 +-
 mingw-w64-crt/math/nearbyintl.S| 2 +-
 mingw-w64-crt/math/pow.def.h   | 2 +-
 mingw-w64-crt/math/remainder.S | 4 ++--
 mingw-w64-crt/math/remainderf.S| 4 ++--
 mingw-w64-crt/math/remainderl.S| 4 ++--
 mingw-w64-crt/math/remquo.S| 4 ++--
 mingw-w64-crt/math/remquof.S   | 4 ++--
 mingw-w64-crt/math/remquol.S   | 4 ++--
 mingw-w64-crt/math/scalbn.S| 4 ++--
 mingw-w64-crt/math/scalbnf.S   | 4 ++--
 mingw-w64-crt/math/scalbnl.S   | 4 ++--
 mingw-w64-crt/math/sinl_internal.S | 4 ++--
 mingw-w64-crt/math/tanl.S  | 4 ++--
 mingw-w64-crt/math/trunc.S | 2 +-
 mingw-w64-crt/math/truncf.S| 2 +-
 45 files changed, 73 insertions(+), 73 deletions(-)

diff --git a/mingw-w64-crt/math/_chgsignl.S b/mingw-w64-crt/math/_chgsignl.S
index 65c4cee..3876465 100644
--- a/mingw-w64-crt/math/_chgsignl.S
+++ b/mingw-w64-crt/math/_chgsignl.S
@@ -20,7 +20,7 @@
 
.file   "_chgignl.S"
.text
-#ifdef _WIN64
+#ifdef __x86_64__
.align 8
 #else
.align 4
diff --git a/mingw-w64-crt/math/ceil.S b/mingw-w64-crt/math/ceil.S
index 2ce21dd..636df1e 100644
--- a/mingw-w64-crt/math/ceil.S
+++ b/mingw-w64-crt/math/ceil.S
@@ -10,7 +10,7 @@
.align 4
.globl __MINGW_USYMBOL(ceil)
.def__MINGW_USYMBOL(ceil);  .scl2;  .type   32; .endef
-#ifdef _WIN64
+#ifdef __x86_64__
.seh_proc   __MINGW_USYMBOL(ceil)
 #endif
 
diff --git a/mingw-w64-crt/math/ceilf.S b/mingw-w64-crt/math/ceilf.S
index c1202e0..605c7bf 100644
--- a/mingw-w64-crt/math/ceilf.S
+++ b/mingw-w64-crt/math/ceilf.S
@@ -10,7 +10,7 @@
.align 4
.globl __MINGW_USYMBOL(ceilf)
.def__MINGW_USYMBOL(ceilf); .scl2;  .type   32; .endef
-#ifdef _WIN64
+#ifdef __x86_64__
.seh_proc   __MINGW_USYMBOL(ceilf)
 #endif
 
diff --git a/mingw-w64-crt/math/ceill.S b/mingw-w64-crt/math/ceill.S
index 9804004..61d6199 100644
--- a/mingw-w64-crt/math/ceill.S
+++ b/mingw-w64-crt/math/ceill.S
@@ -7,7 +7,7 @@
 
.file   "ceill.S"
.text
-#ifdef _WIN64
+#ifdef __x86_64__
.align 8
 #else
.align 4
diff --git a/mingw-w64-crt/math/cephes_mconf.h 
b/mingw-w64-crt/math/cephes_mconf.h
index 25ab33e..832fae0 100644
--- a/mingw-w64-crt/math/cephes_mconf.h
+++ b/mingw-w64-crt/math/cephes_mconf.h
@@ -11,7 +11,7 @@
 #define VOLATILE
 #define mtherr(fname, code)
 #define XPD 0,
-#ifdef _WIN64
+#ifdef __x86_64__
 #define XPD_SHORT 0, 0,
 #define XPD_LONG 0,
 #else
diff --git a/mingw-w64-crt/math/copysignl.S b/mingw-w64-crt/math/copysignl.S
index 0becf53..1ee4a45 100644
--- a/mingw-w64-crt/math/copysignl.S
+++ b/mingw-w

Re: [Mingw-w64-public] [PATCH] ws2tcpip.h: Define AI_DISABLE_IDN_ENCODING

[Corinna Vinschen]

On Mar 15 12:38, Kai Tietz wrote:
> Hi Corinna,
> 
> patch is ok.  Sorry for the delay looking into it.

No worries, I should have sent this patch already long ago.
Patch applied.


Thanks,
Corinna


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] ws2tcpip.h: Define AI_DISABLE_IDN_ENCODING

[Corinna Vinschen]

Starting with Windows 8, the getaddrinfo family of functions automatically
convers IDNs using punycode.  To allw switching this off, Windows 8
introduces the AI_DISABLE_IDN_ENCODING flag.

The value is documented in MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms737529%28v=vs.85%29.aspx

Signed-off-by: Corinna Vinschen <vinsc...@redhat.com>
---
 mingw-w64-headers/include/ws2tcpip.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mingw-w64-headers/include/ws2tcpip.h 
b/mingw-w64-headers/include/ws2tcpip.h
index ae940b0..c530d57 100644
--- a/mingw-w64-headers/include/ws2tcpip.h
+++ b/mingw-w64-headers/include/ws2tcpip.h
@@ -221,6 +221,9 @@ typedef ADDRINFOA ADDRINFO,*LPADDRINFO;
 #define AI_FQDN 0x0002
 #define AI_FILESERVER   0x0004
 #endif
+#if (_WIN32_WINNT >= 0x0602)
+#define AI_DISABLE_IDN_ENCODING 0x0008
+#endif
 
 #ifdef __cplusplus
 extern "C" {
-- 
2.5.0


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
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 1/2] kernel32.def: Export PrefetchVirtualMemory on non-ARM platforms

[Corinna Vinschen]

On Aug 25 14:54, Jacek Caban wrote:
 The patch looks good to me.
 
 Thanks,
 Jacek
 

Commited.


Thanks,
Corinna


pgpZ05TR9Rmqf.pgp
Description: PGP signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] lib32/kernel32.def: Fix PowerSetRequest copy/paste

[Corinna Vinschen]

The definition of PowerSetRequest is missing in lib32/kernel32.def,
while there's a PostQueuedCompletionStatus in its place.  This looks
like a copy/paste bug.  Fixed with this patch.

Signed-off-by: Corinna Vinschen vinsc...@redhat.com
---
 mingw-w64-crt/lib32/kernel32.def | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mingw-w64-crt/lib32/kernel32.def b/mingw-w64-crt/lib32/kernel32.def
index a113650..d4d4141 100644
--- a/mingw-w64-crt/lib32/kernel32.def
+++ b/mingw-w64-crt/lib32/kernel32.def
@@ -900,7 +900,7 @@ PeekNamedPipe@24
 PostQueuedCompletionStatus@16
 PowerClearRequest@8
 PowerCreateRequest@4
-PostQueuedCompletionStatus@16
+PowerSetRequest@8
 PrefetchVirtualMemory@16
 PrepareTape@12
 PrivCopyFileExW@24
-- 
2.1.0


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Definition of __CRT_INLINE breaks non-opimized builds

[Corinna Vinschen]

Ping?


Thanks,
Corinna

On Jul  6 16:51, Corinna Vinschen wrote:
 On Jul  6 12:27, Corinna Vinschen wrote:
  Hi,
  
  
  while working on Cygwin's new sigaltstack implementation, I wrote
  a testcase which I intended to share with my main tester.  Since
  we're trying to debug, we build without optimization.  Now, this
  is looking closely at what happens to the stack, so I need access
  to the TEB.  Here's what happens:
  
$ cat foo.c
#include windows.h
  
int
main ()
{
  MEMORY_BASIC_INFORMATION m;
  NT_TIB *tib = (NT_TIB *) NtCurrentTeb ();
  VirtualQuery (tib, m, sizeof m);
}
$ gcc -g -O foo.c -o foo
$ gcc -g foo.c -o foo
/tmp/ccnnAEl3.o: In function `main':
/home/corinna/foo.c:7: undefined reference to `NtCurrentTeb'
collect2: error: ld returned 1 exit status
  
  There's no way around that, except for builindg with optimization, which
  is often not prudent when debugging.
  
  In winnt.h, NtCurrentTeb is using __CRT_INLINE which, depending on C
  standard, expandes into
  
extern inline __attribute__((__gnu_inline__))
  
  or
  
extern __inline__
  
  However, that's not sufficient for NtCurrentTeb (nor, fwiw,
  GetCurrentFiber() etc.) since they are not backed by non-inlined
  versions.  Linking against ntdll doesn't help.
  
  So, shouldn't these inline functions use the __always_inline__
  attribute?  Or, maybe better, shouldn't __CRT_INLINE use the
  __always_inline__ attribute when built on GCC?
 
 Btw., this problem seems to exist on 32 bit x86.  The x86_64
 code uses FORCEINLINE which apparently inlines even without
 optimization.
 
 
 Corinna


pgpnI2m0V_pkm.pgp
Description: PGP signature
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
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] netioapi.h: Include ws2ipdef.h.

[Corinna Vinschen]

Hi guys,

On Oct 15 20:57, Kai Tietz wrote:
 Patch is ok.  Please go ahead and apply.
 
 Thanks,
 Kai
 
 2014-10-15 20:14 GMT+02:00 Jacek Caban ja...@codeweavers.com:
  For SOCKADDR_INET.
 
  ---
   mingw-w64-headers/include/netioapi.h | 1 +
   1 file changed, 1 insertion(+)

This patch breaks Cygwin applications using the IP Helper API.
iphlpapi.h includes netioapi.h which now includes ws2ipdef.h.  See
https://cygwin.com/ml/cygwin/2014-12/msg00198.html for a description.
Typically we don't want to include ws2ipdef.h and winsock2.h from Cygwin
applications becasue Winsock sockets and their definitions collide with
Cygwin POSIX sockets and their definitions.  The IP helper API needs to
be separate.

Is it ok to simply revert the patch for Cygwin:

diff --git a/mingw-w64-headers/include/netioapi.h 
b/mingw-w64-headers/include/netioapi.h
index 9e7f67d..164f972 100644
--- a/mingw-w64-headers/include/netioapi.h
+++ b/mingw-w64-headers/include/netioapi.h
@@ -7,7 +7,9 @@
 #define _INC_NETIOAPI
 
 #include ws2def.h
+#ifndef __CYGWIN__
 #include ws2ipdef.h
+#endif
 #include iprtrmib.h
 #include ifdef.h
 #include ntddndis.h


Thanks,
Corinna


pgpsiDHGYUdB4.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
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] netioapi.h: Include ws2ipdef.h.

[Corinna Vinschen]

Hi Jacek,

On Dec 15 12:06, Jacek Caban wrote:
 Hi Corinna,
 
 On 12/15/14 11:59, Corinna Vinschen wrote:
  Hi guys,
 
  On Oct 15 20:57, Kai Tietz wrote:
  Patch is ok.  Please go ahead and apply.
 
  Thanks,
  Kai
 
  2014-10-15 20:14 GMT+02:00 Jacek Caban ja...@codeweavers.com:
  For SOCKADDR_INET.
 
  ---
   mingw-w64-headers/include/netioapi.h | 1 +
   1 file changed, 1 insertion(+)
  This patch breaks Cygwin applications using the IP Helper API.
  iphlpapi.h includes netioapi.h which now includes ws2ipdef.h.  See
  https://cygwin.com/ml/cygwin/2014-12/msg00198.html for a description.
  Typically we don't want to include ws2ipdef.h and winsock2.h from Cygwin
  applications becasue Winsock sockets and their definitions collide with
  Cygwin POSIX sockets and their definitions.  The IP helper API needs to
  be separate.
 
  Is it ok to simply revert the patch for Cygwin:
 
 The patch is fine with me. However, to not have similar problems in the
 future, maybe making problematic headers no-op on Cygwin would be a
 better solution than avoiding including them?

I'm not sure.  For historical reasons, Cygwin applications can still opt
for using Winsock sockets instead of Cygwin sockets.  I'm not sure how
much sense is in there, but the combination of various macros (like the
dreaded __USE_W32_SOCKETS) is a bit fragile and I wouldn't want to break
that.  Also, typically this only affects Winsock headers.  With other
Windows headers we typically don't have collision problems(*).


Thanks,
Corinna


(*) There's a type collision with the GNU regex implementation but
it's pretty simple to workaround and the code using it usually
doesn't include Windows headers.


pgpkFE8dfaidr.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

[Corinna Vinschen]

On Dec  8 20:27, Alexpux wrote:
  8 дек. 2014 г., в 17:50, Corinna Vinschen  написал(а):
  On Dec  8 15:12, Alexpux wrote:
  8 дек. 2014 г., в 14:27, Corinna Vinschen  написал(а):
  On Dec  8 14:01, Alexpux wrote:
  Will update sf.net http://sf.net/ repo today.
  
  Ok.
  
  Done.
  
  And this is only for Cygwin.  The situation of the other upstream
  packages isn't better.  About half of the binary packages are younger
  than 6 month, while the latest source archives have been updated
  2014-06-11.
  
  You're violating the GPL again in a pretty big style.  Yes, not all of
  the affected packages are GPLed, but a lot are.  What is so complicated
  to keep the sources up to date with the binary packages?
  
  I’m provide git repository with build scripts and patches that applies 
  to sources:
  For mingw:
  https://github.com/Alexpux/MINGW-packages
  
  For msys2:
  https://github.com/Alexpux/MSYS2-packages 
  https://github.com/Alexpux/MSYS2-packages
  
  In how far does that alleviate the problem of the GPL breach?
  
  No problem, will upload sources soon too. Problem just in
  bandwidth/limited time for it.
  
  I'm suffering limited bandwidth, too.  I workaround that by always
  uploading source and binary package at once, so I'm never falling back.
 
 All sources uploaded:
 https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


pgpA85r2mGYiP.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] MSYS2 is violating the GPL again

[Corinna Vinschen]

Hi,

I just had a look on the MSYS2 pages at sourceforge.  It turned out that
the Cygwin sources provided on sourceforge,

http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources/msys2-runtime-2.0.15816.7257e97-1.src.tar.gz/download

are very old, from 2014-02-02, while the latest binary packages, for
instance

http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/msys2-runtime-2.0.16430.e868fe8-1-x86_64.pkg.tar.xz/download

corresponds to the latest Cygwin source code from 2014-12-06.

The corresponding source repository at

http://sourceforge.net/p/msys2/code/ci/master/tree/

is even older, with the latest sources from late 2013.

And this is only for Cygwin.  The situation of the other upstream
packages isn't better.  About half of the binary packages are younger
than 6 month, while the latest source archives have been updated
2014-06-11.

You're violating the GPL again in a pretty big style.  Yes, not all of
the affected packages are GPLed, but a lot are.  What is so complicated
to keep the sources up to date with the binary packages?

Please fix this ASAP.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


pgpRHTTlPUA12.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

[Corinna Vinschen]

On Dec  8 14:01, Alexpux wrote:
 Will update sf.net http://sf.net/ repo today.

Ok.

  And this is only for Cygwin.  The situation of the other upstream
  packages isn't better.  About half of the binary packages are younger
  than 6 month, while the latest source archives have been updated
  2014-06-11.
  
  You're violating the GPL again in a pretty big style.  Yes, not all of
  the affected packages are GPLed, but a lot are.  What is so complicated
  to keep the sources up to date with the binary packages?
 
 I’m provide git repository with build scripts and patches that applies to 
 sources:
 For mingw:
 https://github.com/Alexpux/MINGW-packages
 
 For msys2:
 https://github.com/Alexpux/MSYS2-packages 
 https://github.com/Alexpux/MSYS2-packages

In how far does that alleviate the problem of the GPL breach?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


pgpscXmmf3u_M.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

[Corinna Vinschen]

On Dec  8 15:12, Alexpux wrote:
 
  8 дек. 2014 г., в 14:27, Corinna Vinschen vinsc...@redhat.com написал(а):
  
  On Dec  8 14:01, Alexpux wrote:
  Will update sf.net http://sf.net/ repo today.
  
  Ok.
 
 Done.
  
  And this is only for Cygwin.  The situation of the other upstream
  packages isn't better.  About half of the binary packages are younger
  than 6 month, while the latest source archives have been updated
  2014-06-11.
  
  You're violating the GPL again in a pretty big style.  Yes, not all of
  the affected packages are GPLed, but a lot are.  What is so complicated
  to keep the sources up to date with the binary packages?
  
  I’m provide git repository with build scripts and patches that applies to 
  sources:
  For mingw:
  https://github.com/Alexpux/MINGW-packages
  
  For msys2:
  https://github.com/Alexpux/MSYS2-packages 
  https://github.com/Alexpux/MSYS2-packages
  
  In how far does that alleviate the problem of the GPL breach?
 
 No problem, will upload sources soon too. Problem just in
 bandwidth/limited time for it.

I'm suffering limited bandwidth, too.  I workaround that by always
uploading source and binary package at once, so I'm never falling back.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


pgpIFduqlnxUA.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 is violating the GPL again

[Corinna Vinschen]

On Dec  8 13:17, Ruben Van Boxem wrote:
 Hi Corinna,
 
 With fear of my life I stick my head in a hornet's nest, with some remarks:
 
 Archlinux solved this issue some years ago, and the bug report is cause for
 an interesting read with some pointers on how to solve this for the MSYS2
 folks: https://bugs.archlinux.org/task/5355
 Any GPLv3 project does not need the source distributed, only a link
 upstream should suffice (as long as it isn't taken offline by upstream of
 course, so a better solution would be nice).

We're not providing MSYS2 sources.  We're providing Cygwin sources.
All of our source distributions are different from MSYS2 sources.
You can't build MSYS2 from Cygwin sources without additional patches.

As for other packages, a lot of Cygwin packages contain source code
changes for patches which haven't been send upstream yet.  We're
*always* providing the exact source code which is required to rebuild
the same package, same version number.  The Cygwin distro is a moving
target, and we're deleting old releases of packages.  Any GPLed MSYS2
binary package which is not accompanied by the *exact* source code
archive required to build *this* version of the package, is in danger of
violating the GPL again.

There's something easily forgotten:

The GPL has not been created for developers or distributors in the first
place.  The GPL has been created for the users.  The idea was that all
users have the *right* to get the source codes of a GPLed binary package
at all times, in the state required to rebuild the binary package.

Whether or not the user actually takes on the offer, and whether or not
this inconveniences the developers or distributors was not a major concern.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat


pgpBaOW42SQWY.pgp
Description: PGP signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Move profile.h to crt

[Corinna Vinschen]

Hi,

the file profile.h is located in mingw-w64-headers/include right now.
I'd like to move it to mingw-w64-headers/crt for two reasons.  It's not
a Windows header, but only used in mingw-w64-crt, so it seems to be
better located in the crt header dir.  And then, on Cygwin it collides
with the official Kerberos 5 profile.h header.  If it's in crt, but
not mentioned in BASEHEAD_LIST (configure.ac), it won't be installed
as part of the w32api headers on Cygwin, so this problem would be fixed.

I didn't attach a diff because it doesn't make sense.  It's just a
git mv from one location to the other.  The ChangeLog entry would be

  * crt/profile.h: Move file from include/profile.h here.


Ok to apply?


Thanks,
Corinna


pgpQthbxO0Cuc.pgp
Description: PGP signature
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Move profile.h to crt

[Corinna Vinschen]

On May 22 12:53, Corinna Vinschen wrote:
 Hi,
 
 the file profile.h is located in mingw-w64-headers/include right now.
 I'd like to move it to mingw-w64-headers/crt for two reasons.  It's not
 a Windows header, but only used in mingw-w64-crt, so it seems to be
 better located in the crt header dir.  And then, on Cygwin it collides
 with the official Kerberos 5 profile.h header.  If it's in crt, but
 not mentioned in BASEHEAD_LIST (configure.ac), it won't be installed
 as part of the w32api headers on Cygwin, so this problem would be fixed.
 
 I didn't attach a diff because it doesn't make sense.  It's just a
 git mv from one location to the other.  The ChangeLog entry would be
 
   * crt/profile.h: Move file from include/profile.h here.
 
 
 Ok to apply?

Scratch that, Kai already moved the file.


Thanks,
Corinna


pgp83Zr_95rND.pgp
Description: PGP signature
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch] lmaccess.h: Add USER_INFO_24

[Corinna Vinschen]

Hi,

the below patch adds the missing USER_INFO_24 structure,
which has been introduced with Windows 8/2012 per
http://msdn.microsoft.com/en-us/library/windows/desktop/hh994455%28v=vs.85%29.aspx

Ok to apply?


Thanks,
Corinna


* lmaccess.h (struct _USER_INFO_24): Define.


Index: lmaccess.h
===
--- lmaccess.h  (revision 6615)
+++ lmaccess.h  (working copy)
@@ -207,6 +207,14 @@
 PSID usri23_user_sid;
   } USER_INFO_23,*PUSER_INFO_23,*LPUSER_INFO_23;
 
+  typedef struct _USER_INFO_24 {
+BOOL usri24_internet_identity;
+DWORD usri24_flags;
+LPWSTR usri24_internet_provider_name;
+LPWSTR usri24_internet_principal_name;
+PSID usri24_user_sid;
+  } USER_INFO_24,*PUSER_INFO_24,*LPUSER_INFO_24;
+
   typedef struct _USER_INFO_1003 {
 LPWSTR usri1003_password;
   } USER_INFO_1003,*PUSER_INFO_1003,*LPUSER_INFO_1003;


pgpS62ZBlmOBD.pgp
Description: PGP signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
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] lmaccess.h: Add USER_INFO_24

[Corinna Vinschen]

On May  8 19:44, Kai Tietz wrote:
 Patch is ok.

Thanks, applied.


Corinna


pgpkA06McgkcQ.pgp
Description: PGP signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
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] Don't use __stdcall on ARM

[Corinna Vinschen]

On May  7 00:59, Kai Tietz wrote:
 Yes, magic wording here is that compiler accepts it and ignores it.
 So it means not in headers.

Sorry, but I don't get this.  So per MSDN, x64 and ARM are identical
with respect to __stdcall.

If so, why is it the right thing to

 #define __stdcall

for x64, but the same is not right for ARM?!?  I fail to see the
difference.  


Corinna


 
 Cheers
 Kai
 Am 07.05.2014 00:51 schrieb Yaakov (Cygwin/X) 
 yselkow...@users.sourceforge.net:
 
  On 2014-05-06 16:37, Kai Tietz wrote:
   2014-05-06 21:15 GMT+02:00 André Hentschel:
   Am 06.05.2014 21:01, schrieb Yaakov (Cygwin/X):
   On 2014-05-05 16:32, André Hentschel wrote:
   Am 05.05.2014 23:29, schrieb André Hentschel:
   Please review, i'll commit it.
  
   Again the right patch attached now, it's getting late, sorry.
  
   Since stdcall isn't used on x64 either, wouldn't it make more sense to
   just do the following in _mingw.h:
  
  /* C/C++ specific language defines.  */
   -#ifdef _WIN64
   +#if defined(_WIN64) || defined(_ARM_)
  #ifdef __stdcall
  #undef __stdcall
  #endif
  #define __stdcall
  #endif
  
  
   Looks like that should work, be free to send a patch as this should
  help with the remaining use of __stdcall in functions
  
   No, for x64 there is still the function-attribute.  It has no mean in
   terms of different calling-convention in ABI.  Nevertheless it is used
   (and need to be handled) by diagnostics.
 
  According to MSDN, x64 and ARM are identical wrt __stdcall:
 
  [1] http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
 
 
  Yaakov
  Cygwin Ports
 
 
 
  --
  Is your legacy SCM system holding you back? Join Perforce May 7 to find
  out:
  #149; 3 signs your SCM is hindering your productivity
  #149; Requirements for releasing software faster
  #149; Expert tips and advice for migrating your SCM now
  http://p.sf.net/sfu/perforce
  ___
  Mingw-w64-public mailing list
  Mingw-w64-public@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
 

 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



pgpAkzxf9x3mw.pgp
Description: PGP signature
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch/cygwin]: Fix u_long problem on LP64 systems

[Corinna Vinschen]

Hi,


I just stumbled over a weird problem in Cygwin's socket code, which I
tracked down to a wrong definition of struct sockaddr_in6.  It had the
correct size (28 bytes) in the application but it was supposedly 40
bytes in the Cygwin DLL.

I tracked it down to the fact that the re-definition of u_long for LP64
systems is missing in ws2ipdef.h.  While looking I found that ws2tcpip.h
and mstcpip.h are affected as well.

So I'd like to propose the below patch which adds LP64 u_long overrides
to these files.


Thanks,
Corinna


* mstcpip.h: Add LP64 u_long override.
* ws2ipdef.h: Ditto.
* ws2tcpip.h: Ditto.


Index: mstcpip.h
===
--- mstcpip.h   (revision 6598)
+++ mstcpip.h   (working copy)
@@ -9,6 +9,12 @@
 #include _mingw_unicode.h
 #include winapifamily.h
 
+#ifdef __LP64__
+#pragma push_macro(u_long)
+#undef u_long
+#define u_long __ms_u_long
+#endif
+
 struct tcp_keepalive {
   u_long onoff;
   u_long keepalivetime;
@@ -131,5 +137,9 @@
 #endif /* WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) */
 #endif /*(_WIN32_WINNT = 0x0502)*/
 
+#ifdef __LP64__
+#pragma pop_macro(u_long)
+#endif
+
 #endif /* _MSTCPIP_ */
 
Index: ws2ipdef.h
===
--- ws2ipdef.h  (revision 6598)
+++ ws2ipdef.h  (working copy)
@@ -5,8 +5,15 @@
 #ifndef _WS2IPDEF_
 #define _WS2IPDEF_
 
+#include _mingw_unicode.h
 #include winapifamily.h
 
+#ifdef __LP64__
+#pragma push_macro(u_long)
+#undef u_long
+#define u_long __ms_u_long
+#endif
+
 #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
 
 #include in6addr.h
@@ -132,4 +139,8 @@
 
 #endif /* WINAPI_PARTION_DESKTOP.  */
 
+#ifdef __LP64__
+#pragma pop_macro(u_long)
+#endif
+
 #endif /*_WS2IPDEF_ */
Index: ws2tcpip.h
===
--- ws2tcpip.h  (revision 6598)
+++ ws2tcpip.h  (working copy)
@@ -8,6 +8,12 @@
 
 #include _mingw_unicode.h
 
+#ifdef __LP64__
+#pragma push_macro(u_long)
+#undef u_long
+#define u_long __ms_u_long
+#endif
+
 #include winsock2.h
 #include ws2ipdef.h
 #include psdk_inc/_ip_mreq1.h
@@ -435,4 +441,8 @@
 }
 #endif
 
+#ifdef __LP64__
+#pragma pop_macro(u_long)
+#endif
+
 #endif /* _WS2TCPIP_H_ */


pgprOzfCGh4Ji.pgp
Description: PGP signature
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
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/cygwin]: Fix u_long problem on LP64 systems

[Corinna Vinschen]

On Apr 24 15:55, Kai Tietz wrote:
 Hello Corinna,
 
 good catch.  Patch is ok. Please apply.

Done.


Thanks,
Corinna


pgpRE_5zsASTC.pgp
Description: PGP signature
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Win-Builds

[Corinna Vinschen]

On Dec 13 10:06, Adrien Nader wrote:
 There are two issues here:
 - symlink fallback on windows
 - Windows XP and symlink fallback
 
 tl;dr: don't mind the warnings, they're harmless; Windows XP support is
 an issue (but at least read the last paragraph)
 
 Full explanation below.
 
 Since the package is a *native* windows executable, it cannot do POSIX
 symlinks. Win32 symlinks are slightly different and also have several
 issues which make them not usable.
 
 The approach to provide something equivalent to how symlinks are used
 inside packages is:
 - build on linux

- or Cygwin.  It supports its own symlinks which work on XP as well.


Corinna

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

[Corinna Vinschen]

On Nov 12 13:59, Óscar Fuentes wrote:
 
 $ du -sh /lib/git-core
 13M /lib/git-core
 
 Windows Explorer says that d:/msys32/lib/git-core uses 169 MB. Obviously
 `du' is wrong because that directory contains lots of executables, using
 1.5 MB each.

No, Windows Explorer is wrong.  It doesn't grok the concept of
hardlinks, even though NTFS supports them since its birth in the last
century.


Corinna

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2: wrong disk space used reported by `du'

[Corinna Vinschen]

On Nov 12 22:52, Óscar Fuentes wrote:
 Corinna Vinschen vinsc...@redhat.com
 writes:
 
  On Nov 12 13:59, Óscar Fuentes wrote:
  
  $ du -sh /lib/git-core
  13M /lib/git-core
  
  Windows Explorer says that d:/msys32/lib/git-core uses 169 MB. Obviously
  `du' is wrong because that directory contains lots of executables, using
  1.5 MB each.
 
  No, Windows Explorer is wrong.  It doesn't grok the concept of
  hardlinks, even though NTFS supports them since its birth in the last
  century.
 
 I thought of links too, but MSYS2 `ls -l' command doesn't show anything
 that could indicate its existence. But then I learnt that hardlinks
 aren't displayed by `ln -l'. `ln -i' indeed shows the same number for
 each identical file. Thanks Corinna for putting me on the right track.
 
 Is this new on MSYS2 or MSYS already had the capability of creating hard
 links?

No, it's not new.  MSYS/MSYS2 is a fork of Cygwin and Cygwin has this
ability for ages.


Corinna

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 12:08, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12.06.2013 18:51, Alexpux wrote:
  среда, 12 июня 2013 г. в 18:00, Corinna Vinschen написал:
  On Jun 12 15:50, Alexpux wrote:
  среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
  On Jun 11 21:10, Алексей Павлов wrote:
  4. Replaced Cygwin symlinks with copying (we can investigate an option 
  for
  mklink symlinks on Vista and above but this is a topic for discussion -
  MSYS compliant software tend to work around most ln-as-cp issues when
  possible anyway).
   
   
  I said my share about what I think of copying files when the application
  expects to get a symlink. It's wrong. It's dangerous. You still have
  the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
  CYGWIN=winsymlinks:nativestrict options available when using Cygwin
  unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
   
   
   
  Yes it dangerous but native symlinks work need elevated shell and OS 
  Vista+
   
  Again, if you need a copy, use cp, not ln -s. It's plainly a bug in the
  scripts or tools you're using, if they use ln -s (or symlink(2)) when
  called in a Mingw environment. Neither of them must rely on symlinks.
   
   
  
  And I need patch every configure script and Makefile to fix it?
 To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first
 thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln
 - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance.

On Cygwin?  Not that I'm aware of.  I tested the AC_PROG_LN_S macro
on Cygwin and the LN_S setting is 'ls -s' afterwards.  That's with
autoconf-2.69.

 So it might turn out that `ln -s' hack would only affect corner-cases
 (where people just write `ln -s' in makefiles and such).
 
 Later today, when i get a new MSYS2 build (based upon the latest Cygwin
 with fixed symlinks in case of a different cygdrive prefix), i'll hack
 AC_PROG_LN_S to allow MSYS2's `ln -s' to be used, and will check if that
 works (i expect that it would).
 
 I could also replace /usr/bin/ln with a wrapper script that would log
 all invocations of `ln' with `-s' to count exactly how much it is being
 used (that said, it won't cover things like `lndir' which is use when
 needed).

What about leaving the symlink(2) function alone and rather just replace
the ln(1) tool with a wrapper which calls cp(1) in case of the -s option
instead, some ln.orig.exe otherwise?


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 13:32, LRN wrote:
 On 19.06.2013 12:57, Corinna Vinschen wrote:
  On Jun 19 12:08, LRN wrote:
  To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first
  thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln
  - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance.
  
  On Cygwin?  Not that I'm aware of.  I tested the AC_PROG_LN_S macro
  on Cygwin and the LN_S setting is 'ls -s' afterwards.  That's with
  autoconf-2.69.
 
 My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S.

_AS_LN_S_PREPARE also yields `ln -s' on Cygwin.  Just tested.

  What about leaving the symlink(2) function alone and rather just replace
  the ln(1) tool with a wrapper which calls cp(1) in case of the -s option
  instead, some ln.orig.exe otherwise?
 
 No idea. Any proposal will have to be tested first. Alexey just gave me
 a new snapshot, i'll test nativestrict there, and then we'll see.

Btw., I've created a snapshot immediately after I had applied my patch.
If you're not chilled by a Cygwin install, you can test this stuff
quicker.  The 32 bit developer snapshots are on
http://cygwin.com/snapshots, the 64 bit test version can be installed
via ftp://cygwin.com/pub/cygwin/64bit/setup64.exe


HTH,
Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 14:28, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 19.06.2013 13:55, Corinna Vinschen wrote:
  On Jun 19 13:32, LRN wrote:
  On 19.06.2013 12:57, Corinna Vinschen wrote:
  On Jun 19 12:08, LRN wrote:
  To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and first
  thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln
  - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance.
 
  On Cygwin?  Not that I'm aware of.  I tested the AC_PROG_LN_S macro
  on Cygwin and the LN_S setting is 'ls -s' afterwards.  That's with
  autoconf-2.69.
 
  My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S.
  
  _AS_LN_S_PREPARE also yields `ln -s' on Cygwin.  Just tested.
 It shouldn't. Probably. I think.
 
 It (is/should be) impossible to create an NTFS symlink to non-existing
 target in Cygwin or MSys (since the target must exist to be able to
 create an link of the right type).
 
 Are you sure that your _AS_LN_S_PREPARE does this:

yes.

 [...]
 and that you're using winsymlinks:nativestrict?

No.  I'm using any one of the other variations of symlinks.  nativestrict
was a compromise with my fellow co-maintainer.  The default symlinks
and winsymlinks:lnk always work, winsymlinks:native falls back to the 
default symlinks if creating the native symlink doesn't work.

winsymlinks:nativestrict is a special case, not the norm.

  Btw., I've created a snapshot immediately after I had applied my patch.
  If you're not chilled by a Cygwin install, you can test this stuff
  quicker.
 
 The mere thought of installing Cygwin on my machine sends shivers
 through my spine. I'll keep using MSYS2 for now. Maybe later, when i
 gather enough courage...

:)


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 12:34, Corinna Vinschen wrote:
 On Jun 19 14:28, LRN wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 19.06.2013 13:55, Corinna Vinschen wrote:
   On Jun 19 13:32, LRN wrote:
   On 19.06.2013 12:57, Corinna Vinschen wrote:
   On Jun 19 12:08, LRN wrote:
   To be fair here, i've tried the MSYS=winsymlinks:nativestrict, and 
   first
   thing i hit was AC_PROG_LN_S. That macro explicitly refuses to use `ln
   - -s' provided by MSYS or Cygwin, asking for 100% POSIX compliance.
  
   On Cygwin?  Not that I'm aware of.  I tested the AC_PROG_LN_S macro
   on Cygwin and the LN_S setting is 'ls -s' afterwards.  That's with
   autoconf-2.69.
  
   My mistake, i meant _AS_LN_S_PREPARE, not AC_PROG_LN_S.
   
   _AS_LN_S_PREPARE also yields `ln -s' on Cygwin.  Just tested.
  It shouldn't. Probably. I think.
  
  It (is/should be) impossible to create an NTFS symlink to non-existing
  target in Cygwin or MSys (since the target must exist to be able to
  create an link of the right type).
  
  Are you sure that your _AS_LN_S_PREPARE does this:
 
 yes.
 
  [...]
  and that you're using winsymlinks:nativestrict?
 
 No.  I'm using any one of the other variations of symlinks.  nativestrict
 was a compromise with my fellow co-maintainer.  The default symlinks
 and winsymlinks:lnk always work, winsymlinks:native falls back to the 
 default symlinks if creating the native symlink doesn't work.
 
 winsymlinks:nativestrict is a special case, not the norm.

As a sidenote:

What's really sad is the fact that a native symlink contains the
information if the target is a file or directory, and worse, that
non-Cygwin tools fail if the file/directory information in the symlink
is wrong.  That alone disallows to create native symlinks to non-existing
targets, since you never know whether the target will be file or dir.
I'm totally baffled how a simple functionality like creating symlinks
can be so screwed up, with no hope in sight.


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 16:01, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 19.06.2013 15:54, Ruben Van Boxem wrote:
  2013/6/19 Corinna Vinschen vinsc...@redhat.com
  
  On Jun 19 12:34, Corinna Vinschen wrote:
  On Jun 19 14:28, LRN wrote:
  [...]
  and that you're using winsymlinks:nativestrict?
 
  No.  I'm using any one of the other variations of symlinks.  nativestrict
  was a compromise with my fellow co-maintainer.  The default symlinks
  and winsymlinks:lnk always work, winsymlinks:native falls back to the
  default symlinks if creating the native symlink doesn't work.
 
  winsymlinks:nativestrict is a special case, not the norm.
 
  As a sidenote:
 
  What's really sad is the fact that a native symlink contains the
  information if the target is a file or directory, and worse, that
  non-Cygwin tools fail if the file/directory information in the symlink
  is wrong.  That alone disallows to create native symlinks to non-existing
  targets, since you never know whether the target will be file or dir.
  I'm totally baffled how a simple functionality like creating symlinks
  can be so screwed up, with no hope in sight.
 
  
  I'm sorry, but all documentation I can find about NTFS reparse points and
  softlinks etc. say explicitely that you can create a softlink to a
  nonexistent file:
  http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx
  
  So either something is XP specific and not clearly showing on MSDN, or I'm
  misunderstanding the problem.
 A file link to non-existing file - yes (mklink).
 A directory link to non-existing directory - yes (mklink /D).
 An untyped link to non-existing filesystem object - no, because NTFS
 doesn't support untyped symlinks.
 Cygwin emulates untyped linking (ln -s) by checking the type of the
 target and creating the link of the right type. If the target doesn't
 exist, you're screwed.

Not really screwed.  But if the target doesn't exist, you have the
choice between creating a file symlink or a directory symlink, and you
just don't know what the target will be.

If you create a dir symlink,
and the later created target turns out to be a file or vice versa,
the *native* tools will be screwed since the path resolution mechanism
requires the symlink type to reflect the target type.

Cygwin ignores the symlink type and resolve the symlink just by path, so
in Cygwin all symlinks will work.


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 14:11, Ruben Van Boxem wrote:
 2013/6/19 LRN lrn1...@gmail.com
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 19.06.2013 15:54, Ruben Van Boxem wrote:
   2013/6/19 Corinna Vinschen vinsc...@redhat.com
  
   On Jun 19 12:34, Corinna Vinschen wrote:
   On Jun 19 14:28, LRN wrote:
   [...]
   and that you're using winsymlinks:nativestrict?
  
   No.  I'm using any one of the other variations of symlinks.
   nativestrict
   was a compromise with my fellow co-maintainer.  The default symlinks
   and winsymlinks:lnk always work, winsymlinks:native falls back to the
   default symlinks if creating the native symlink doesn't work.
  
   winsymlinks:nativestrict is a special case, not the norm.
  
   As a sidenote:
  
   What's really sad is the fact that a native symlink contains the
   information if the target is a file or directory, and worse, that
   non-Cygwin tools fail if the file/directory information in the symlink
   is wrong.  That alone disallows to create native symlinks to
  non-existing
   targets, since you never know whether the target will be file or dir.
   I'm totally baffled how a simple functionality like creating symlinks
   can be so screwed up, with no hope in sight.
  
  
   I'm sorry, but all documentation I can find about NTFS reparse points and
   softlinks etc. say explicitely that you can create a softlink to a
   nonexistent file:
   http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx
  
   So either something is XP specific and not clearly showing on MSDN, or
  I'm
   misunderstanding the problem.
  A file link to non-existing file - yes (mklink).
  A directory link to non-existing directory - yes (mklink /D).
  An untyped link to non-existing filesystem object - no, because NTFS
  doesn't support untyped symlinks.
  Cygwin emulates untyped linking (ln -s) by checking the type of the
  target and creating the link of the right type. If the target doesn't
  exist, you're screwed.
 
 
 Call me naive, but why not create the link to non-existent ... thing (which
 should possible, just choose file or directory; it doesn't matter because
 its not there)... then when the actual thing is created, change the link to
 conform to the new filesystem state?

The POSIX calls are stateless.  When the target of a symlink gets
created, you don't even know if a symlink to the target has been created
at all, let alone by the same process.

 You can keep track as the symlink info is contained in the information
 retrieved by GetFileAttributesEx.

Not really.  With GetFileAttributesEx you only get the fact if a file is
a reparse point or not.  If it's a symlink requires further checking.
Even with the underlying native NtQueryInformationFile you can get all
the hardlinks pointing to the same file (same file ID), but not all
symlinks pointing to a file.

 This setup might require bookkeeping though, not entirely well-versed in
 this stuff.

This kind of bookkeeping opens a can of worms.  In theory you'd have to
maintain a shared memory region of potentially indefinite size to keep
track of dangling symlinks in calls to symlink(2).  To utilize this
shared mem region, *all* Cygwin processes calling open(2) or mkdir(2)
would have to check if the path to the new file or directory is in the
shared list of dangling symlinks and, if so, call a helper function
which recreates the symlink with the correct type and remove the
dangling symlink from the list.

One problem here is the fact, that the shared memory region is only
maintained as long as at least one Cygwin process is still running since
shared mem regions disappear when the last handle to them is closed.  If
you start Cygwin tools from CMD like this

  C:\ C:\cygwin\bin\ln -s foo bar
  C:\ C:\cygwin\bin\mkdir bar

then there's no Cygwin process running between the lifetime of ln and
mkdir.  So the shared mem region doesn't exist anymore when mkdir is
called and the whole excerise is moot.

And there's another problem with this approach.  Unfortunately you can't
overwrite symlinks atomically.  You have to remove the old symlink and
create a new one.  In the time between removing and recreation, another
process could have made a wrong decision based on the non-existence of
the symlink.  You could eliminate this problem by deleting and
recreating the symlink in an NTFS transaction, but very, very
unfortunately Microsoft has announced to drop NTFS transactions from
future versions of NTFS(*).


Corinna


(*) This a an extrem pity, because transactions are necessary in some
scenarios to overcome non-POSIXy behaviour of some system calls.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 14:36, Corinna Vinschen wrote:
 On Jun 19 16:01, LRN wrote:
  Cygwin emulates untyped linking (ln -s) by checking the type of the
  target and creating the link of the right type. If the target doesn't
  exist, you're screwed.
 
 Not really screwed.  But if the target doesn't exist, you have the
 choice between creating a file symlink or a directory symlink, and you
 just don't know what the target will be.
 
 If you create a dir symlink,
 and the later created target turns out to be a file or vice versa,
 the *native* tools will be screwed since the path resolution mechanism
 requires the symlink type to reflect the target type.
 
 Cygwin ignores the symlink type and resolve the symlink just by path, so
 in Cygwin all symlinks will work.

Btw., this is one reason why I don't understand the desire to use native
tools.  If you can get a working POSIXy build environment for free, why
do you want to use native tools which only generate problems you could
easily do without weird tweaks to the Cygwin DLL?!?


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 14:14, Ray Donnelly wrote:
 On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen wrote:
  Btw., this is one reason why I don't understand the desire to use native
  tools.  If you can get a working POSIXy build environment for free, why
  do you want to use native tools which only generate problems you could
  easily do without weird tweaks to the Cygwin DLL?!?
 
 Usually it's because Cygwin is usually a lot slower than native for IO
 heavy operations. Projects (such as the Android NDK) that supply
 Cygwin-based compilers usually try to migrate to native ASAP, viewing the
 Cygwin-based tools as a stop-gap measure.

Yeah.  There's nothing we can do about that if we want to maintain POSIX
compatibility as much as possible.  SFU suffered from the same problem
and they had at least the advantage of being able to use a native fork.


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 15:27, Ruben Van Boxem wrote:
 2013/6/19 Corinna Vinschen
  And there's another problem with this approach.  Unfortunately you can't
  overwrite symlinks atomically.  You have to remove the old symlink and
  create a new one.  In the time between removing and recreation, another
  process could have made a wrong decision based on the non-existence of
  the symlink.  You could eliminate this problem by deleting and
  recreating the symlink in an NTFS transaction, but very, very
  unfortunately Microsoft has announced to drop NTFS transactions from
  future versions of NTFS(*).
 [...]
 An alternative to TxF is doing that in Kernel mode directly of course:
 http://msdn.microsoft.com/en-us/library/windows/hardware/ff565748%28v=vs.85%29.aspx

Cygwin already uses the native NT calls as described in this document.
Many of them are usable from user space without having to create a
kernel driver, see
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?rev=1.648content-type=text/x-cvsweb-markupcvsroot=src
functions start_transaction() and stop_transaction().

However, if future NTFS versions stop supporting transactions, even
using the native NT calls will be useless since the filesystem flags
will have the FILE_SUPPORTS_TRANSACTIONS flag unset (as on ReFS, for
instance).


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 19 15:24, Corinna Vinschen wrote:
 On Jun 19 14:14, Ray Donnelly wrote:
  On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen wrote:
   Btw., this is one reason why I don't understand the desire to use native
   tools.  If you can get a working POSIXy build environment for free, why
   do you want to use native tools which only generate problems you could
   easily do without weird tweaks to the Cygwin DLL?!?
  
  Usually it's because Cygwin is usually a lot slower than native for IO
  heavy operations. Projects (such as the Android NDK) that supply
  Cygwin-based compilers usually try to migrate to native ASAP, viewing the
  Cygwin-based tools as a stop-gap measure.
 
 Yeah.  There's nothing we can do about that if we want to maintain POSIX
 compatibility as much as possible.  SFU suffered from the same problem
 and they had at least the advantage of being able to use a native fork.

OTOH, Cygwin got faster over the last year or so, and the 64 bit version
will be another bit faster.  There's always room for development.


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

 function X server with X clients.

That's all I'm trying to say.  I don't see a good reason to change the
Cygwin DLL.  Use it as is and build your Mingw-targeting environment
around it.  I'm here to help if something doesn't work out as you need
it.  Maybe we find another, working solution, without having to fork
Cygwin.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 12 12:47, Corinna Vinschen wrote:
  6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is
  to retain compatibility with MSYS-enabled software that makes assumptions
  about /c/ being equivalent to C:/
 
 It's not necessary at all to change the Cygwin/MSYS2 DLL to make this
 happen.  Just add this to /etc/fstab:
 
   none / cygdrive binary,posix=0,user 0 0
 
 Stop all Cygwin processes, login to your bash and try this:
 
   $ cd /c
   $ ls
   $Recycle.Bin  Documents and Settings  ProgramData   System Volume 
 Information
   bootmgr   pagefile.sysPython32  Users
   BOOTNXT   PerfLogsrhcygwin  Windows
   cygwinProgram Files   swapfile.sys
   cygwin64  Program Files (x86) Symbols

I forgot to provide a link to the User's Guide describing the mount table
and the cygdrive prefix handling:

  http://cygwin.com/cygwin-ug-net/using.html#mount-table
  http://cygwin.com/cygwin-ug-net/using.html#cygdrive

The mount command also has changed from how it worked in earlier Cygwin
versions:

  http://cygwin.com/cygwin-ug-net/using-utils.html#mount

  
HTH,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 12 16:00, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12.06.2013 14:47, Corinna Vinschen wrote:
  Hi Алексей,
  
  On Jun 11 21:10, Алексей Павлов wrote:
  MSYS includes the following changes to Cygwin to support using native Win32
  programs:
  1. Automatic path mangling of command line arguments and environment
  variables to Win32 form on the fly for Win32 applications inside bash.exe
  
  That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
 You misinterpreted that.
 
 The mangling is done in msys-2.dll, it's done every time a process is
 spawned. The parent checks the dependencies of the child, and if child
 does NOT depend on msys-2.dll (that is, if child is not a MSYS
 application), the parent will spawn it with mangled environment (thus
 the child will not get POSIX paths in envvars, such as PATH) mangled and
 arguments

This is default in Cygwin for a long time.  When Cygwin starts, a small
number of variables is converted from Windows to POSIX style, namely
PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP.

If a Cygwin process execve's a non-Cygwin process, the whole thing
is done backwards.

This is not done for any other variable, and in no direction, because
trying to recognize other variable's content as path and then converting
it to the other style is pure speculation on the DLL's part.  The result
is broken as often as not.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 12 15:50, Alexpux wrote:
 среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
  On Jun 11 21:10, Алексей Павлов wrote:
   MSYS includes the following changes to Cygwin to support using native 
   Win32
   programs:
   1. Automatic path mangling of command line arguments and environment
   variables to Win32 form on the fly for Win32 applications inside bash.exe

   
   
  That's a bash change which does not affect the underlying Cygwin/MSYS DLL.
   
 This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc 
 and new files msys.cc and is msys.cc  

You wrote it's a bash change.  As a bash change I can understand it, as
a Cygwin change not so much.  This is pure speculating on the DLL side
again.  You simply don't know exactly if something is a path and in what
form the argument is used by the called application.  If in doubt, use
cygpath.

   2. Ability to change OSNAME with an environment variable (MSYSTEM) to
   change it between MSYS and MINGW32 (so people can add to or fix MSYS
   programs should they need to).

   
   
  Ditto.
 Cygwin dll function uname changes  

Sigh.

   3. Conversion of output of native Win32 application output from Windows
   line endings to Posix line endings - removing trailing '\r' symbol - in
   bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected.

   
   
  Ditto.
 Yes it is bash changes and they also can be integrated in Cygwin bash I think 
  
man dos2unix

   4. Replaced Cygwin symlinks with copying (we can investigate an option for
   mklink symlinks on Vista and above but this is a topic for discussion -
   MSYS compliant software tend to work around most ln-as-cp issues when
   possible anyway).

   
   
  I said my share about what I think of copying files when the application
  expects to get a symlink. It's wrong. It's dangerous. You still have
  the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
  CYGWIN=winsymlinks:nativestrict options available when using Cygwin
  unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
   
   
 
 Yes it dangerous but native symlinks work need elevated shell and OS Vista+

Again, if you need a copy, use cp, not ln -s.  It's plainly a bug in the
scripts or tools you're using, if they use ln -s (or symlink(2)) when
called in a Mingw environment.  Neither of them must rely on symlinks.

  I'm not negative. I'm just defending the integrity of the Cygwin DLL.
   
  Again, I'm perfectly happy if you provide an MSYS2 distro containing
  special tools, like a tweaked bash and an entire, Mingw-centric
  toolchain arrangement, as long as you keep the underlying Cygwin DLL
  intact as provided upstream. Also, don't change the name of the DLL and
  the target name of the toolchain ({i686/x86_64}-pc-cygwin).
   
  Everyone would have an advantage of this:
   
  - There would be only one source of the underlying POSIX-providing DLL.
  Central repository, only one source to care about, no merging and
  tweaking hassle.
   
  - The DLL name stays intact, thus every tool built in and for the MSYS2
  environment would run in a Cygwin distro environment as well.
  - The toolchain name stays intact. You can just grab the latest gcc and
  binutils sources and build them for the upstream supported
  ${arch}-pc-cygwin target and it would create files running in both
  environments.
   
  - While the normal Mingw/MSYS2 user would not have to look into the
  Cygwin distro since the MSYS2 distro provides what he or she needs,
  the more demanding user of MSYS2 would have free access to all tools
  provided by the Cygwin distro with thousands of tools and applications,
  not to mention a fully function X server with X clients.
   
  That's all I'm trying to say. I don't see a good reason to change the
  Cygwin DLL. Use it as is and build your Mingw-targeting environment
  around it. I'm here to help if something doesn't work out as you need
  it. Maybe we find another, working solution, without having to fork
  Cygwin.

Corinna

--  
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 12 15:11, Ray Donnelly wrote:
 Ok, We're back to asking for a plugin with a clearly defined interface for
 env. var and path translation; despite LRNs reasonable objections I think
 it might be the only acceptable solution?
 
 .. that way we can continue to speculate (as MSYS always has) about what's
 a path and what isn't and also use the cygwin.dll unmodified.
 
 Otherwise we're at an impasse.

First, may I politely ask, if this is really necessary, or if everybody
thinks it's necessary just because the old MSYS did so.

Does anybody have a real world example which requires this, and isn't
easily fixed by using cygpath at the crucial stage?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 10 13:19, Алексей Павлов wrote:
 Corinna,
 I upload 3rdparty sources that I use in MSYS2 to
 https://sourceforge.net/projects/msys2/files/Sources/

Thank you.


Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

Hi Алексей,

On Jun 10 10:19, Corinna Vinschen wrote:
 On Jun  8 12:49, Алексей Павлов wrote:
  I recreate git repository on msys2.sf.net.
  Now master branch point to MSYS2 source and when you go to code page on
  sf.net you get page with MSYS2 source.
 
 Thank you, that's much better.  This allows an unaware user to access 
 the correct sources immediately.

I noticed that you changed the file information resource in winver.rc:

  VALUE CompanyName, SourceForge.Net
  VALUE FileDescription, MSYS\256 POSIX Emulation DLL
  VALUE FileVersion, STRINGIFY(CYGWIN_VERSION)
  VALUE InternalName, CYGWIN_DLL_NAME
  VALUE LegalCopyright, Copyright \251 - see the file MSYS_COPYRIGHT

Two questions:

- CompanyName SourceForge.Net makes me cringe, since that looks as if
  SourceForge is the company behind that project.  Fortunately the
  CompanyName value is not printed in the file properties dialog anymore
  since Vista, but still... would you mind to change that to MSYS or
  something?

- LegalCopyright refers to a file called MSYS_COPYRIGHT, but there's no
  such file in the source package, nor in the binary package.  May I asked
  to add this file?

And a suggestion:

- FileDescription contains an (R), Registered Trademark.  Is MSYS actually
  a registered trademark?  If not, I would suggest to remove this because
  it can have negative effects in some legislations.


Thanks,
Corinna

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

Hi Алексей,

On Jun  8 01:56, Алексей Павлов wrote:
 2013/6/7 Corinna Vinschen wrote:
  A final note:  I'm not opposing the fork.  Under the GPL it's your
  perfect right to do so, as long as you adhere to the license
  requirements.  But that doesn't mean I have to understand it.  If the
  DLL and the tools are exactly the same and only differ by name, then,
  what's the point?  Wouldn't it make more sense to work with us on the
  Cygwin project instead?
 
 Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
 IRC. It would be more right way I think but I think you don't interesting
 in it. I'm right? That is why I create fork of Cygwin. But if it possible
 to support MSYS2 mode in Cygwin sources I think all be happy to not create
 many forks an so on.

The problem is this.  So far I'm wondering what MSYS2 is about.  It
doesn't add any useful functionality over Cygwin.  And if so, why not
integrate it into Cygwin instead and only have one project for
everybody?  JonY already maintains the mingw-w64 32 and 64 bit cross
toolchains as part of the Cygwin distro, so there's nothing missing for
those who want to create native applications.

Forking makes sense in some scenarios, especially if there's a big rift
between the development targets of the developers, or licensing
problems.  But for a start, I don't see this here, unless I'm missing
something.

Granted, right now MSYS2 adds code which is entirely unacceptable for
Cygwin.  For instance the symlink(2) function *copying* files, even
recursively if the target is a directory.  I don't grok the reason for
this.

So here's a user or script innocently calling

  ln -s /cygdrive/c/Windows /

which is something I do often to have easier access to the Windows
directory for certain tasks.  But I definitely don't want a copy of the
Windows directory.  If it's about compatibility with native tools, the
change still doesn't makes sense.

- Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
  symlinks works fine,
  
- or you need a copy of a certain subtree, then you should have called
  cp, rather than ln -s,

- or you need a Windows symlink, then you should have created a
  native symlink using the new Cygwin capability to create native
  symlinks using the CYGWIN=winsymlinks:native{strict} setting.

The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.

emotional mode

Other than that I'm rather puzzled as to what MSYS2 is about, other than
to duplicate developer efforts and to split communities.  Apart from
your perfect right to fork, you might nevertheless understand that I'm a
bit annoyed.  Especially given the code base.  Me and Kai were working
hard for months to create a 64 bit version of Cygwin, and while our
Cygwin 64 bit distro is still in test mode, you simply rip off the code
and just release your own MSYS2 distro from there.

I can't help to feel exploited.

/emotional mode

Back to the technical stuff.  Again, I don't understand the reason for
the fork, please explain.  What is it, codewise, you really miss in
Cygwin?  What non-code problems is MSYS2 trying to fix?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 13:26, Corinna Vinschen wrote:
 Other than that I'm rather puzzled as to what MSYS2 is about, other than
 to duplicate developer efforts and to split communities.  Apart from
 your perfect right to fork, you might nevertheless understand that I'm a
 bit annoyed.  Especially given the code base.  Me and Kai were working
 hard for months to create a 64 bit version of Cygwin, [...]

...and don't forget all the other people who helped to find and fix
porting bugs in the 64 bit Cygwin version, the maintainers who helped
building the 64 bit test distro and who are sending patches upstream,
etc.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 15:43, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 11.06.2013 15:26, Corinna Vinschen wrote:
  Hi Алексей,
  
  On Jun  8 01:56, Алексей Павлов wrote:
  2013/6/7 Corinna Vinschen wrote:
  A final note:  I'm not opposing the fork.  Under the GPL it's your
  perfect right to do so, as long as you adhere to the license
  requirements.  But that doesn't mean I have to understand it.  If the
  DLL and the tools are exactly the same and only differ by name, then,
  what's the point?  Wouldn't it make more sense to work with us on the
  Cygwin project instead?
 
  Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
  IRC. It would be more right way I think but I think you don't interesting
  in it. I'm right? That is why I create fork of Cygwin. But if it possible
  to support MSYS2 mode in Cygwin sources I think all be happy to not create
  many forks an so on.
  
  The problem is this.  So far I'm wondering what MSYS2 is about.
 
 MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and
 libraries with *nixy (or cygwinny, if you prefer) buildtools and
 scripts, with the aim of building W32 libraries and applications.
 
 In Cygwin (or when running a real GNU system) you have to use a
 cross-compiler to build W32 binaries.
 In MSYS you don't have to. That's it.

And why exactly is that a problem?  The cross compiler is creating
the exact same code as a native-like compile with the same version.

If you really want that badly, you could get this by not installing
the Cygwin gcc4 package but rather installing matching hardlinks or
symlinks in the /bin directory.  This hardly explains the requirment
for a fork.

  [...]
  - or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
  
  The latter would be much more feasible as default setting, while on old
  pre-Vista systems, it would be much more feasible to fail gracefully, or
  to use Cygwin's method to create a Windows .lnk file instead.
 
 Now that you know what MSYS is about,

You're not telling me that *this* is what MSYS2 is about, right?
Not seriously.

  it should be obvious that crude
 symlink-by-copying is necessary to satisfy W32 tools, which cannot use
 cygwin symlinks or Windows .lnk files.

Not really.  If you need a copy, call cp.  That's what it is for.
Faking symlinks by copying is just bad.  So you create a symlink by
copying.  Next you change the original.  The consumers of the symlink
will never see this change.  This is just... bad.

 Windows symlinks (when using NT 6 and newer) are fine (well, they are
 not POSIXly, but they may turn out to be better than dumb copying (for
 the purpose of using them when building software), i'll try to test that
 later), MSYS1 had no way of creating them, and thus this was not an
 option. Now it is an option, and maybe a good default too.

And then, if you;re using them as default, the question returns.  Why
not use Cygwin with this option rather than the fork?  ou can simply set
up your default environment with the CYGWIN=winsymlinks:native{strict}
option and you're all set.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 12:58, Ray Donnelly wrote:
 I for one am hugely appreciative of all the hard work that Corinna, Kai,
 redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
 MSYS2.
 
 Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we

I fail to see that.  MSYS2 is basically to run a Mingw compiler and to
have a POSIX-like shell.  How is that something Cygwin doesn't provide
anyway?!?

 can reasonably do on MSYS2 (credits, thanks printed at each login,
 explanations of where MSYS2 comes from and links to Cygwin etc) to make the
 fork-pill easier to swallow, I'm sure Alexey will be happy to do (though I
 can't speak for him of course!)
 
 MSYS itself was a fork of Cygwin ages ago, and it's really showing its age.
 If you accept that there's any value in MSYS, then I hope you can see the
 need we in the MSYS using section of the mingw-w64 community have for an
 updated versoin. As an example, we can't build Qt with MSYS because MSYS
 Perl is at version 5.8.8. MSYS itself was badly fragmented by the msysgit
 project which uses an even earlier version of MSYS than the latest one
 which is also missing important tools such as install.exe and something
 has to be done to improve this situation. Our hope is that MSYS2 can be
 adopted by that project and that MSYS never rots as badly as it has done.
 
 If we can get down to a proper technical discussion on what's different and
 why, then we can maybe think about some way of working together?
 
 So many thanks everybody for the hard work and dedication.

My stance is that everything you can do with MSYS2 you can do with
Cygwin anyway, so the reason for the fork escapes me.  If it's all about
symlinks as copies, then I think this was a really bad idea from the
start.  In the old times Cygwin did the same (albeit not recursively)
when creating hardlinks on FAT and FAT32.  But that was a bad idea from
the start as well, which is why later versions of Cygwin returned an
error EPERM instead.

So, yes, I'm more than willing to discuss the technical reasons for
forking Cygwin, but there's nothing yet which couldn't be handled
by a change to the environment setup alone.

Alternatively, I could understand if you would build some micro-distro
around Cygwin which handles the default setup of the environment
differently so it's more matching your Mingw workflow.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 16:59, LRN wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 11.06.2013 16:14, Corinna Vinschen wrote:
  On Jun 11 12:58, Ray Donnelly wrote:
  I for one am hugely appreciative of all the hard work that Corinna, Kai,
  redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
  MSYS2.
 
  Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we
  
  I fail to see that.  MSYS2 is basically to run a Mingw compiler and to
  have a POSIX-like shell.  How is that something Cygwin doesn't provide
  anyway?!?
 Cygwin doesn't seem to have the mangling (that is, converting paths like
 /usr/local/include/glib to C:/foobar/baz/usr/local/include/glib).

Cygwin has the cygwin_path_conv call which allows to convert paths
from POSIX to Windows and vice versa, including long paths  260 chars.

You can also use Windows path as input.  `find C:/' works.

 I'm sure that Alexey will be able to give you a complete list of things
 that Cygwin can't do, but MSYS2 can (or should be able to) do.

Just as a sidenote, a ChangeLog.MSYS or something like that in the
sources would be helpful.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 16:42, m...@morous.org wrote:
  On Jun 11 12:58, Ray Donnelly wrote:
  I for one am hugely appreciative of all the hard work that Corinna, Kai,
  redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
  MSYS2.
 
  Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything
  we
 
  I fail to see that.  MSYS2 is basically to run a Mingw compiler and to
  have a POSIX-like shell.  How is that something Cygwin doesn't provide
  anyway?!?
 
 Before I begin I would like to note that I have never been a member of
 cygwin or MSYS development community, but that I was using both in the
 past as a user (several years each).
 
 I am one of those who uses MSYS and who does not like cygwin, so perhaps
 it might be beneficial to provide my point of view. So keep in mind that
 what follows is only my subjective opinions what MSYS is good for and why
 it is good to have it.
 
 If you want a minimalistic environment where you can use simple unix-like
 Makefile or run your configure script, MSYS is exactly that. If your
 shell script or Makefile works in MSYS, you can have a good confidence it
 will work for others who use MSYS, and probably even for those who use
 cygwin or who cross-compile on Linux.
 
 On the other side, cygwin is very big, complex and ever-changing beast.

We seem to mix two things here.

I'm more concerned about a fork of the Cygwin DLL, Cygwin, the
underlying POSIX DLL vs. MSYS2, the underlying POSIX DLL.

You seem to be taking of Cygwin the distro, vs. MSYS2 the distro and
the contained tools.

If the Cygwin distro is too big, or too unstable or whatnot for your
taste, that's ok.  So, if you think that a MSYS2 distro makes sense,
because of a different set of tools, more compact, easier to install,
more aligned with the requirements of the Mingw developer, than that's
fine.

But I don't see that this qualifies for a fork of the DLL.  Or, FWIW,
to implement a parallel toolchain, targeting *exactly* the same target,
just with another toolchain name, linked against the same DLL, just
using another name, so the tools are non-interoperable.

Think about it.  You have two sets of exactly the same coreutils (cp,
mv, ls, ...) which are non-interoperable just because the DLL they are
linked against are named differently?  That's just puzzeling.  It
doesn't help anybody.

 There were also other technical reasons which perhaps may be already be
 fixed.

A lot has changed since 2002...


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun 11 16:52, LRN wrote:
  And why exactly is that a problem?  The cross compiler is creating
  the exact same code as a native-like compile with the same version.
 Cross-compiling is somewhat more tricky. Also do remember that MSYS1 is
 rather old, cross-compiling was even trickier back then. And Cygwin had
 - -mno-cygwin for that purpose back then too.
 
 AFAIU, it's also tricky to run testsuite when cross-compiling.

I'm using the Mingw cross compiler as part of the Cygwin distro a lot
for testing purposes.  I never had much of a problem.  And the -mno-cygwin
flag was a hack.  I admit freely that I was kind of nervous when
everybody around me thought it's a good idea to remove that flag, but
I'm certainly not looking back anymore for a long time.

   it should be obvious that crude
  symlink-by-copying is necessary to satisfy W32 tools, which cannot use
  cygwin symlinks or Windows .lnk files.
  
  Not really.  If you need a copy, call cp.  That's what it is for.
  Faking symlinks by copying is just bad.  So you create a symlink by
  copying.  Next you change the original.  The consumers of the symlink
  will never see this change.  This is just... bad.
 Indeed, users are able to call cp instead of ln. Buildscripts can't.
 Buildscripts (which mostly means autotools) are written with the
 assumption that they will be run on a POSIX system, and thus MSYS has to
 provide POSIX tools. Just as Cygwin does. Except that Cygwin goes all
 the way down to the toolchain and compiles Cygwin programs, while MSYS
 stops early, only providing tools (i.e. things that are only used at
 build-time), and only those tools that can't be feasibly ported to W32
 (i.e. pkg-config and gettext are ported, bison and bash are not; libtool
 is a borderline case - is a shell script, but it is also very W32-aware).

And what's the exact problem here?  If you have a POSIX toolset anyway,
it can be easily used from autotools.  Why *do* you stop in the middle?
The fact that autotools use POSIX tools doesn't mean the end result of
your build has to.

 I do understand that Cygwin improved a lot since MSYS1 fork, and that
 cross-compiling also moved on, so cross-compiling from Cygwin is not as
 scary as it was years ago (i hope it isn't; i don't use Cygwin, and i
 don't cross-compile on my Debian machine these days, so that's all just
 speculation on my part).

Cross-compiling is dead easy these days.  For instance, I'm building
the Cygwin package and multiple other packages on Linux for years.

Yes, there are packages which refuse to configure correctly when
trying to cross-build them, but these are simple bugs in the autoconf
script, which are rectifiable and, ideally, sent upstream.

 Still, i'm not convinced that Cygwin is the
 universal, all-purpose tool that you seem to think it is
 (SquarePegRoundCygwin).

Dunno about that.  It seems to me that the peg is only square because it
has been mauled with too big a hammer.  Creating an incompatible POSIX
toolchain with a forked DLL which in principal only differs by name is
such a big hammer.

Creating a simplified set of tools but using the same underlying DLL
without introducing incompatibilites would have been the more friendly
way, IMHO, for the developers and the users.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

Hi Алексей,

On Jun  8 12:49, Алексей Павлов wrote:
 I recreate git repository on msys2.sf.net.
 Now master branch point to MSYS2 source and when you go to code page on
 sf.net you get page with MSYS2 source.

Thank you, that's much better.  This allows an unaware user to access 
the correct sources immediately.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun  7 00:17, Алексей Павлов wrote:
 Hi, everybody!
 
 I have work on creating MSYS2 based on latest Cygwin sources and now create
 archives with alpha version.
 Links:
 32-bit:  
 x32-msys2-alpha-20130607.7zhttp://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download
 64-bit:  
 x64-msys2-alpha-20130607.7zhttp://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download
 
 MSYS2 is still using Cygwin like posix paths with /cygdrive prefix.
 
 I would be happy if it can be tested by users who uses MSYS environment.
 Information about issues you can send to alex...@gmail.com or in this
 thread.

This binary archive has a serious licensing problem.

I checked the git source repository on sourceware and found that there
is absolutely *no* change compared to the Cygwin source repository, none
at all.  If you build from the git repo, the resulting DLL will be
basically identical to the 2013-06-06 snapshot from
http://cygwin.com/snapshots/

Also, right now, the accompanying tools and DLLs are named as their
Cygwin counterparts.  They still use the original names cygcheck.exe,
cygpath.exe, cyglsa{64}.dll, cygwin-console-helper.exe, cygserver.exe.
Isn't that, to say the least, strange?

But more importantly, in the aforementioned binary archives, the DLL is
called msys-2.0.dll.  Additionally, calling `uname -sro' returns

  MSYS_NT-6.2-WOW64 2.0.0(0.266/5/3) Msys

rather than

  CYGWIN_NT-6.2-WOW64 1.7.20(0.266/5/3) Cygwin

and inspecting the object file shows more tiny changes.

None of them are available in the git source repository.

Therefore the binary package infringes the Cygwin license, or, more
specificially, the underlying GPLv3+.

As representative of the copyright holders, I ask you to fix this ASAP
by providing the exact sources required to build the msys-2.0.dll and
it's accompanying tools in the git repo.  I also ask you to adhere to
the GPLv3, section 5a, by adding prominent notices stating that you
modified it, and giving a relevant date, in the sources.

Apart from the Cygwin package, the aforementioned binary archives come
with a lot of binaries from other projects, many of them GPLed.  Where's
the source code for them?

For GPLv2 packages you could get away with complying to section 3b, but
that requires to give any of your downloaders the written promise to
provide the source code within the next three years, which is kind of
unrealistic, so you *must* provide equivalent source codes according to
GPLv2, section 3a.

For GPLv3 packages you *must* provide either source codes for all binary
packages as well, or you must maintain clear directions next to the
object code saying where to find the corresponding sources, according to
section 6d.  If you made changes to the upstream sources to build the
packages, you also have to adhere to section 5.  If the changes are not
upstream, you have to provide the source changes.

For non-GPL packages I suggest to check their licensing requirements as
well, especially in terms of the requirement to provide source code.

Please fix this license infringements as soon as possible and keep us
informed about the progress.

A final note:  I'm not opposing the fork.  Under the GPL it's your
perfect right to do so, as long as you adhere to the license
requirements.  But that doesn't mean I have to understand it.  If the
DLL and the tools are exactly the same and only differ by name, then,
what's the point?  Wouldn't it make more sense to work with us on the
Cygwin project instead?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun  7 17:34, Jean-Baptiste Kempf wrote:
 Hello,
 
 On 07 Jun, Corinna Vinschen wrote :
  I checked the git source repository on sourceware and found that there
  is absolutely *no* change compared to the Cygwin source repository, none
 
 git checkout -b msys-2.1 origin/msys2-1.0-dev
 
 There are a lot of changes. 235 to be exact...

Thanks, but that's not easily reachable via the MSYS web page.  If you
click on the Code link on http://sourceforge.net/projects/msys2/
it leads you to the web view and a git command, which is

  git clone git://git.code.sf.net/p/msys2/code msys2-code

I used this command to fetch the repo and I called `git branch'
with the following result:

  $ git branch
  * master

Now I see that the msys2-1.0-dev branch exists, but is only remotely
tracked.  It would be more helpful if the default `git pull' command
would fetch the branch which represents the msys2 binary package.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

[Corinna Vinschen]

On Jun  7 17:57, Jean-Baptiste Kempf wrote:
 On 07 Jun, Corinna Vinschen wrote :
  On Jun  7 17:34, Jean-Baptiste Kempf wrote:
   Hello,
   
   On 07 Jun, Corinna Vinschen wrote :
I checked the git source repository on sourceware and found that there
is absolutely *no* change compared to the Cygwin source repository, none
   
   git checkout -b msys-2.1 origin/msys2-1.0-dev
   
   There are a lot of changes. 235 to be exact...
  
  Thanks, but that's not easily reachable via the MSYS web page.  If you
 
 Indeed. Yet, I fail to see how this is a GPL violation.
 A limitation of SF, probably.
 
 Asking for the code would have been faster and saner, IMVHO.
 http://sourceforge.net/p/msys2/code/ci/msys2-1.0-dev/tarball

Given the msys2-1.0-dev branch, it's not a GPL violation.  However,
usually I'd expect that I have access to the sources easily.  From
the msys2 homepage there's only easy access to the binary packages
and the master branch.  Sane is in the eye of the beholder.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ctype warnings

[Corinna Vinschen]

On Apr 11 09:38, Ruben Van Boxem wrote:
 2013/4/11 G M gmiso...@gmail.com
 
  Hi Ruben
 
  Thanks for replying. :)
 
  That's because from the pasted code shows the file and the line and an
  array access:
 
 
  c:/mingw/bin/../lib/clang/3.3/../../../x86_64-w64-mingw32/include\ctype.h:201:41:
  note: expanded from macro '__chvalidchk'
   #define __chvalidchk(a,b) (__PCTYPE_FUNC[(a)]  (b))
 
  As _PCTYPE_FUNC[(a)] is an array access, and chvalidchk is a macro, to my
  mind, a macro can't know it's types, but could be passed a character or an
  integer in this instance.
 
  When it's a character, the warning will occur, since it's being used as an
  offset into an array.
  So I'm thinking static_castsize_t or static_castptrdiff_t should
  be there to silence this.
 
  What do you think?
 
  The calling code is libcxx, and/or there may be issues there so if you
  want to marvel the full beauty of the warnings to be sure, here they are.
  Thanks.
  c:\libcxx\src\locale.cpp:915:34: warning: array subscript is of type
  'char' [-Wchar-subscripts]
  *low = (isascii(*low)  islower_l(*low, __cloc())) ? *low-'a'+'A'
  : *low;
   ^
 
 
 This is the thing I was talking about: the actual warning that spawned the
 notes. This is actually libc++'s problem: both POSIX and MSDN define
 [_]islower_l as taking an int, and here a char is passed to it, resulting
 in a warning originating from the implementation in the mingw-w64 crt.

And this warning is a good thing.

 Granted, all this define mess in my support/win32/*h headers should really
 be inline functions or something, but that's beside the point here. libc++
 should cast the char_type to int in this case to remedy this warning.
 
 http://msdn.microsoft.com/en-us/library/1z2s6by9%28v=vs.110%29.aspx
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/islower.html
 (actually is_lower_l is not POSIX, but an extension supported by
 BSD/Mac/MSVS2005+. All accept int, not char)

Yes, the functions accept int, but the reason they do it is to make
sure to recognice EOF.  But note the rest of the text:

  The c argument is an int, the value of which the application shall
  ensure is a character representable as an unsigned char or equal to
^
  the value of the macro EOF.  If the argument has any other value, the
  behavior is undefined.
  ^

That means, if you give a char to this function, on machines on which
char is a *signed* type, you make a mistake.  All char values  127
are negative int values, and automatic casting to int will still result
in negative values.  Negative values are very certainly not within the
range of the unsigned char type.

So, in fact, even if it's long standing typical behaviour in a lot of
applications, using the ctype functions with a char type is wrong.
For that reason, newlib introduced a deliberate warning in ctype.h,
if one of the ctype functions is used with a char value.

Bottom line:  If you have char value called c, don't call islower(c),
call islower ((unsigned char) c).  Otherwise, expect undefined behaviour.


Corinna

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ctype warnings

[Corinna Vinschen]

On Apr 11 15:46, Ruben Van Boxem wrote:
 2013/4/11 Earnie Boyd ear...@users.sourceforge.net
  On Thu, Apr 11, 2013 at 6:08 AM, Corinna Vinschen wrote:
   That means, if you give a char to this function, on machines on which
   char is a *signed* type, you make a mistake.  All char values  127
   are negative int values, and automatic casting to int will still result
   in negative values.  Negative values are very certainly not within the
   range of the unsigned char type.
 
 
 There are no char values  127 for an 8-bit signed char. See below for the
 conversion to unsigned char.

Of course not.  I had wrongly assumed this woudn't be taken literally
but in the sense as it was meant.

  Given Corrina's excellent exposé the examples on the opengroup page
  are incorrect.  Perhaps someone should point that out to them?
 
 
 I don't agree. Quoting the C++ standard (which may or may not be equivalent
 to the C standard on this point)

It's not.  The underlying function either takes an int value in the
range EOF, 0..255, or the result is undefined.  Of course a conversion
from char to int is well defined, but it doesn't automatically make
a wrong usage of a function right.


Corinna

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
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/cygwin] Fix intrin.h and intrinsics to be buildable on Cygwin

[Corinna Vinschen]

On Apr  6 17:54, Ruben Van Boxem wrote:
 2013/4/5 Corinna Vinschen vinsc...@redhat.com
 
  On Apr  5 12:15, Kai Tietz wrote:
   2013/4/5 Corinna Vinschen vinsc...@redhat.com:
On Apr  5 11:39, Kai Tietz wrote:
Hi Corinna,
   
well I dislike this __CYGWIN__ define mess here, but I admit I don't
   
It's only eight ifndef __CYGWIN__ blocks, not really a mess, IMHO.
Alternatively we could move all declaration colliding with POSIX into a
single block at the start of intrin.h and guard it with a single
#ifndef, plus a comment to tell people to put POSIX declarations always
into this block.
  
   True, there are only 8 of them.  The idea to move them into a single
   block sounds good to me.
 
  Applied with that change.  I just left the setjmp stuff intact since it
  seemed strange to move it, too.  But if you like I can pull that into
  the cygwin block as well, no worries.
 
 
 
 Building trunk crt gives me this error:
 
 i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
 -I/home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt  -m32
 -I/home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt/include -D_CRTBLD
 -I/usr/i686-w64-mingw32/include  -pipe -std=gnu99 -Wall -Wextra -Wformat
 -Wstrict-aliasing -Wshadow -Wpacked -Winline
 -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g
 -O2 -MT intrincs/lib32_libkernel32_a-membarrier.o -MD -MP -MF
 intrincs/.deps/lib32_libkernel32_a-membarrier.Tpo -c -o
 intrincs/lib32_libkernel32_a-membarrier.o `test -f 'intrincs/membarrier.c'
 || echo
 '/home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt/'`intrincs/membarrier.c
 /home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt/intrincs/membarrier.c:
 In function 'MemoryBarrier':
 /home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt/intrincs/membarrier.c:5:5:
 error: unknown type name '__LONG32'
  __LONG32 Barrier = 0;
  ^
 
 I think something was missed.

Indeed.  I tested on 64 bit only.  membarrier.c is only built for 32 bit
and it's the only intrinsics source not including intrin.h.

Two solutions:

- Either add #include intrin.h to membarrier.c,

- or revert all __LONG32 to long in 32bit-only intrinsics.

Whatever the maintainers prefer.


Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
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/cygwin] Fix intrin.h and intrinsics to be buildable on Cygwin

[Corinna Vinschen]

On Apr  6 18:34, Kai Tietz wrote:
 2013/4/6 Corinna Vinschen vinsc...@redhat.com:
  On Apr  6 17:54, Ruben Van Boxem wrote:
  Building trunk crt gives me this error:
 [...]
  /home/ruben/AUR/mingw-w64-crt-svn/src/mingw-w64-crt/intrincs/membarrier.c:5:5:
  error: unknown type name '__LONG32'
   __LONG32 Barrier = 0;
   ^
 
  I think something was missed.
 
  Indeed.  I tested on 64 bit only.  membarrier.c is only built for 32 bit
  and it's the only intrinsics source not including intrin.h.
 
  Two solutions:
 
  - Either add #include intrin.h to membarrier.c,
 
  - or revert all __LONG32 to long in 32bit-only intrinsics.
 
  Whatever the maintainers prefer.
 
 
  Corinna
 
 I prefer to add the header-include.

Done.  I also added the for x86 only comment as all other x86-only
files have.


Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
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/cygwin] Fix intrin.h and intrinsics to be buildable on Cygwin

[Corinna Vinschen]

On Apr  5 11:39, Kai Tietz wrote:
 Hi Corinna,
 
 well I dislike this __CYGWIN__ define mess here, but I admit I don't

It's only eight ifndef __CYGWIN__ blocks, not really a mess, IMHO.
Alternatively we could move all declaration colliding with POSIX into a
single block at the start of intrin.h and guard it with a single
#ifndef, plus a comment to tell people to put POSIX declarations always
into this block.


Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
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/cygwin] Fix intrin.h and intrinsics to be buildable on Cygwin

[Corinna Vinschen]

On Apr  5 12:15, Kai Tietz wrote:
 2013/4/5 Corinna Vinschen vinsc...@redhat.com:
  On Apr  5 11:39, Kai Tietz wrote:
  Hi Corinna,
 
  well I dislike this __CYGWIN__ define mess here, but I admit I don't
 
  It's only eight ifndef __CYGWIN__ blocks, not really a mess, IMHO.
  Alternatively we could move all declaration colliding with POSIX into a
  single block at the start of intrin.h and guard it with a single
  #ifndef, plus a comment to tell people to put POSIX declarations always
  into this block.
 
 True, there are only 8 of them.  The idea to move them into a single
 block sounds good to me.

Applied with that change.  I just left the setjmp stuff intact since it
seemed strange to move it, too.  But if you like I can pull that into
the cygwin block as well, no worries.


Thanks,
Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

Hi,

On Mar 15 16:14, Corinna Vinschen wrote:
 On Mar 15 06:09, JonY wrote:
  On 3/14/2013 23:52, Corinna Vinschen wrote:
   
   What two build systems?  It's a fairly simple patch which allows the
   normal user of mingw64 to build the entire source tree in a single
   `configure; make; make install', nothing more, nothing less.  I don't
   understand why the unnecessary complicated 2-stage process is enforced.
   
   
  
  After having some proper sleep and looking at your patch again, I can
  see what you are trying to do.
  
  Please keep the changes to the top level configure, pass the -I
  arguments to the lower levels. None of the lower modules have any
  business getting too familiar with each other.
 
 I think NightStrike is already looking into this, so I shut up for now.
 Feel free to ping me if I I'm supposed to do something in this matter.

Is there some progress in this matter, which allows to build the headers
and crt in a single configure/make run?  Just asking...


Thanks,
Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch/cygwin]: Add crt/intrin.h to the list of installed w32api headers

[Corinna Vinschen]

Hi,

now that Cygwin also provides the intrinsics, it also needs the intrin.h
header to build crt without parallel header files.  The intrin.h header
just needs a minor tweak to exclude setjmp definitions.  The below patch
implements that.

Ok to apply?


Thanks,
Corinna


* crt/intrin.h: Exclude setjmp stuff when bulding under Cygwin.
* configure.ac (BASEHEAD_LIST): Add crt/intrin.h.
* configure: Regenerate.


Index: crt/intrin.h
===
--- crt/intrin.h(revision 5723)
+++ crt/intrin.h(working copy)
@@ -8,7 +8,11 @@
 #ifndef RC_INVOKED
 
 #include crtdefs.h
+#ifdef __CYGWIN__
+#define USE_NO_MINGW_SETJMP_TWO_ARGS
+#else
 #include setjmp.h
+#endif
 #include stddef.h
 
 #if defined(__GNUC__)  \
@@ -341,7 +345,9 @@
 __MACHINEIA64(void __lfetchfault_excl(int,void const *))
 __MACHINEIA64(__MINGW_EXTENSION __int64 __load128(void *,__int64 *))
 __MACHINEIA64(__MINGW_EXTENSION __int64 __load128_acq(void *,__int64 *))
+#ifndef __CYGWIN__
 __MACHINEZ(void __cdecl longjmp(jmp_buf,int))
+#endif
 
 #pragma push_macro (_lrotl)
 #undef _lrotl
Index: configure.ac
===
--- configure.ac(revision 5723)
+++ configure.ac(working copy)
@@ -39,7 +39,7 @@
 
 # Checks for header files.
 
-BASEHEAD_LIST=crt/_bsd_types.h crt/_cygwin.h crt/_mingw.h crt/_mingw_mac.h 
crt/_mingw_print_push.h crt/_mingw_print_pop.h crt/_mingw_secapi.h 
crt/_mingw_unicode.h crt/_timeval.h crt/crtdefs.h crt/excpt.h crt/vadefs.h 
$srcdir/include/*.h
+BASEHEAD_LIST=crt/_bsd_types.h crt/_cygwin.h crt/_mingw.h crt/_mingw_mac.h 
crt/_mingw_print_push.h crt/_mingw_print_pop.h crt/_mingw_secapi.h 
crt/_mingw_unicode.h crt/_timeval.h crt/crtdefs.h crt/excpt.h crt/intrin.h 
crt/vadefs.h $srcdir/include/*.h
 SECHEAD_LIST=$srcdir/crt/sec_api/stralign_s.h
 for i in dlg h16 hxx rh ver; do
   BASEHEAD_LIST=$BASEHEAD_LIST $srcdir/include/*.$i

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
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/cygwin]: Add crt/intrin.h to the list of installed w32api headers

[Corinna Vinschen]

On Apr  4 17:45, Corinna Vinschen wrote:
 Hi,
 
 now that Cygwin also provides the intrinsics, it also needs the intrin.h
 header to build crt without parallel header files.  The intrin.h header
 just needs a minor tweak to exclude setjmp definitions.  The below patch
 implements that.
 
 Ok to apply?

No, it's not.  There's more stuff necessary to make it work in a Cygwin
environment.  The problem is the usage of long in the declarations and
definitions of the intrinsic functions.  To make this work on 64 bit
Cygwin, the long's have to be convert to __LONG32, similar to the
changes for 64 bit Cygwin last year.  I'm going to work on that.


Corinna

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a

[Corinna Vinschen]

Hi,

today we got a report on the cygwin-developers mailing list, which
reported that linking a certain library fails, because some of the
inline functions in winnt.h can't be resolved by the linker under
Cygwin:

  http://cygwin.com/ml/cygwin-developers/2013-04/msg00010.html

The problem here is that the intrinsics are linked into libmingwex.a,
but libmingwex.a doesn't exist in the w32api and thuis isn't available
under Cygwin.

Kai and I discussed this privatly on IRC and we came to the conclusion
that the most generic solution is to include the intrinsics in
libkernel32.a, rather than in libmingwex.a.  This allows to link against
the intrinsics on both platforms, Mingw-w64 as well as Cygwin.  

It also matches the expectations of application programmers when reading
MSDN.  Apart from the fact that the functions are implemented as
compiler intrinsics, their documentation on MSDN claims their
availability in kernel32.lib, see, for instance,
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683597%28v=vs.85%29.aspx,
in the Requirements section.

The below patch implements this.  It strips the intrinsic functions
from the src_libmingwex variable and introduces a src_intrincs
variable instead.  It also renames src_libmingwex32 and src_libmingwex64
to src_intrincs32 and src_intrincs64.  Then it adds rules for building
libkernel32.a for 32 and 64 bit targets, and includes the intrinsics
functions to their sources.

Is that ok to check in?


Thanks,
Corinna


* Makefile.am (src_libmingwex): Split off intrinsic functions
into...
(src_intrincs): ...this new variable.
(src_intrincs64): Rename from src_libmingwex64.
(src_intrincs32): Rename from src_libmingwex32.
(lib32_LIBRARIES): Add lib32/libkernel32.a.
(lib32_libkernel32_a_SOURCES): New variable.
(lib32_libkernel32_a_CPPFLAGS): New variable.
(lib32_DATA): Remove lib32/libkernel32.a.
(lib64_LIBRARIES): Add lib64/libkernel32.a.
(lib64_libkernel32_a_SOURCES): New variable.
(lib64_libkernel32_a_CPPFLAGS): New variable.
(lib64_DATA): Remove lib64/libkernel32.a.


Index: Makefile.am
===
--- Makefile.am (revision 5712)
+++ Makefile.am (working copy)
@@ -217,21 +217,6 @@
   stdio/vscanf.c   stdio/vsnprintf.c stdio/vsnprintf_s.c  
stdio/vsnwprintf.cstdio/vsscanf.c \
   stdio/vswscanf.c stdio/vwscanf.c   stdio/wtoll.c\
   \
-  intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c   
  intrincs/__stosb.c   intrincs/__stosd.c\
-  intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c   
  intrincs/bitscanfwd.cintrincs/bitscanrev.c \
-  intrincs/bittest.cintrincs/bittestc.c   intrincs/bittestci.c 
  intrincs/bittestr.c  intrincs/bittestri.c  \
-  intrincs/bittests.c   intrincs/bittestsi.c  intrincs/cpuid.c 
  intrincs/currentfiber.c  intrincs/currentteb.c \
-  intrincs/fiberdata.c  intrincs/ilockadd.c   intrincs/ilockand.c  
  intrincs/ilockand64.cintrincs/ilockcxch.c  \
-  intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.c  
  intrincs/ilockdec.c  intrincs/ilockdec16.c \
-  intrincs/ilockdec64.c intrincs/ilockexch.c  intrincs/ilockexch64.c   
  intrincs/ilockexchadd.c  intrincs/ilockexchadd64.c \
-  intrincs/ilockexchptr.c   intrincs/ilockinc.c   intrincs/ilockinc16.c
  intrincs/ilockinc64.cintrincs/ilockor.c\
-  intrincs/ilockor64.c  intrincs/ilockxor.c   intrincs/ilockxor64.c
  intrincs/inbyte.cintrincs/inbytestring.c   \
-  intrincs/indword.cintrincs/indwordstring.c  intrincs/inword.c
  intrincs/inwordstring.c  intrincs/outbyte.c\
-  intrincs/outbytestring.c  intrincs/outdword.c   
intrincs/outdwordstring.c  intrincs/outword.c   intrincs/outwordstring.c  \
-  intrincs/rdtsc.c  intrincs/readcr0.cintrincs/readcr2.c   
  intrincs/readcr3.c   intrincs/readcr4.c\
-  intrincs/readcr8.cintrincs/readmsr.cintrincs/writecr0.c  
  intrincs/writecr2.c  intrincs/writecr3.c   \
-  intrincs/writecr4.c   intrincs/writecr8.c   intrincs/writemsr.c  
  intrincs/RtlSecureZeroMemory.c \
-  \
   secapi/_cgets_s.c secapi/_cgetws_s.c \
   secapi/_cprintf_s.c secapi/_cprintf_s_l.c \
   secapi/_vcprintf_s.c secapi/_vcprintf_s_l.c \
@@ -249,8 +234,25 @@
   secapi/_strtime_s.c secapi/_wstrtime_s.c \
   secapi/wmemcpy_s.c secapi/memcpy_s.c
 
+# These intrinsics are target independent:
+src_intrincs= \
+  intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c   
  intrincs/__stosb.c   intrincs/__stosd.c\
+  intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c   
  intrincs/bitscanfwd.c

Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a

[Corinna Vinschen]

On Apr  2 03:00, NightStrike wrote:
 On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote:
  The below patch implements this.  It strips the intrinsic functions
  from the src_libmingwex variable and introduces a src_intrincs
  variable instead.  It also renames src_libmingwex32 and src_libmingwex64
  to src_intrincs32 and src_intrincs64.  Then it adds rules for building
  libkernel32.a for 32 and 64 bit targets, and includes the intrinsics
  functions to their sources.
 
  Is that ok to check in?
 
 I have nothing to offer on the concept behind the patch.  However, I
 do feel the need to point out that with this patch, dlltool will no
 longer run to process the kernel32.def file when building
 libkernel32.a.  There are two cases where we incorporate a def file
 into a lib.  The easiest is when there are no other sources, and that
 is handled by the general make rule, ie:
 
 lib32/lib%.a: lib32/%.def
 $(DTDEF32) $
 [...]
 I admit that the above situation isn't ideal, but the autotools don't
 really actively support windows-isms like dlltool.  They said they
 would review a patch if I wrote it, but I don't know perl yet :(
 
  -lib32_LIBRARIES = lib32/libshell32.a
  +lib32_LIBRARIES = lib32/libkernel32.a
  +lib32_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs32)
  +lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)
 
 Stick it in here
 
  +lib64_LIBRARIES = lib64/libkernel32.a
  +lib64_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs64)
  +lib64_libkernel32_a_CPPFLAGS=$(CPPFLAGS64) -D_SYSCRT=1 -DCRTDLL=1 
  $(extra_include) $(AM_CPPFLAGS)
 
 And here

Ok, done.  The order of the variables is different between 32 and 64
bit.  I did it the same way as in the following shell32.a rule for the
same target to align to the surrounding style.

 On a second note   the CPPFLAGS lines are different.  Why are
 _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit
 case?  And why not including sys_includes?  Do the intrinsics not
 depend on mingw-w64-headers, only the internal crt headers?  Any
 answer is ok to these last questions, as long as you have an answer :)

Uhm... well, the answer *I* have is this:  I fat-fingered my copy/paste.
I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS,
but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS,
accidentally.  Sorry about that and thanks for catching.  This is fixed
in the below updated patch.


Thanks,
Corinna


* Makefile.am (src_libmingwex): Split off intrinsic functions
into...
(src_intrincs): ...this new variable.
(src_intrincs64): Rename from src_libmingwex64.
(src_intrincs32): Rename from src_libmingwex32.
(lib32_LIBRARIES): Add lib32/libkernel32.a.
(lib32_libkernel32_a_SOURCES): New variable.
(lib32_libkernel32_a_AR): New variable.
(lib32_libkernel32_a_CPPFLAGS): New variable.
(lib32_DATA): Remove lib32/libkernel32.a.
(lib64_LIBRARIES): Add lib64/libkernel32.a.
(lib64_libkernel32_a_SOURCES): New variable.
(lib64_libkernel32_a_CPPFLAGS): New variable.
(lib64_libkernel32_a_AR): New variable.
(lib64_DATA): Remove lib64/libkernel32.a.


Index: Makefile.am
===
--- Makefile.am (revision 5712)
+++ Makefile.am (working copy)
@@ -217,21 +217,6 @@
   stdio/vscanf.c   stdio/vsnprintf.c stdio/vsnprintf_s.c  
stdio/vsnwprintf.cstdio/vsscanf.c \
   stdio/vswscanf.c stdio/vwscanf.c   stdio/wtoll.c\
   \
-  intrincs/__movsb.cintrincs/__movsd.cintrincs/__movsw.c   
  intrincs/__stosb.c   intrincs/__stosd.c\
-  intrincs/__stosw.cintrincs/_rotl64.cintrincs/_rotr64.c   
  intrincs/bitscanfwd.cintrincs/bitscanrev.c \
-  intrincs/bittest.cintrincs/bittestc.c   intrincs/bittestci.c 
  intrincs/bittestr.c  intrincs/bittestri.c  \
-  intrincs/bittests.c   intrincs/bittestsi.c  intrincs/cpuid.c 
  intrincs/currentfiber.c  intrincs/currentteb.c \
-  intrincs/fiberdata.c  intrincs/ilockadd.c   intrincs/ilockand.c  
  intrincs/ilockand64.cintrincs/ilockcxch.c  \
-  intrincs/ilockcxch16.cintrincs/ilockcxch64.cintrincs/ilockcxchptr.c  
  intrincs/ilockdec.c  intrincs/ilockdec16.c \
-  intrincs/ilockdec64.c intrincs/ilockexch.c  intrincs/ilockexch64.c   
  intrincs/ilockexchadd.c  intrincs/ilockexchadd64.c \
-  intrincs/ilockexchptr.c   intrincs/ilockinc.c   intrincs/ilockinc16.c
  intrincs/ilockinc64.cintrincs/ilockor.c\
-  intrincs/ilockor64.c  intrincs/ilockxor.c   intrincs/ilockxor64.c
  intrincs/inbyte.cintrincs/inbytestring.c   \
-  intrincs/indword.cintrincs/indwordstring.c  intrincs/inword.c
  intrincs/inwordstring.c

Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a

[Corinna Vinschen]

On Apr  2 11:05, NightStrike wrote:
 On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen vinsc...@redhat.com wrote:
  On Apr  2 03:00, NightStrike wrote:
  On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com 
  wrote:
  Ok, done.  The order of the variables is different between 32 and 64
  bit.  I did it the same way as in the following shell32.a rule for the
  same target to align to the surrounding style.
 
 Ok.  I have no idea why the lib32 ordering is different than lib64.
 Probably an oversight.
 
  On a second note   the CPPFLAGS lines are different.  Why are
  _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit
  case?  And why not including sys_includes?  Do the intrinsics not
  depend on mingw-w64-headers, only the internal crt headers?  Any
  answer is ok to these last questions, as long as you have an answer :)
 
  Uhm... well, the answer *I* have is this:  I fat-fingered my copy/paste.
  I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS,
  but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS,
  accidentally.  Sorry about that and thanks for catching.  This is fixed
  in the below updated patch.
 
 Looks good, thanks!

Thanks, applied.


Corinna

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

On Mar 15 06:09, JonY wrote:
 On 3/14/2013 23:52, Corinna Vinschen wrote:
  
  What two build systems?  It's a fairly simple patch which allows the
  normal user of mingw64 to build the entire source tree in a single
  `configure; make; make install', nothing more, nothing less.  I don't
  understand why the unnecessary complicated 2-stage process is enforced.
  
  
 
 After having some proper sleep and looking at your patch again, I can
 see what you are trying to do.
 
 Please keep the changes to the top level configure, pass the -I
 arguments to the lower levels. None of the lower modules have any
 business getting too familiar with each other.

I think NightStrike is already looking into this, so I shut up for now.
Feel free to ping me if I I'm supposed to do something in this matter.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

On Mar 14 10:13, Corinna Vinschen wrote:
 Sorry, but I'm really confused about the unnecessary complexity.  I don't
 want to stage anything.  I would like to be able call
 
   configure --prefix=...
   make
   make install
 
 That's a pretty standard scenario.  But here's what happens: Try to
 build a full set of headers and libs for a Cygwin target:
 
   ${srcdir}/configure \
 --host=x86_64-w64-mingw32 \
 --prefix=/home/corinna/mingw \

That should have been --prefix=/home/corinna/mingw64 to match the below
error message.  Sorry.

 --enable-w32api
 
 As common as it looks, the build will fail:
 
   x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H \
 -I. \
 -I${srcdir}/mingw-w64-crt  \
 -m32 \
 -I/home/corinna/mingw64/include   \
 [...] -g -O2 [...] \
 -c -o libsrc/lib32_libwmcodecdspuuid_a-wmcodecdspuuid.o \
 [...]/wmcodecdspuuid.c
   ${srcdir}/mingw-w64-crt/libsrc/wmcodecdspuuid.c:8:24: fatal error: 
 wmcodecdsp.h: No such file or directory
   compilation terminated.
 
 The reason is obvious.  The -I don't include the headers within the
 same src tree, and they don't contain the generated headers within
 the same build tree *even though thay are available*.
 
 It simply doesn't make sense to require having a copy of these headers
 installed to some arbitrary sysroot dir, just to be able to build crt.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

On Mar 14 11:13, m...@morous.org wrote:
 
 
  You *have* to install the headers first as a prerequisite for the crt to
  work. There are generated headers required for the CRT, not a plain and
  simple -I.
 
 Many packages generate headers or some sources. Consider config.h.in -
 config.h as the most common case. I cannot see that as a reason for
 increased build complexity. There just implies one extra level of
 dependencies in (generated) Makefile.

Exactly.  Also, the just built headers *are* taken into account by my
patch, because they are included as well.  I don't see why we need a 
two stage build at all, if a one stage build can do the right thing
out of the box.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

On Mar 14 10:53, NightStrike wrote:
 On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote:
  On Mar 13 16:18, NightStrike wrote:
  On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com 
  wrote:
   Hi,
  
   I'd like to resurrect a patch which has been refused last year, but
   I think it's still helpful and maybe the opinions have changed a bit.
 
  Sorry.. did I refuse it?  Can you link to the mailing list archive (I
  understand that the SF interface blows for that...)
 
 No link?  I tried to find it and could not.

Do we really need that?  I didn't keep a local copy and searching the
ML archive sucks.

  I'm a little confused here.  What we require, ie, the only situation
  that we support, is when the version of the headers is the same
  version of the crt.  Ie, svn checkout revision.  Anything outside of
  that will probably work, of course, but nobody tests it.
 
  Sure, I'm not claiming anything else, nor am I trying to do anything
  else.  I want to build a full mingw tree, without having to have
  anything installed outside the source or build tree.
 
 When you say full mingw tree, do you mean that you are building crt,
 headers, and tools using the top level configure/make, as opposed to
 building each thing you want independently?

Exactly.  Doing that is a fairly typical scenario, isn't it?

  Now, in terms of the configure test that errors out in the case of not
  finding _mingw_mac.h, that is due to the fact that the headers are
  required to build the crt.  We don't care where they are, we just care
  that they exist.  If they don't, the crt build will be all fouled up.
 
  I'm puzzeled.  That has nothing to do with my patch.
 
 Your patch changed when it errored out.

Sorry?  When did my patch change?  When did it error out?  I realy don't
understand what you're talking about.

  The default, of course, is for the headers to exist in the sysroot
  that the crt is getting installed into.  This is a fairly common usage
  pattern, and modeled after the gcc build.  If they're somewhere else
  instead, you can just use --with-sysroot=some/wheres/else
 
  In fact, the help text for with-sysroot even says this:
   --with-sysroot=DIR   Search for headers within DIR/include
 
  So if you for whatever reason want to stage a build of
  mingw-w64-headers in /tmp/my/dir, you just build the crt with
  --with-sysroot=/tmp/my/dir
 
  Does that not work for you?
 
  Sorry, but I'm really confused about the unnecessary complexity.  I don't
  want to stage anything.  I would like to be able call
 
configure --prefix=...
make
make install
 
 Which configure are we talking about in all of this?  I thought you
 were always asking about the crt configure, but I'm getting the
 feeling that you're really asking about the top level configure.

The crt configurey needs a change to be able to build a full mingw
tree from top level.  I thought that was clear.  Only building crt
without the headers makes only marginal sense.  My below example
shows that:

  That's a pretty standard scenario.  But here's what happens: Try to
  build a full set of headers and libs for a Cygwin target:


 
${srcdir}/configure \
  --host=x86_64-w64-mingw32 \
  --prefix=/home/corinna/mingw \
  --enable-w32api
 
  As common as it looks, the build will fail:
 
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H \
  -I. \
  -I${srcdir}/mingw-w64-crt  \
  -m32 \
  -I/home/corinna/mingw64/include   \
  [...] -g -O2 [...] \
  -c -o libsrc/lib32_libwmcodecdspuuid_a-wmcodecdspuuid.o \
  [...]/wmcodecdspuuid.c
${srcdir}/mingw-w64-crt/libsrc/wmcodecdspuuid.c:8:24: fatal error: 
  wmcodecdsp.h: No such file or directory
compilation terminated.
 
  The reason is obvious.  The -I don't include the headers within the
  same src tree, and they don't contain the generated headers within
  the same build tree *even though thay are available*.
 
  It simply doesn't make sense to require having a copy of these headers
  installed to some arbitrary sysroot dir, just to be able to build crt.

Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] winbase.h: Define missing PIPE_xxx_REMOTE_CLIENTS

[Corinna Vinschen]

On Mar 14 16:29, Corinna Vinschen wrote:
 Hi,
 
 the below patch defines the missing PIPE_ACCEPT_REMOTE_CLIENTS and
 PIPE_REJECT_REMOTE_CLIENTS defines available since Vista.
 
 Ok to apply?
 
 Thx,
 Corinna
 
 
   * winbase.h (PIPE_ACCEPT_REMOTE_CLIENTS): Define when building for
   Vista or later.
   (PIPE_REJECT_REMOTE_CLIENTS): Ditto.
 
 
 Index: winbase.h
 ===
 --- winbase.h (revision 5656)
 +++ winbase.h (working copy)
 @@ -140,6 +140,10 @@
  #define PIPE_READMODE_MESSAGE 0x2
  #define PIPE_TYPE_BYTE 0x0
  #define PIPE_TYPE_MESSAGE 0x4
 +#if (_WIN32_WINNT = 0x0600)
 +#define PIPE_ACCEPT_REMOTE_CLIENTS 0x0
 +#define PIPE_REJECT_REMOTE_CLIENTS 0x8
 +#endif
  
  #define PIPE_UNLIMITED_INSTANCES 255
  

ALong the same lines, I just noticed that ddk/ntifs.h defines
FILE_PIPE_ACCEPT_REMOTE_CLIENTS and FILE_PIPE_REJECT_REMOTE_CLIENTS
twice in a row.  The below patch removes one set.

Ok?
Corinna


* ddk/include/ddk/ntifs.h (FILE_PIPE_ACCEPT_REMOTE_CLIENTS): Remove
duplicate.
(FILE_PIPE_REJECT_REMOTE_CLIENTS): Ditto.


Index: ddk/include/ddk/ntifs.h
===
--- ddk/include/ddk/ntifs.h (revision 5656)
+++ ddk/include/ddk/ntifs.h (working copy)
@@ -2874,8 +2874,6 @@
 #define FILE_PIPE_ACCEPT_REMOTE_CLIENTS 0x
 #define FILE_PIPE_REJECT_REMOTE_CLIENTS 0x0002
 
-#define FILE_PIPE_ACCEPT_REMOTE_CLIENTS 0x
-#define FILE_PIPE_REJECT_REMOTE_CLIENTS 0x0002
 #define FILE_PIPE_TYPE_VALID_MASK   0x0003
 
 #define FILE_PIPE_BYTE_STREAM_MODE  0x

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] winbase.h: Define missing PIPE_xxx_REMOTE_CLIENTS

[Corinna Vinschen]

On Mar 14 16:41, Kai Tietz wrote:
 2013/3/14 Corinna Vinschen vinsc...@redhat.com:
  Hi,
 
  the below patch defines the missing PIPE_ACCEPT_REMOTE_CLIENTS and
  PIPE_REJECT_REMOTE_CLIENTS defines available since Vista.
 
  Ok to apply?
 
  Thx,
  Corinna
 
 
  * winbase.h (PIPE_ACCEPT_REMOTE_CLIENTS): Define when building for
  Vista or later.
  (PIPE_REJECT_REMOTE_CLIENTS): Ditto.
 
 Patch is ok.  I have just one nit here.  Not sure if we add here the
 guard for Vista (Longhorn) at all for the define.

The flags are only available for Vista and later, so it would make sense,
wouldn't it?  AFAIK older OSes would return with ERROR_INVALID_ARGUMENT.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] winbase.h: Define missing PIPE_xxx_REMOTE_CLIENTS

[Corinna Vinschen]

On Mar 14 16:49, Corinna Vinschen wrote:
 On Mar 14 16:41, Kai Tietz wrote:
  2013/3/14 Corinna Vinschen vinsc...@redhat.com:
   Hi,
  
   the below patch defines the missing PIPE_ACCEPT_REMOTE_CLIENTS and
   PIPE_REJECT_REMOTE_CLIENTS defines available since Vista.
  
   Ok to apply?
  
   Thx,
   Corinna
  
  
   * winbase.h (PIPE_ACCEPT_REMOTE_CLIENTS): Define when building for
   Vista or later.
   (PIPE_REJECT_REMOTE_CLIENTS): Ditto.
  
  Patch is ok.  I have just one nit here.  Not sure if we add here the
  guard for Vista (Longhorn) at all for the define.
 
 The flags are only available for Vista and later, so it would make sense,
 wouldn't it?  AFAIK older OSes would return with ERROR_INVALID_ARGUMENT.

Um... ERROR_INVALID_PARAMETER


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
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] Prefer to use local headers over installed headers

[Corinna Vinschen]

On Mar 14 15:00, NightStrike wrote:
 On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com 
 wrote:
  On Mar 14 10:53, NightStrike wrote:
  On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com 
  wrote:
   On Mar 13 16:18, NightStrike wrote:
   On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com 
   wrote:
  When you say full mingw tree, do you mean that you are building crt,
  headers, and tools using the top level configure/make, as opposed to
  building each thing you want independently?
 
  Exactly.  Doing that is a fairly typical scenario, isn't it?
 
 Actually, no.  Pretty much nobody uses the top level configure.  It
 was an idea that I had that nobody really wanted, and so it fell into
 disuse and doesn't really work (which I guess is what you are seeing).

The top-level configure works excellent for creating the w32api
installation, except for the missing header file paths.

 Your patch moved the criteria for erroring out on the non-existence of
 mingw_mac.h:
 
 -AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if
 the mingw-w64 header set and the build/host option are set
 properly.])])
 +AS_CASE([$with_headers],
 +  [yes],[],
 +  [AC_CHECK_HEADER([_mingw_mac.h],
 +   [],
 +   [AC_MSG_ERROR([Please check if the mingw-w64
 header set and the build/host option are set properly.])])])
 
 After your patch, configure won't always verify that the headers are
 usable for building crt.

The criteria are pretty clear, so maybe I just didn't create the test
correctly:

- Either we're building a full tree with headers and crt, then the
  we don't need the test for _mingw_mac.h, because it will be
  created early enough while building the headers.

- Or we're building a standalone crt, then the _mingw_mac.h test is ok.

So, to get that right, the crt configure just needs to know if we're
building with in-tree headers or not.

I'd appreciate it very much if that could be done to allow an easy
single-stage build of the full tree.


Corinna

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch] Prefer to use local headers over installed headers

[Corinna Vinschen]

Hi,

I'd like to resurrect a patch which has been refused last year, but
I think it's still helpful and maybe the opinions have changed a bit.

For people building just the latest mingw64-headers and mingw64-crt,
it's kind of surprising that mingw64-crt requires that the headers
are already installed.  In theory, the right thing to do should be
that mingw64-crt is build after mingw64-headers, and then prefer the
just built in-tree headers over the already installed headers.  The
below patch does that, unless the --without-headers option is set.

This should work in all typical scenarios:

- cross build gcc:

  The headers have to be build first.  At the time crt gets build,
  the in-tree headers already have been built for gcc, so they
  are nicely available for the crt build.

- native build gcc:

  The installed headers are potentially old.  Building crt with the
  latest in-tree headers is preferrable to circumnavigate potential
  bugs in the older headers.

- native mingw-only build:

  Same as above.

I can't come up with a scenario in which it would be bad to use the
in-tree headers, unless you don't build the headers, but crt only.
This should be fixable, shouldn't it?


TIA,
Corinna


* configure.ac: Add --without-headers option.  Set WITH_LOCAL_HEADERS
by default unless no parallel mingw-w64-headers directory exists.
* configure: Regenerate.
* Makefile.am: Add local header paths to sysincludes if
WITH_LOCAL_HEADERS is set.


Index: configure.ac
===
--- configure.ac(revision 5645)
+++ configure.ac(working copy)
@@ -45,6 +45,19 @@
 dnl ---
 AM_PROG_CC_C_O
 
+AC_MSG_CHECKING([whether to use the local in-tree headers])
+AC_ARG_WITH([headers],
+  [AS_HELP_STRING([--without-headers],
+[Do not use the in-tree mingw-w64 headers])],
+  [],
+  [with_headers=`test -d ${srcdir}/../mingw-w64-headers  echo yes || echo 
no`])
+AC_MSG_RESULT([$with_headers])
+AS_CASE([$with_headers],
+  [no],[],
+  [yes],[AS_VAR_SET([WITH_LOCAL_HEADERS])],
+  [AC_MSG_ERROR([invalid argument.  Must be either yes or no.])])
+AM_CONDITIONAL([WITH_LOCAL_HEADERS], [AS_VAR_TEST_SET([WITH_LOCAL_HEADERS])])
+
 AC_MSG_CHECKING([whether to build a w32api package for Cygwin])
 AC_ARG_ENABLE([w32api],
   [AS_HELP_STRING([--enable-w32api],
@@ -228,7 +241,11 @@
 #AC_FUNC_VPRINTF
 #AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate gettimeofday 
isascii localeconv mbrlen memmove memset pow rint setlocale sqrt strcasecmp 
strchr strncasecmp strtoull strtoumax])
 
-AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
+AS_CASE([$with_headers],
+  [yes],[],
+  [AC_CHECK_HEADER([_mingw_mac.h],
+   [],
+   [AC_MSG_ERROR([Please check if the mingw-w64 header set and 
the build/host option are set properly.])])])
 
 #Warnings and errors, default level is 3
 AC_MSG_CHECKING([for warning levels])
Index: Makefile.am
===
--- Makefile.am (revision 5645)
+++ Makefile.am (working copy)
@@ -12,11 +12,17 @@
 
 #AUTOMAKE_OPTIONS = color-tests
 
+if WITH_LOCAL_HEADERS
+local_headers=-I$(abs_top_srcdir)/../mingw-w64-headers/crt 
-I$(abs_top_srcdir)/../mingw-w64-headers/include 
-I$(abs_builddir)/../mingw-w64-headers 
-I$(abs_builddir)/../mingw-w64-headers/crt
+else
+local_headers=
+endif
+sysincludes=$(local_headers)
+
 if WITHSYSROOT
-  sysincludes=-I@TARGET_SYSTEM_ROOT@/include
+  sysincludes+=-I@TARGET_SYSTEM_ROOT@/include
   withsys=--with-sysroot=@TARGET_SYSTEM_ROOT@
 else
-  sysincludes=
   withsys=
 endif
 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch] lmaccess.h: Add ServiceAccount functions

[Corinna Vinschen]

Hi,

the below patch adds the missing Net...ServiceAccount functions to
lmaccess.h.  The prototypes and the flag value are based on the MSDN
documentation.

Ok to apply?


Thanks,
Corinna


* lmaccess.h (SERVICE_ACCOUNT_FLAG_LINK_TO_HOST_ONLY): Define.
(NetAddServiceAccount): Add prototype.
(NetRemoveServiceAccount): Ditto.
(NetIsServiceAccount): Ditto.
(NetEnumerateServiceAccounts): Ditto.


Index: include/lmaccess.h
===
--- include/lmaccess.h  (revision 5627)
+++ include/lmaccess.h  (working copy)
@@ -881,6 +881,13 @@
   MSA_INFO_STATE State;
 } MSA_INFO_0, *PMSA_INFO_0;
 
+#define SERVICE_ACCOUNT_FLAG_LINK_TO_HOST_ONLY 0x0001
+
+  NTSTATUS WINAPI NetAddServiceAccount (LPWSTR ServerName,LPWSTR 
AccountName,LPWSTR Reserved,DWORD Flags);
+  NTSTATUS WINAPI NetRemoveServiceAccount (LPWSTR ServerName,LPWSTR 
AccountName,DWORD Flags);
+  NTSTATUS WINAPI NetIsServiceAccount (LPWSTR ServerName,LPWSTR 
AccountName,BOOL *IsService);
+  NTSTATUS WINAPI NetEnumerateServiceAccounts (LPWSTR ServerName,DWORD 
Flags,DWORD *AccountsCount, PZPWSTR *Accounts);
+
 #endif /*(_WIN32_WINNT = 0x0601)*/
 
 #ifdef __cplusplus

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
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] winnt.h: Only include x86intrin.h on Cygwin

[Corinna Vinschen]

On Dec 11 19:29, Kai Tietz wrote:
 Hi Corinna,
 
 Patch is ok.  I agree we should cleanup things here.
 
 Regards,
 Kai
 
 2012/12/11 Corinna Vinschen ...
  Hi,
 
  the below patch just removes the inclusio of a few GCC files on Cygwin.
  The reason is that the x86intrin.h header includes these files
  automatically, so we should better clean up winnt.h.  Ok to apply?
 
 
  Thanks,
  Corinna
 
 
  * winnt.h: Drop inclusion of mmintrin.h, emmintrin.h, and
  pmmintrin.h on Cygwin.

Thanks, applied.


Corinna


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [patch] winnt.h: Only include x86intrin.h on Cygwin

[Corinna Vinschen]

Hi,

the below patch just removes the inclusio of a few GCC files on Cygwin.
The reason is that the x86intrin.h header includes these files
automatically, so we should better clean up winnt.h.  Ok to apply?


Thanks,
Corinna


* winnt.h: Drop inclusion of mmintrin.h, emmintrin.h, and
pmmintrin.h on Cygwin.


Index: winnt.h
===
--- winnt.h (revision 5493)
+++ winnt.h (working copy)
@@ -1456,15 +1456,6 @@
 extern C {
 # endif
 # include x86intrin.h
-# ifdef __MMX__
-#  include mmintrin.h
-# endif
-# ifdef __SSE2__
-#  include emmintrin.h
-# endif
-# ifdef __SSE3__
-#  include pmmintrin.h
-# endif
 # if defined(__cplusplus)
 }
 # endif

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public