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\\
&
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 pointin
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
> >\\hos
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 allo
e()` 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. Ou
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
> > com
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
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.
S
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
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
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
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 V
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
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
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
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
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
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
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'
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:
> + *
> + *
>
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 D
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
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 iscyg
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
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, ra
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 ass
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
%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/i
On Aug 25 14:54, Jacek Caban wrote:
The patch looks good to me.
Thanks,
Jacek
Commited.
Thanks,
Corinna
pgpZ05TR9Rmqf.pgp
Description: PGP signature
--
___
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
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
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
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
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
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
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
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
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
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
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
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:
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
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,
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
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
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
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
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
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, Алексей
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
, 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
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
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
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:
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 211 matches
Mail list logo