Re: [Mingw-w64-public] PRIu64 and uint64_t
why would I want to use __mingw_printf? what exactly is it? why shouldn't I just use printf like I think I should (end-user's prospective)? normally I would see that and assume it's some sort of internal compiler-use thing and avoid it and just stick with the the standard c library or c++ library stuff. this is news to me, and I have been working with mingw-w64 for a few years now - lost count. new feature? From: JonY jo...@users.sourceforge.net To: mingw-w64-public@lists.sourceforge.net Sent: Monday, June 10, 2013 3:06 AM Subject: Re: [Mingw-w64-public] PRIu64 and uint64_t On 6/10/2013 14:07, Jim Michaels wrote: is there a way to detect compilation with --ansi or --posix? No, this should not be needed, the correct inttypes macro will be used corresponding to the printf set. C99 printf with __mingw_printf etc... I have not investigated this further. -- 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 -- 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] PRIu64 and uint64_t
-Original Message- From: Jim Michaels [mailto:jmich...@yahoo.com] Sent: Tuesday, June 11, 2013 9:23 AM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] PRIu64 and uint64_t why would I want to use __mingw_printf? what exactly is it? why shouldn't I just use printf like I think I should (end-user's prospective)? normally I would see that and assume it's some sort of internal compiler-use thing and avoid it and just stick with the the standard c library or c++ library stuff. http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf this is news to me, and I have been working with mingw-w64 for a few years now - lost count. new feature? I think that's an old problem. Regards Kai -- 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)
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] PRIu64 and uint64_t
On 6/11/2013 15:55, Koehne Kai wrote:
-Original Message-
From: Jim Michaels [mailto:jmich...@yahoo.com]
Sent: Tuesday, June 11, 2013 9:23 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] PRIu64 and uint64_t
why would I want to use __mingw_printf? what exactly is it? why shouldn't I
just use printf like I think I should (end-user's prospective)? normally I
would
see that and assume it's some sort of internal compiler-use thing and avoid
it
and just stick with the the standard c library or c++ library stuff.
http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf
libstdc++ (GCC C++ implementation) REQUIRES C99, especially to support
C++11, so these are staying whether used by the user or not.
The proper macro selection is done automatically, and in my case,
correctly depending on which feature set is requested. Example:
#include inttypes.h
#include stdio.h
int main(){
printf(% PRId64 \n, __INT64_MAX__);
printf(9223372036854775807LL\n);
return 0;
}
Notice PRId64 is replaced with C99 equivalents:
$ x86_64-w64-mingw32-gcc printf64.c -posix -E |tail
...
int main(){
printf(% lld \n, 9223372036854775807LL);
printf(9223372036854775807LL\n);
return 0;
}
Notice the default is still the MS %I64d for compatibility:
$ x86_64-w64-mingw32-gcc printf64.c -E |tail
...
int main(){
printf(% I64d \n, 9223372036854775807LL);
printf(9223372036854775807LL\n);
return 0;
}
this is news to me, and I have been working with mingw-w64 for a few years
now - lost count. new feature?
I think that's an old problem.
Old news, more than a few years old by now.
signature.asc
Description: OpenPGP digital signature
--
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)
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)
2013/6/11 Corinna Vinschen vinsc...@redhat.com 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 Yes this is my mistake it came from old MSYS dll. I fix it today. Regards, Alexey. -- 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)
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)
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)
-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.
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.
Now that you know what MSYS is about, it should be obvious that crude
symlink-by-copying is necessary to satisfy W32 tools, which cannot use
cygwin symlinks or Windows .lnk files.
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.
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
=iQw0
-END PGP SIGNATURE-
--
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)
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
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.
On Tue, Jun 11, 2013 at 12:43 PM, LRN lrn1...@gmail.com 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.
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.
Now that you know what MSYS is about, it should be obvious that crude
symlink-by-copying is necessary to satisfy W32 tools, which cannot use
cygwin symlinks or Windows .lnk files.
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.
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
=iQw0
-END PGP SIGNATURE-
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
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)
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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:58, Ray Donnelly wrote: 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. Just to make sure that facts (or my interpretation of them, anyway) are on the table: The so-called msysGit project is somewhat misnamed. The git that they build and distribute is actually a mingw-git (that is, a W32 git built with mingw-gcc and not linked to msys-1.dll), which is achieved by heaping lots of W32-specific patches on top of upstream git. With parts of MSYS1 bundled in. I'm not sure why they initially bundled MSYS1 with that git. They probably figured that without a *nix'y shell git doesn't feel git'ty. Or maybe git has mandatory shell scripts somewhere, and they needed bash to run them. mingw-git didn't exist back then (and they didn't switch to it later, when it appeared), so they had to update that bundled MSYS1 manually, and it went stale quickly as a result. Anyway, bundling a copy of MSYS1 wasn't enough for them, they also forked MSYS1 a bit (added partial unicode support, altered MSYS mangling to fit the needs of git better, etc). So far i haven't seen any arguments in favor of git being a W32 application rather than MSYS application. I was able to build msys-git (true msys-git, built with msys-gcc and msys headers, linked to msys-1.dll) recently, and it worked well enough for me. With MSYS2 that is not even a problem anymore, since MSYS2 inherits everything Cygwin has (including a well-maintained version of git). Therefore i hope that msysGit will simply die. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtxcsAAoJEOs4Jb6SI2Cwmr8H/3umAgeku/ModbMrJ39o2CAf c9+AfYLvYi9BaBA2BVSpOvqw4DwH+lE1N7Sf/v2dM/x/ufuPz/jSNWEJLSAEVAmW Jr9wUZzTSiQENCd5OiJBpJD68wOcF8wYVvI2f089uuPxDo7r+88FXHkNB6xm15xF 7+ZKxm/6185KMFkupTKVkYU1PvyZwYFcWbxvyuynahcLyLk/Szf4ydJWsNHGUF/r V8gF/Rt33hbsqhCySHWygdR8HkUIBIDvczRwDN9PfcaDu01VuVjSG04TjVBfttjk R21ySWOW/Qd0AopjSw9ndhWsWnx/nhDe/awumJ4o4NlceN3XjdXjODceLnabXoY= =7sz2 -END PGP SIGNATURE- -- 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)
On Tue, Jun 11, 2013 at 1:25 PM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:58, Ray Donnelly wrote: 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. Just to make sure that facts (or my interpretation of them, anyway) are on the table: The so-called msysGit project is somewhat misnamed. The git that they build and distribute is actually a mingw-git (that is, a W32 git built with mingw-gcc and not linked to msys-1.dll), which is achieved by heaping lots of W32-specific patches on top of upstream git. With parts of MSYS1 bundled in. Yes I think of it as msys-with-git rather than an MSYS git. I'm not sure why they initially bundled MSYS1 with that git. They probably figured that without a *nix'y shell git doesn't feel git'ty. Or maybe git has mandatory shell scripts somewhere, and they needed bash to run them. mingw-git didn't exist back then (and they didn't switch to it later, when it appeared), so they had to update that bundled MSYS1 manually, and it went stale quickly as a result. Anyway, bundling a copy of MSYS1 wasn't enough for them, they also forked MSYS1 a bit (added partial unicode support, altered MSYS mangling to fit the needs of git better, etc). So far i haven't seen any arguments in favor of git being a W32 application rather than MSYS application. I was able to build msys-git (true msys-git, built with msys-gcc and msys headers, linked to msys-1.dll) recently, and it worked well enough for me. With MSYS2 that is not even a problem anymore, since MSYS2 inherits everything Cygwin has (including a well-maintained version of git). Therefore i hope that msysGit will simply die. My main argument for git remaining a native program is that for programs that do a lot of file IO (compilers, git), native is faster than Cygwin, usually by a big margin. If mingw-git supported native symlinks and MSYS2 did too (as you say, via Cygwin) then IMHO that would be the best scenario. I agree however, that the msysGit project should divorce itself into mingw-git and a crappy broken MSYS (which should then die). I guess they had some essential shell script glue (hopefully) in the past, most of which is probably now done in Perl. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtxcsAAoJEOs4Jb6SI2Cwmr8H/3umAgeku/ModbMrJ39o2CAf c9+AfYLvYi9BaBA2BVSpOvqw4DwH+lE1N7Sf/v2dM/x/ufuPz/jSNWEJLSAEVAmW Jr9wUZzTSiQENCd5OiJBpJD68wOcF8wYVvI2f089uuPxDo7r+88FXHkNB6xm15xF 7+ZKxm/6185KMFkupTKVkYU1PvyZwYFcWbxvyuynahcLyLk/Szf4ydJWsNHGUF/r V8gF/Rt33hbsqhCySHWygdR8HkUIBIDvczRwDN9PfcaDu01VuVjSG04TjVBfttjk R21ySWOW/Qd0AopjSw9ndhWsWnx/nhDe/awumJ4o4NlceN3XjdXjODceLnabXoY= =7sz2 -END PGP SIGNATURE- -- 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 -- 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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 16:04, Corinna Vinschen wrote: 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. 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. 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). 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). Still, i'm not convinced that Cygwin is the universal, all-purpose tool that you seem to think it is (SquarePegRoundCygwin). - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtx1xAAoJEOs4Jb6SI2CwWr0H/2gNYeqKZRzZz19yhDiMh6oT JMxIILyuGQ6JcSVQHK3JwAERdhTg7JumShehLaqd2diUOfxjbWvr7xXH8uuQST3g rcPIxQPMG5uTnJuSHuK3j9N2hDGKrpj3KgW+PZOix29hRJkQTnwi/vYs3cYHycv/ RgU0Qe/XbfuchYIEcBIAmgS6NNko2Cnmb2iHBEzTNsIpYdppxxbVorgGO822rzji okv4fqP9hLmS250zWIkhXgfsA/qrhMStItFje2e0MYUtqJNiANWrjgutGWSfx5Dx DENJBTd5GoKWdvjNxzvzA/G++JfRVNNAINnWHE9hSkKRcO7ApENYcHsyX2ma9Lo= =I1A8 -END PGP SIGNATURE- -- 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)
-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). 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. Whether these extra features (or behaviour changes, where features already exist, but do not work in the desired way) should be merged into upstream Cygwin (with appropriate options to turn them on and off) or be left out as a fork, is another question which i am not qualified to answer. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtx9GAAoJEOs4Jb6SI2Cw1ckH/iEFDUNxTrIrgpKQ0+l8+7tN nDwAHVQ411KimF5GxQhjoVhw16WV97jDJCDBNx4X+FL1X3m/KQo+yPGSzkWb8SkX jpc9HRugCmTCNVz0vDqj4ELh1NWvt/m5CuuE6te5h1z0pbhwxvE13380MMQ1G6on yw5dkBGZa5unXGZ0TwedcKhIRBnfYMWfn5oTo3WpWqrU1UDdT8Py5VM4lRK01A9c 8jv4RFUCeunARZl3fyfWPZRy33xovlVYFWTcOwBVi4kcHI/C2seuOb6VBRRb+WI4 usy2WpJQrYYcBDWzxt2slXFtyjAQaqS6rsb3ZgdGBze03feYPLsxM5Ur37s7GgU= =WXti -END PGP SIGNATURE- -- 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)
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. It is more like another OS embedded in Windows rather then a shell. Almost no people have the same version of the utils because its multi-version and multi-package nature leads exactly to such diversity. That forces them to manage (install, update) the packages from time to time. Having anything working on your machine says nothing about working it elsewhere because the other one may have some package missing (often difficult to detect which one) or in another version. As a developer I want to be focused on my code and not to continually manage packages in the underlying environment. Exactly such experience taught me to avoid using cygwin. There were also other technical reasons which perhaps may be already be fixed. It is few years ago when I tried cygwin last time. The most prominent of those was the problem with end-of-line settings which tended to be different on some machine causing so many troubles with some utilities etc. I just never encountered such problem with MSYS. Please note I do not say cygwin is useless. I'm sure there are many tasks which require its complexity and where its ability to be (re)configured to one's needs is actually an advantage. But for the tasks I do, it is not. Best regards, Morous -- 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)
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)
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)
2013/6/11 Corinna Vinschen vinsc...@redhat.com: 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 Hmm, isn't the maintaining of ChangeLog not mandatory for GPL? Anyway, I have one question about term msys-toolchain. What actual is here the difference to cygwin, if there is any? [I don't speak about the native-Windows Toolchain end-user in general are using]. As msys isn't a known target upstream on gcc/binutils/etc, I would strictly recomment to use here instead cygwin-triplet anyway. Kai -- 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)
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)
Corrina, My user-based perspectives embedded below for your consideration... 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? ...SNIP... 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. You assume too much when you say ..there's nothing missing... from the current Cygwin situation. For example, while scanning the artifacts from JonY's substantial efforts at http://cygwin.mirrors.pair.com/release/gcc4/ having older 4.7.2 support is uninteresting for how I use mingw-w64 based toolchains. Furthermore, JonY's perspective on cross vs native toolchains is very different than mine. Until the mingwbuilds and ruben's mingw-w64 toolchains became available, the auto-built mingw-w64 toolchains were almost unusable for me for a variety of reasons. But is this a problem? No. I simply use mingwbuilds or ruben mingw-64 toolchains and my own tweaks to take advantage of all of JonY's amazing work without having to share JonY's workflow perspectives. It doesn't appear that I have this flexibility if I chose Cygwin. 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 While I'm glad you summarized your emotional views (sadly, too often our emotions are dismissed as somehow irrelevant (!?) and only technical or analytical views are acceptable or correct in a discussion), I truly hope you don't feel exploited. I view things very differently and think you and Kai should feel honored that someone with a different perspective than yours respected your and Kai's work enough to use it as the foundation for MSYS2, and open up the discussion on this list early in the MSYS2 development. I view Alexey's efforts as sharing rather than ripping off and think his work is very much a complement to the work that you and Kai have done. 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? It's been a very long time since I used Cygwin, but this discussion will cause me to go back and look at Cygwin again. That said, the following are user-perspective reasons why I currently don't use Cygwin: 1) I build native applications rather than apps dependent upon the Cygwin DLL. 2) I dislike Cygwin's `setup.exe` gui installation helper. I automate the stitching together of MSYS functionality with multiple mingw-w64 and mingw.org (non cross) toolchains to create custom toolchains. Cygwin's integrated `gcc4` support from JonY does not work for me, but I'm very thankful I can take advantage of JonY's tremendous efforts in other ways. In fact, I'm working on a tool that will use window's recent symlink behavior to easily switch toolchains via a dir symlink to locations like `C:\DevTools\mingw` in which the MSYS/MSYS2 goodies live in `C:\DevTools\bin` and the toolchains get symlinked and switched under `C:\DevTools\mingw` by a tool that works similar to MKLINK. The bottom line is that while my workflow does not appear to be a good match for Cygwin's primary use cases, I greatly benefit from MSYS (and likely MSYS2) creative and targeted use of underlying Cygwin capabilities. Even though I don't directly use Cygwin, I thank you for all your hard work and hope to always have the option of using a maintained MSYS or MSYS2 bag-o-goodies. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing
[Mingw-w64-public] [PATCH] Make dxva2api.h compilable without d3d9.h
---
mingw-w64-headers/include/dxva2api.h | 10 +-
mingw-w64-headers/include/dxva2api.idl | 8
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/dxva2api.h
b/mingw-w64-headers/include/dxva2api.h
index 3ab4842..c75474e 100644
--- a/mingw-w64-headers/include/dxva2api.h
+++ b/mingw-w64-headers/include/dxva2api.h
@@ -1,4 +1,4 @@
-/*** Autogenerated by WIDL 1.5.25 from include/dxva2api.idl - Do not edit ***/
+/*** Autogenerated by WIDL 1.5.19 from include/dxva2api.idl - Do not edit ***/
#ifndef __REQUIRED_RPCNDR_H_VERSION__
#define __REQUIRED_RPCNDR_H_VERSION__ 475
@@ -278,6 +278,7 @@ typedef struct _DXVA2_ValueRange {
DXVA2_Fixed32 StepSize;
} DXVA2_ValueRange;
+#ifdef _D3D9_H
typedef struct _DXVA2_VideoDesc {
UINT SampleWidth;
UINT SampleHeight;
@@ -288,6 +289,7 @@ typedef struct _DXVA2_VideoDesc {
UINT UABProtectionLevel;
UINT Reserved;
} DXVA2_VideoDesc;
+#endif
/* DeviceCaps
DXVA2_VPDev_EmulatedDXVA1
@@ -357,6 +359,7 @@ typedef struct _DXVA2_VideoProcessBltParams {
DWORDDestData;
} DXVA2_VideoProcessBltParams;
+#ifdef _D3D9_H
typedef struct _DXVA2_VideoProcessorCaps {
UINTDeviceCaps;
D3DPOOL InputPool;
@@ -369,6 +372,7 @@ typedef struct _DXVA2_VideoProcessorCaps {
UINTNoiseFilterTechnology;
UINTDetailFilterTechnology;
} DXVA2_VideoProcessorCaps;
+#endif
/* SampleData
DXVA2_SampleData_RFF
@@ -376,6 +380,7 @@ DXVA2_SampleData_TFF
DXVA2_SampleData_RFF_TFF_Present
*/
+#ifdef _D3D9_H
typedef struct _DXVA2_VideoSample {
REFERENCE_TIME Start;
REFERENCE_TIME End;
@@ -387,6 +392,7 @@ typedef struct _DXVA2_VideoSample {
DXVA2_Fixed32PlanarAlpha;
DWORDSampleData;
} DXVA2_VideoSample;
+#endif
/* Constants */
@@ -428,6 +434,7 @@ __forceinline DXVA2_Fixed32 DXVA2FloatToFixed (const float
f) {
return f32;
}
+#ifdef _D3D9_H
HRESULT WINAPI DXVA2CreateDirect3DDeviceManager9(UINT
*pResetToken,IDirect3DDeviceManager9 **ppDXVAManager);
HRESULT WINAPI DXVA2CreateVideoService(IDirect3DDevice9 *pDD,REFIID riid,void
**ppService);
/*
@@ -726,6 +733,7 @@
DECLARE_INTERFACE_(IDirectXVideoDecoderService,IDirectXVideoAccelerationService)
END_INTERFACE
};
+#endif
#ifdef COBJMACROS
#define IDirectXVideoDecoderService_QueryInterface(This,riid,ppvObject)
(This)-lpVtbl-QueryInterface(This,riid,ppvObject)
#define IDirectXVideoDecoderService_AddRef(This) (This)-lpVtbl-AddRef(This)
diff --git a/mingw-w64-headers/include/dxva2api.idl
b/mingw-w64-headers/include/dxva2api.idl
index c0fd3b0..038d6b6 100644
--- a/mingw-w64-headers/include/dxva2api.idl
+++ b/mingw-w64-headers/include/dxva2api.idl
@@ -257,6 +257,7 @@ cpp_quote( DXVA2_Fixed32 DefaultValue;)
cpp_quote( DXVA2_Fixed32 StepSize;)
cpp_quote(} DXVA2_ValueRange;)
cpp_quote()
+cpp_quote(#ifdef _D3D9_H)
cpp_quote(typedef struct _DXVA2_VideoDesc {)
cpp_quote( UINT SampleWidth;)
cpp_quote( UINT SampleHeight;)
@@ -267,6 +268,7 @@ cpp_quote( DXVA2_Frequency OutputFrameFreq;)
cpp_quote( UINT UABProtectionLevel;)
cpp_quote( UINT Reserved;)
cpp_quote(} DXVA2_VideoDesc;)
+cpp_quote(#endif)
cpp_quote()
cpp_quote(/* DeviceCaps)
cpp_quote(DXVA2_VPDev_EmulatedDXVA1)
@@ -336,6 +338,7 @@ cpp_quote( DXVA2_FilterValues DetailFilterChroma;)
cpp_quote( DWORDDestData;)
cpp_quote(} DXVA2_VideoProcessBltParams;)
cpp_quote()
+cpp_quote(#ifdef _D3D9_H)
cpp_quote(typedef struct _DXVA2_VideoProcessorCaps {)
cpp_quote( UINTDeviceCaps;)
cpp_quote( D3DPOOL InputPool;)
@@ -348,6 +351,7 @@ cpp_quote( UINTVideoProcessorOperations;)
cpp_quote( UINTNoiseFilterTechnology;)
cpp_quote( UINTDetailFilterTechnology;)
cpp_quote(} DXVA2_VideoProcessorCaps;)
+cpp_quote(#endif)
cpp_quote()
cpp_quote(/* SampleData)
cpp_quote(DXVA2_SampleData_RFF)
@@ -355,6 +359,7 @@ cpp_quote(DXVA2_SampleData_TFF)
cpp_quote(DXVA2_SampleData_RFF_TFF_Present)
cpp_quote(*/)
cpp_quote()
+cpp_quote(#ifdef _D3D9_H)
cpp_quote(typedef struct _DXVA2_VideoSample {)
cpp_quote( REFERENCE_TIME Start;)
cpp_quote( REFERENCE_TIME End;)
@@ -366,6 +371,7 @@ cpp_quote( DXVA2_AYUVSample8Pal[16];)
cpp_quote( DXVA2_Fixed32PlanarAlpha;)
cpp_quote( DWORDSampleData;)
cpp_quote(} DXVA2_VideoSample;)
+cpp_quote(#endif)
cpp_quote()
cpp_quote(/* Constants */)
cpp_quote()
@@ -407,6 +413,7 @@ cpp_quote( f32.Fraction = ((ULONG) (f * (1 16)))
0x;)
cpp_quote( return f32;)
cpp_quote(})
cpp_quote()
+cpp_quote(#ifdef _D3D9_H)
cpp_quote(HRESULT WINAPI DXVA2CreateDirect3DDeviceManager9(UINT
*pResetToken,IDirect3DDeviceManager9 **ppDXVAManager);)
cpp_quote(HRESULT WINAPI DXVA2CreateVideoService(IDirect3DDevice9 *pDD,REFIID
Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)
Cygwin and MSYS have significantly different goals (even if MSYS is entirely based on Cygwin). My understanding is that MSYS is the minimal shell required to run autotools and get sources from internet from different repositories. MSYS is about porting Unix programs to Windows without having a Posix emulation layer, and then (hopefully!) getting those changes up-streamed. Typically, on MSYS, the executables that are run want to be native Win32 where-as on Cygwin they want to be Posix and this will always be the case and a problem. 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 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). 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. 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). 5. Add -W option to bash.exe's pwd command for compatibility with old MSYS. 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:/ 7. Minor changes to other userland programs (such as Perl so it reports msys as $^O) which again helps to retain compatibility. The reality is that MSYS exists and it's really old and getting in the way of developers, and MSYS2 is needed to replace this. I'm surprised therefore at the negative reaction, but really hope that MSYS2 can be viewed as a complimentary off-shot from Cygwin (even *hopefully* by the Cygwin developers!). Regards, Alexey. -- 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] [Website] Work on a Download page
Hi, It feels like I'm spamming a bit so I hope I'm not too annoying with this. I've put a new version online and I hope that besides a couple of minor changes (cleaning some code and updating links), it is ready to go live: http://notk.org/~adrien/mingw-w64-download/htdocs/download.php -- Adrien Nader -- 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] Runtime for Cygwin
Please keep signature in platform-headers as they are in prototypes. I'm trying to understand exactly what the requirement is here. You've been doing this kind of work for a long time, so if you say there's a reason to do this I expect there is. As I look at your patch (or my second one), I see these downsides: * Using different definitions between winnt.h and intrin.h is going to continue to cause conflicts. While your patch resolves the problem of winnt.h conflicting with itself, trying to #include both files will still cause errors. * I'm uncertain about which definition to put in __stosb.c. Both prototypes are implemented in the same .c file. So, use the definition from winnt.h? Or intrin.h? If they are not virtually identical, the linker won't find it. If they must be identical, why have 2? * We are adding complexity to the macro. This makes maintenance harder. On the plus side I see: * The prototype in winnt.h still looks like MS's. Near, but not exactly what I wrote. I know they aren't. But there are downsides to this solution. Indeed to every solution that isn't use the exact same definition for this function everywhere (ie my first proposed patch). That fact that you continue to push for keeping them different confuses me. I assume that's because you know something I don't. Help me understand. I don't see either a reason to modify intrin.h prototype either. I made the change to intrin.h as a result of the (somewhat bewildering) fact that __LONG32 isn't always 32bits. I'm sure there's a good reason for this, but I believe __stosd should always work 4 bytes at a time. dw -- 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] Runtime for Cygwin
Sorry. Looking back, you did try to describe some of the issues. However, this hasn't helped clear things up. The problems are still essentially what the email I just sent said: The point is that LP64 target provides type size_t proper for its ABI. Yes it does. However, winnt.h still causes compile errors when used with intrin.h. There should be no reason you can't use intrinsics at the same time you are using the platform files. makes sure we have C-linkage, we have no issues about signatures here. But we do if you include both files. instead, due it uses C and therefore has no special signatures, too. Both winnt.h and intrin.h use extern C. For C++ signatures have to be same, as otherwise C++ will see it as two different functions. Since the prototypes in both files are marked as extern C, I don't see how this applies. I'm sorry, but I still just see conflicts. dw -- 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
