Re: [Mingw-w64-public] [PATCH] headers: Add a configure parameter for setting the default value of _WIN32_WINNT
Hi, On Fri, Nov 03, 2017, Kai Tietz via Mingw-w64-public wrote: > Hello Martin, > > The patch is ok. Please go ahead and apply. > > JonY, Adrien do we have on web-server documentation about our special > configure options? I think it might be time to create such a > page/document. What do you think? I don't have the time to do it and the website is a wiki: anyone who logins can add documentation. Registration woes should be a thing of the past now and have been checked on yesterday with a gmail address. Moreover, I will happily assist people who might have troubles with the website but I won't try to handle the whole topic of documentation alone. -- Adrien -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New bug fix from v5.x release soon
Good morning, I was looking at the changelog for OCaml 4.06 and noticed the following entry: > - MPR#7638: in the Windows Mingw64 port, multithreaded programs > compiled to bytecode could crash when raising an exception from C > code. This looks like a Mingw64 issue, which we work around with GCC > builtins. (Xavier Leroy) This leads to the following pages: https://caml.inria.fr/mantis/view.php?id=7638 http://www.agardner.me/golang/windows/cgo/64-bit/setjmp/longjmp/2016/02/29/go-windows-setjmp-x86.html https://sourceforge.net/p/mingw-w64/bugs/406/ Does anyone know if this issue has been fixed and if the bug report should be closed, or if this has flown under the radar? Thanks, -- Adrien -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News|New Builds]
On Tue, Aug 15, 2017, niXman wrote: > Liu Hao 2017-08-15 05:59: > > >When I click the Register button the page reloads and nothing happens > >thereafter. > > +1 Have you checked your emails, including the spam folder? -- Adrien -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News|New Builds]
On Mon, Aug 14, 2017, niXman wrote:
> Norbert Pfeiler 2017-08-14 18:19:
> >What do you want the contents to be? (regarding it currently shows 2
> >versions)
> >I usually update Msys2 and Arch where only 1 version applies.
>
> will be better if you explain how I can update this myself.
Scroll to the bottom, click login/register, fill in and validate the
form, check your emails. Edits on some pages require me to add editors
to a specific group, this is the case for the download pages so you have
to tell me or Jonathan about your username.
After login you will get edit buttons on the right of the content (both
a button for the whole page and one per content section).
As an additional note (this does not apply for your case), for
maintainability reasons some of the download infos have been moved to
separate pages that are "included" in the main one. This is not visible
to visitors, only to editors. This is easily spotted because the
textblock contains '{{section>download/...' and the corresponding page
('download/...') should be edited instead.
--
Adrien Nader
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?
Hi, The implication of this change would be that you need a separate toolchain to target these OSes and 5.x is not going to be abandoned tomorrow, which gives you plenty of time. I've followed the support from browsers and FF 53 which is an ESR is the last browser to support XP. Since it's recent and ESR, support will last a few more months but that's about it. The possibility for you would be the aforementioned patch and default to something more recent to XP but still allow to target it. That's the moment you're welcome to do it and post it for review on the list. Targeting XP will not be supported but that's actually the current situation anyway since the majority of people here are not testing XP anymore. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-w64-public Digest, Vol 113, Issue 11
On Mon, Feb 27, 2017, Robert May wrote: > $ . / configure --build alias - -host -alias --target -alias > This came from somewhere in the help files Which help files? And please avoid using (weekly) digests to answer on the mailing-list: they break threading of conversations and are a huge pain for other readers because of that. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: mungw-w64-v5.0.1
On Sat, Feb 25, 2017, Mateusz Mikuła wrote:
> > ./configure --build alias - -host -alias --target -alias
>
> It is wrong, because there is no arch named 'alias'.
> Look at
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-crt-git/PKGBUILD#L57
> ,
> "${MINGW_CHOST}" is expanded as 'x86_64-w64-mingw32'.
My point was not that such an architecture exist but that there are
configure variables named "build_alias", "host_alias" and
"target_alias".
There are some copy-paste involved. Look at the inconsistent spacing.
That said, configure quickly throws me away when I try to use
--build-alias, --host-alias or --target-alias so I'm not sure who could
have mentioned these in such a way.
--
Adrien Nader
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)
Full logs would be valuable. Moreover as far as I understand, you want to build a static executable. Please confirm that you understand the consequences on complying with the LGPL. Since you also pass --enable-gpl, please also confirm that you understand the consequencs on complying with the GPL (actually the whole thing will be GPL so the LGPL doesn't matter anymore but it's a better start). -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stdio.h: Ignore extern "C++" for Clang
Hi, Do you know how much this (still?) applies to GCC? The goal should be to reduce the number of compiler-specific sections rather than add new ones. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Align thread entry point stack
Hi,
I've recently re-stumbled upon this. As far as I can tell it hasn't been
commited. Was there some more discussion on the topic or did it simply
get forgotten?
--
Adrien Nader
On Mon, Aug 22, 2016, Kai Tietz wrote:
> Hello Aleksey,
>
> 2016-08-22 13:52 GMT+02:00 Aleksey Vasenev <margtu-f...@ya.ru>:
> > __attribute__((aligned)) don't work for stack variables in threads created
> > with _beginthreadex without alignment.
> >
> > Signed-off-by: Aleksey Vasenev <margtu-f...@ya.ru>
> > ---
> > send it again
> > github: https://github.com/Ratio2/mingw-w64/tree/align
> > fix crash: ffmpeg -f lavfi -i testsrc -vcodec libvpx -threads 2 -f null -
> > problem discuss: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2236
> >
> > _beginthreadex does not align the stack on 16-byte boundary as expected
> > by gcc.
> >
> > On x86 targets, the force_align_arg_pointer attribute may be applied to
> > individual function definitions, generating an alternate prologue and
> > epilogue that realigns the run-time stack if necessary. This supports
> > mixing legacy codes that run with a 4-byte aligned stack with modern
> > codes that keep a 16-byte stack for SSE compatibility.
> > https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html
> >
> > mingw-w64-libraries/winpthreads/src/thread.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mingw-w64-libraries/winpthreads/src/thread.c
> > b/mingw-w64-libraries/winpthreads/src/thread.c
> > index 565ea48..c771daf 100644
> > --- a/mingw-w64-libraries/winpthreads/src/thread.c
> > +++ b/mingw-w64-libraries/winpthreads/src/thread.c
> > @@ -1454,6 +1454,9 @@ pthread_setcanceltype (int type, int *oldtype)
> >return 0;
> > }
> >
> > +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2)
> > +__attribute__((force_align_arg_pointer))
> > +#endif
> > int
> > pthread_create_wrapper (void *args)
> > {
> > --
> > 2.9.1
>
> I guess you have tested your suggested patch? Over all it looks
> reasonable to me.
>
> Regards,
> Kai
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cannot build ming64 for windows
Considering the error is about muldi.o, I'm curious as to which steps you've followed for other components of the toolchain so a list of them would be interesting, especially when it comes to the CRT. -- Adrien Nader -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Make isatty Cygwin-compatible
Hi,
Below I'm only looking at the code by itself, not at the overall
approach.
On Sun, Nov 13, 2016, Mihail Konev wrote:
> + pNtQueryObject = (proc_NtQueryObject*)
> GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQueryObject");
> + if (!pNtQueryObject)
> +goto no_tty;
Curly braces prevent many mistakes.
> + memset(ntfn, 0, ntfn_size);
> + status = pNtQueryObject((HANDLE)h_fd, ObjectNameInformation,
> + ntfn, ntfn_size, _size);
> +
> + if (!NT_SUCCESS(status)) {
> +/* If it is not NUL (i.e. \Device\Null, which would succeed),
> + * then normal isatty() could be consulted.
> + * */
> +if (_isatty(fd))
> + return 1;
Curly braces.
> +goto no_tty;
> + }
> +
> + s = ntfn->Name.Buffer;
> + s[ntfn->Name.Length / sizeof(WCHAR)] = 0;
> +
> + /* Look for
> \Device\NamedPipe\(cygwin|msys)-[a-fA-F0-9]{16}-pty[0-9]{1,4}-(from-master|to-master|to-master-cyg)
> */
What's the logic? You're saying what you're doing but not the reason
for doing it.
> +
> + if (wcsncmp(s, L"\\Device\\NamedPipe\\", 18))
18 looks like a magic number here; I guess it's related to the string
before but it's painful to count. Creating a variable and getting the
string length would be much more readable.
> +goto no_tty;
Curly braces.
> + s += 18;
> +
> + if (!wcsncmp(s, L"cygwin-", 7))
> +s += 7;
Curly braces.
> + else if (!wcsncmp(s, L"msys-", 5))
> +s += 5;
Curly braces.
> + else
> +goto no_tty;
Curly braces.
> +
> + for (i = 0; i < 16; i++) {
Why 16?
> +c = *s++;
> +if (!( (c >= 'a' && c <= 'f') || (c >= 'A' && c <= 'F') || (c >= '0' &&
> c <= '9') ))
> + goto no_tty;
Curly braces.
> + }
You can probably do the same but probably more readable with wcsspn and
it'll be one less thing to worry with when it comes to encoding. Simply
ensure the value returned by wcsspn() is the string length.
By the way, what if s is smaller than 16? It is filled with null
characters?
> +
> + if (wcsncmp(s, L"-pty", 4))
The reason I prefer explicits == 0 and != 0 for compare functions is
that I then don't have to double-check that you simply haven't forgotten
an exclamation mark at the beginning of your condition.
> +goto no_tty;
Curly braces.
> + s += 4;
> +
> + for (i = 0; i < 4; i++, s++) {
> +c = *s;
> +if (!( c >= '0' && c <= '9' ))
> + break;
> + }
Again, curly braces and handling of strings shorter than 4.
As far as I understand the goal here is to check that up to the first
four characters after "-pty" are numerical and move to the first
non-numerical characters after these. You can use wcscspn() to do the
lookup. You should also handle the cases where no numerical character is
found.
> +
> + if (i == 0)
> +goto no_tty;
Curly braces.
> +
> + if (wcscmp(s, L"-from-master") &&
> +wcscmp(s, L"-to-master") &&
> +wcscmp(s, L"-to-master-cyg"))
> +goto no_tty;
Curly braces.
> +
> + return 1;
> +
> +no_tty:
> + errno = EINVAL;
> + return 0;
> +}
> +
> #ifndef _FILE_OFFSET_BITS_SET_LSEEK
> #define _FILE_OFFSET_BITS_SET_LSEEK
> #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
> --
> 2.9.2
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] lib32 msvcrt add mkgmtime exports - XP support?
Hi, A small thread hijack. On Mon, Oct 31, 2016, Martell Malone wrote: > Hey guys, > > My only concern is if this is supported on windows xp. > https://msdn.microsoft.com/en-us/library/2093ets1.aspx > MSDN has a doc version from VS2005. > I don't see anything about a min windows version there. > We already have this in the lib64 variant. > So all indicators are good. Some time ago there has been a conversation about XP support and v5 and future versions on IRC. And basically it said that XP support could be dropped after v5. So, what's the status? -- Adrien Nader -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Release criteria for mingw-w64 v6?
Hi, On Wed, Oct 19, 2016, David Wohlferd wrote: > Is there an official list of release criteria for mingw-w64 v6? Or a > targeted release date? I'm not seeing anything on the web site. Not that I know of. Not that I know of. Yes, website needs to be updated and I don't have the time to do it before several days. Edit rights should be good enough for at least Jonathan and a couple others but I'm definitely open to broadening the accesses to the proper people: simply send me an email (and you can do that for any issue with the website). (and now I have the RSS feed for page changes fetched regularly on my phone) > I have some changes I'd like to propose that only belong at the start of > a new cycle. But I'd like to see how they fit with the current plans. I think a time-based release would make sense. Something like 1 year. There usually aren't huge new features that land all at once but rather smaller improvements which add up over the time. I think this has been an issue in the past and people were wondering whether the changes warranted a release or not. Meanwhile, downstreams were waiting for a new release to be able to benefit from all the small improvements. It's also possible to argue about the release periodicity. I wouldn't go over 1 year. I wouldn't go below 6 months because of the additional work. Of course, since I can't be considered as an active code author in the project, I won't argue much about these. -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers need to be updated?
Hi, On Thu, Aug 11, 2016, LRN wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10.08.2016 20:04, John Klimek wrote: > > I'm trying to compile mpv which checks to see if the OpenGL headers > > are installed. It's failing because the included 'gl.h' is missing > > the constant GL_RGB32F. Instead, this is defined in glext.h. > > > > Somebody from the mpv team said that this constant is now part of the > > default OpenGL specification so it should be defined in 'gl.h'. > > If that constant is in glext.h, then that is where it is supposed to be. > I've pulled latest OpenGL registry svn revision (r33080 from 2016-08-05) > and that constant is still only in glext.h and glcorearb.h. > > If that is incorrect, complain to OpenGL registry[1] maintainers. > > > > > Does anybody know if the included OpenGL headers are recent or if they > > could be updated? > > Most headers are from 2014-08-11 or so. They can be updated from the > OpenGL svn repo[2]. > > Previously i've been doing the updating. However, i have certain > rudimentary quality control procedure for verifying that the headers i've > pulled are at least somewhat useful, and i put headers through that > procedure before pushing the update upstream. That procedure is currently > unavailable to me. That is why headers are 2 years old now. > > [1] https://www.opengl.org/registry/ > [2] https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api I got late in my handling of emails and I only recently read this. Is there still a need or will for an update to more recent headers? Can that test procedure be shared and properly run by someone else and is there someone interested to do that? -- Adrien Nader -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync
On Mon, Oct 03, 2016, David Wohlferd wrote:
> On 10/2/2016 6:38 PM, JonY wrote:
> >On 10/3/2016 06:37, David Wohlferd wrote:
> >>So, my testing didn't turn up any problems. The patch is pretty
> >>big (1,389,398), so I have compressed it and uploaded it to
> >>http://www.LimeGreenSocks.com/gen2.7z (where it is only 82,083).
> >>
> >>Just a reminder: Despite the size, this is 100% regenerated code,
> >>mostly in the build-aux directories.
> >>
> >>Comments (especially about whether we need the beta config.guess)
> >>welcome. What needs to happen to get this approved to Push?
> >>
>
> I'm sorry, I'm a bit thick. Can you clarify?
>
> >Since it is all regenerated code, I'm OK with it.
>
> Is this the same as "approved to push?"
>
> >config.guess is
> >nice, but not essential, no one has complained about unsupported
> >platforms, yet.
>
> Does this mean you want to use the most-recently-released version?
> Or the beta version (which is even more recent)? The patch I posted
> uses the released version. But it could be that "no one has
> complained" because the beta is what is currently checked in.
>
> While an argument can be made for either, my recommendation is to go
> with the 'released,' and only use the beta if there is a specific
> requirement. But since "going backward" like this might break
> something (maybe someone did complain at some point?), I felt the
> need to ask.
>
> My tests were with the 'released' version, but I'm prepared to
> re-test if the beta is preferred. As the "approver," I assume you
> decide?
>
> I believe that if I update config.guess, I'm supposed to update
> config.sub too (not knowing the answer to this is another reason to
> stick with the 'released' version). I have attached a patch for
> config.guess + config.sub to show what has changed. Note that this
> is going backwards (turning the 'beta' into the 'most recently
> released').
I quickly went through the diff and I've found the following:
> +amd64:MSYS*:*:* | x86_64:MSYS*:*:*)
> + echo x86_64-unknown-msys
> + exit ;;
There are also changes that could be related to ARM support ("earm").
Oh and iOS and ASM.js but I think they don't matter much to us (although
maybe we'll soon have that portable POSIX environment in javascript and
we'll build boost with it).
Most of the diff is either quoting or removed and added platforms but
there are also a couple other changes.
I think it's safer to keep the version that is currently checked in. I
prefer versions from released tarballs but sometimes we'll also need to
handle new platforms. For these cases, I'm perfectly fine with
unreleased versions (autotools perfectly enables such usecases) but I'd
like to see a request somewhere or a slightly more complete commit
message (i.e. "adds support for X and Y") so it's easier to track in the
future.
--
Adrien Nader
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Pre-built toolchains and packages gone from the Downloads page
On Mon, Sep 05, 2016, NightStrike wrote: > On Sep 4, 2016 6:50 PM, "Adrien Nader" <adr...@notk.org> wrote: > > > > Additionaly, the list of projects using mingw-w64 is now sorted and > > always displayed in full. > > This was always randomized on purpose, and for very good reason: we don't > want to give preferential treatment to projects based on names starting > with 'A'. We'd like to give equal exposure to all. I still have a few things to improve for this but the drawbacks to randomizing are a bit too big for my taste. - users find the order weird - users find the order changes weird - the current implementation relies on javascript and makes the list change suddenly - some search engine bots *really* dislike that links come and go Meanwhile the links are not at the top of the page at all and are quite clearly sorted alphabetically (except for the fact that there should be two lists and not one) which makes me not worried about this. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Pre-built toolchains and packages gone from the Downloads page
That, I can arrange it by hand. I thought it ws fine for you now and I had added you to the right group to edit the pages. I'll get you a new password by hand this evening. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] glibc isinf() behaviour
Hi, On Mon, May 23, 2016, Nakai Yuta wrote: > Hi, all > I attached the patch. > > I put ifdef guard for compatibility with MSVC. > > default behaviour: same as MSVC > when defined _GNU_SOURCE: same as glibc(>2.01) This is tangential. I'm actually a bit worried about such changes in the general case: when using autoconf, one typically doesn't define _GNU_SOURCE but instead ask for "extensions" and ./configure decides what to do. It's kind of automatic. This means that there are many projects (most actually it seems) which #define _GNU_SOURCE 1 and not only the ones which really really really want it. I don't think this specific patch is wrong or will cause troubles. And I'm not saying either that projects which ask for non-standard behaviour that is not clearly defined and guaranteed are right. Instead, I merely wish to warn for future changes because it's perfectly reasonable to have code relying on msvcrt-specific behaviour in windows-only codepaths while also having _GNU_SOURCE. Of course, _GNU_SOURCE gives no guarantee but we know how things work when it comes to compatibility. Also, what is the official stance on msvcrt- vs gnu-specific behaviours currently? I don't think I've seen it written well anywhere. -- Adrien Nader -- Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] It would be very much appreciated if you would find a better solution for multiprocessing.
Hi, What are you talking about? -- Adrien Nader -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
On Thu, Apr 14, 2016, lh_mouse wrote: > C++0x threading APIs are currently unimplemented. > > It is only because gthr.h is so obscure about __gthred_time_t. > It doesn't say anything about whether __gthread_time_t should be a struct > (like struct timespec) or a plain integer or even a floating point type, > neither does it say where and how to obtain a __gthread_time_t that > represents the current system time. > Nonetheless, all *timedwait() interfaces, for mutex, condition variable and > (as extensions) even thread and once-init, are naturally supported by > mcfgthread. > > I really hate the 'struct timespec' thing, as well as using a UNIX timestamp > in *_timedwait() functions because the wall clock is subject to DST and NTP > and can also be manually set by the user. > Rather, (currently) all timepoints in mcfgthread are obtained using the > _MCFCRT_GetFastMonoClock() function which is simply a wrapper for > GetTickCount64() that is only available since Vista. > This guarantees that the clock is monotonic and can't be set by the user, as > well as a good resolution of 1ms. > > However, should readjusting the time origin be essential, it would be easy to > use an alternative clock, code about which could be found here: > https://github.com/lhmouse/mcfgthread/blob/master/src/env/_nt_timeout.h?ts=4#L15 The use of unix timestamps and the clock choice are completely orthogonal issues. CLOCK_MONOTONIC can be happily used with unix timestamps. If it couldn't, then I wonder why the REALTIME, REALTIME_COARSE, MONOTONIC, MONOTONIC_COARSE, RAW, BOOTTIME, PROCESS_CPUTIME_ID, THREAD_CPUTIME_ID clocks would have been added to glibc (well, except thread cputime :) ). If you want to use a specific clock with says pthread_cond_timedwait, you should set the corresponding attribute on the condition variable with pthread_condattr_setclock(). I'm not sure you (or someone else) would start implementing C++11 threading on top of that but as far as I know, C++, at least C++11, gives absolutely no guarantee on the clock being used. It's not even that you can't rely on a monotonic one being available, it's that you can't rely on the dumbest one being available and you cannot chose nor check anything about clocks. What you are doing here is using your own preference. I agree it makes much more sense but you shouldn't chose a behaviour based on that, especially when the most-widespread behaviour does the opposite. -- Adrien Nader -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which project are alive?
Hi, On Tue, Apr 05, 2016, Julien Darthenay wrote: > Hello, > > (I am not sure my message was sent because I forgot to activate my > mailing-list subscription, so I sent it again. Pretty please, excuse me > for the spam if you got this message twice). > > I have installed MinGW64 three years ago, it was something such as > i686-w64-mingw32-gcc-4.8.0-win32_rubenvb. > This year I decided to update it, so I discovered the "new" website > http://mingw-w64.org (not sure it is new, but if it was already there in > 2013 I was not aware of it and never saw it). Yes, it's new. Well, only a few months old. > I tried to use Win-Builds. This seem a rather good stuff, installing a > lot of usefull libraries, avoiding me the big pain in the ass to install > them one by one, not even sure I could find all of them. But I realize > this toolchain seems to be somewhat outdated compared to others, still > stuck to MinGW-w64 3.3.0, and last update (1.5) was more than one year > ago. I also got an very annoyous bug > <http://win-builds.org/bugs/index.php?do=details_id=137> with gmake > 4.0 64-bit, so I am stuck with using GNU Make 3.82.90 from a previous > installation. Also building 32bits target with Win-builds 64-bits does > not work, so I had to install Win-builds 32-bits. I saw your report back then but available time has been completely used by the development of the next version. Unfortunately the scope of this version has increased over and over, ultimately encompassing the scope of two versions and getting a consistent release schedule. > I also tried to install MSys2, but I got very disappointed. First thing, > the installer seems to install only for current user (at least it > installed shortcut only for the user who launch installation) but > requires Admin rights to install. This is truly a big flaw that have to > be fixed. But my worst worry was Avast putting a lot of stuff in > quarantine, and after I searched the with DuckDuckGo the messages from > Avast it appears I was being delivered malwares by Soureceforge. So I > immediately removed MSys2. > > At work for some project we are using TDM-GCC, but this tool is not even > mentionned in your download section, this is not reasuring. Also last > news in their website is from 2015 July 2nd. > > And Rubenv toolchain don't seem to be maintained any more. > The story of the download section is roughly as follows: - [old site], no dedicated page but the file and directory listing of sourceforge's file hosting feature - [old site], dedicated page, edited through git commits - [new site], wiki, dedicated page, only requires an account - [new site], edition doesn't require an account anymore because sending emails is probably the most difficult task on the Internet nowadays (probably more difficult than buying nuclear weapons) The new site is hosted on a dedicated server from OVH that is shared with a few people related to me. Sourceforge was too slow to let a single full pass of the rendering complete (they have a timeout) and the wiki's cache would never populate. Even when the website was still hand-written, I had separated the various "toolchains" so they could be edited independently. I refrain from touching most sections other than win-builds' and completely avoid a couple ones. > So, now that I have finished narrating my story, I have a few questions... > Which of these tools are still alive? > What would you recommend me to use? > I have downloaded a Debian 8.2 32-bit virtual machine, may I use it to > build my how Mingw-64 packages? (Actually I also downloaded the 64-bit > one, but when I tried to run it VMWare insulted me and told me to stop > dreaming, softwares can be very disrespectful nowadays) >From what I've seen, the packages in Debian are fine. My only complaints is that there are two alternatives provided in the packages (one provides no C++11 threading but a small dependency less) and users seem to be unaware of that. > Will you do something about the Sourceforge's malwares issue? You need to check the actual origin of what you downloaded then. There are many links on the download page and the vast majority of them points outside of the mingw-w64 SF.net project; and I think that one was outsid of it. > What to do if a MinGW package I need is only on Sourcforge? I haven't understood that question (mostly, what's a "mingw package")? > Sorry for my disturbing English, and if you have not fallen asleep yet, > thanks for reading me. I'm French but I'm picky with English and didn't have troubles understanding. :) -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
On Tue, Mar 01, 2016, David Grayson wrote: > Could we add a preprocessor configuration option like > __USE_MINGW_POSIX_PID which makes getpid() actually return a pid_t > (signed 64-bit integer)? (It can be wrapped in a function named > __mingw_getpid or something.) So POSIXY projects could opt in to the > new behavior in their build configuration, and Windowsy projects would > keep working as is? It would be like __USE_MINGW_ANSI_STDIO. Wouldn't that mean two ABIs? Sounds difficult to balance. -- Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
Hi, I poked Kaï on IRC about that; here's the log (very slightly reformatted): > Well, I admit that I know that pid_t is on standard sdk just a 32-bit value. > Nevertheless there is a lot of software in FOSS, which assumes that pid_t has > actually the width of a pointer, and so we decided to make pidt_t on Windows > 64-bit. > Nevertheless assuming that pid_t is an int, is also wrong on Windows. > It is actually a DWORD. See GetThreadId (or something like that is the API of > Win32). > So negative values are nothing to be concerned about at all. > API is GetCurrentThreadId() > I am openminded here, but we might need to expect fallout by this change. > Not sure if this is worth the change. -- Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
On Sun, Feb 28, 2016, Stefan Weil wrote: > PS. If you want, you can add QEMU to the project list > http://mingw-w64.org/doku.php#some_projects_using_mingw-w64 Done. -- Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] website out of date
Ah, I really thought 4.0.2 was the latest one when I looked at the website last and I had misunderstood what Kaï had recently told me. In any case, when you spot such things, you can update the page yourself (it's a now-open wiki). Regards, Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Website change: edits without registration
Hi, A few months ago, I migrated the website from a static-content php-based website to a dokuwiki installation in order to benefit from a newer theme and ease edits. This also lifted the previous restriction that only project commiters could touch the website. Unfortunately, the sum of the server's http, php and mailer daemon configuration combined with the ones of some mail servers meant the registration confirmation mail never reached its target. This seems to have mostly impacted self-hosters who are unsurprisingly not so uncommon around the project. I had wanted to find the actual issue but never managed to find the time to dig properly and I've therefore decided to simply make it possible for anyone to edit the various pages besides the main page (that will certainly be possible soon). So far it is still an experiment because of possible spam edits but only time will tell. Therefore, you should be able to simply go on http://mingw-w64.org , browse to another page and be able to edit what you wish without having to log in. -- Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64-tools: genlib - internal tool for import lib generation
Hi, On Thu, Oct 29, 2015, Martell Malone wrote: > Hi, > > Kai and I discussed this previously but I would like to present to everyone > a tool to generate import libs based on layout and code structure of gendef. > > I would like propose > https://github.com/martell/genlib > to be merged as part of the mingw-w64 project. > > There are a couple of advantages over using this to dlltool. > > 1. This tool supports the following targets armv7 aarch64 i686 and x86_64. > where as dlltool currently supports just i686 and x86_64 > (and a really old arm target thats not NT) > > 2. The target is specified at runtime so one build will do for all targets. > (this will be especially useful for cross compiling) > > 3. This tool unlike dlltool complies to the PE/COFF spec 7. > Import Library Format. so that we can interop with other linkers > besides ld. > > The 2 most common use cases would be > > 1. Using llvm's linker lld which is now feature complete for COFF on arm > x86 and x64. > 2. Generate an import lib for msvc to use which dlltool could not do. These are really great news, thanks for the work! :) > I would like to propose we initially have a flag to enable using this when > building the crt. Some of the autotools experts here may know some more on > that. This is because currently ld does not support PE/COFF spec 7 and does > not understand the resulting library. I believe it is best outside of the CRT's build process actually. If you require it as part of the CRT's build, you'll have to build it first which will be an issue for native builds. Sure you could build the CRT without and then rebuild it with it but it's not very friendly to make the compiler bootstrap chain longer (there's already GCC [possibly twice], binutils, the CRT [possibly the headers separately], winpthreads, and soon genlib once). I believe it is better to keep its build separate but be able to do something similar to: ./configure --with-mingw-w64-sources=. And it would build itself as it currently does and would then build the .lib files too. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] Include usb.h with quotes
On Tue, Nov 03, 2015, David Grayson wrote: > Both mingw-w64 and libusb-compat define a header called "usb.h". This issue > was sort of discussed on this mailing list five years ago: > > https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/aanlkti%3dkikjoqdmb3u8brdxrry0vqqejbjbqgqz40...@mail.gmail.com/?page=1 > > Back then, Xiaofan was arguing that mingw-w64 breaks a lot of Linux software > that expects "#include " to bring in the libusb-compat library's > header file instead of the mingw-w64 header file. I actually am having the > opposite problem: MSYS2 installs libusb-compat's usb.h inside > /mingw64/include/, which has a higher precendence than the mingw-w64 headers, > so including usb.h always gives you the libusb-compat header if that package > is installed. > > This problem cannot be fixed with a simple -I flag because of a quirk in how > GCC's search path works: I see that libusb avoids using a toplevel system include directory. Do you really need the -compat stuff? Moreover there's a .pc file for libusb-compat; if build systems rely on pkg-config in practice, then it is trivial to move the file to a sane directory and update the .pc file to reflect that. > > You can add to this list with the `-Idir` command-line option. > > All the directories named by `-I` are searched, in left-to-right > > order, before the default directories. The only exception is > > when dir is already searched by default. In this case, the > > option is ignored and the search order for system directories > > remains unchanged. > > To build the MSYS2 usbview package, we resorted to copying usb.h into a local > directory and adding that directory to the search path with -I. > > This patch helps to address this issue by simply changing angle-brackets to > double quotes in the two places that include usb.h (winusbio.h and usbdi.h). > This guarantees that those two include statements will work as expected. > External source code that wants to include the mingw-w64 usb.h can simply be > patched to include usbdi.h instead, which in turn includes the correct usb.h > using quotes. Let's suppose mingw-w64 should adapt. What about the build of libusb-compat under MSVC? Really, there's a platform and software is built on top of it; it is that software that is supposed to adapt to the platform. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64-tools: genlib - internal tool for import lib generation
On Tue, Nov 03, 2015, Martell Malone wrote: > Just to clear things up here. > > I intend to include the source into the mingw-w64-tools folder so building > for any host should not be a problem. > > As for the option I just would like a configure option in the crt to force > using it instead of dlltool. > ./configure --use-genlib > It should not affect the current building in anyway and can be enabled by > choice. > > Does my explanation this make sense? That's how I had understood it. The difference I see is that binutils is already a build dependency and is always the first step. It's already there so depending on it doesn't change anything. However this isn't the case for genlib. Is it possible to build genlib with only the header set installed? That would actually perfectly avoid my concerns. Also does it have any kind of dependency on a given version of mingw-w64? -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] change the winpthreads license
Hi, Hasn't this already been discussed on this very mailing-list? I'll try to summarize: - no - because there is no reason to since it's already very liberal (almost as liberal as possible) - if you have specific questions, people here will do their best to address them but remember this is not lawyer advice -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc 5.2.1 libgomp testsuite failures with latest runtime and winpthread
On Fri, Sep 11, 2015, Michel Zou wrote: > > You can ping the gcc dudes instead ! > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 Considering the issue, I doubt that only libgomp has the sloppy coding. :) -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Request for mingw-w64 website update
Hi, On Wed, Sep 02, 2015, Martin Mitáš wrote: > > Hello, > > A few days ago, I tried to register on the http://mingw-w64.org in order > to edit link to mCtrl project as it has been migrated from [old] to [new]. > (mCtrl is listed on the homepage as one of projects using mingw-w64.) > > Unfortunately, it seems the registration process is broken. It doesn't > ask for a password and it either doesn't send any generated password by > e-mail or whatever. > > (Who knows how it is supposed to work? The registration wizard does not > tell anything useful in this regard.) It's actually supposed to work in the obvious way: if you don't enter a password, you get a mail giving you a generated one which you can change afterwards. I've had one previous report of a registration issue but the cause was not obvious unfortunately (mail stuff is *fun*, not). Did you try to register with the same mail address as the one you've used to send this e-mail? > So could someone with write access update the link for me, please? > > Links: > [old] http://mctrl.sf.net > [new] http://mctrl.org I've updated it. It's worth noting that the main page has specific edition restrictions (no other page has that). Currently, Jonathan and I can change it (the list isn't set in stone at all but it's meant to be at least a bit restrictive). -- Adrien Nader -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Request for mingw-w64 website update
On Wed, Sep 02, 2015, Martin Mitáš wrote: > Dne 2. 9. 2015 v 11:15 Adrien Nader napsal(a): > > Hi, > > > > On Wed, Sep 02, 2015, Martin Mitáš wrote: > >> > >> Hello, > >> > >> A few days ago, I tried to register on the http://mingw-w64.org in order > >> to edit link to mCtrl project as it has been migrated from [old] to [new]. > >> (mCtrl is listed on the homepage as one of projects using mingw-w64.) > >> > >> Unfortunately, it seems the registration process is broken. It doesn't > >> ask for a password and it either doesn't send any generated password by > >> e-mail or whatever. > >> > >> (Who knows how it is supposed to work? The registration wizard does not > >> tell anything useful in this regard.) > > > > It's actually supposed to work in the obvious way: if you don't enter a > > password, you get a mail giving you a generated one which you can > > change afterwards. > > > > I've had one previous report of a registration issue but the cause was > > not obvious unfortunately (mail stuff is *fun*, not). > > > > Did you try to register with the same mail address as the one you've > > used to send this e-mail? > > I believe so. OK, I'll try to take a look at the logs (currently travelling). -- Adrien Nader -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gdb after cross compiling doesn't seem to work
On Wed, Aug 26, 2015, Roger Pack wrote: On 8/26/15, Roger Pack rogerdpa...@gmail.com wrote: Hello. I've been having a struggle getting something that was cross compiled to be debuggable using native gdb on windows. details: http://stackoverflow.com/a/32233750/32453 OK I was able to figure this out. I'll answer inline here: Question 1: this is expected to just work is that right? Typically I should be able to cross compile something with -g and then copy it to a windows box and use gdb.exe on it and it should work? Yes it should. :) Does anybody know why I might be getting: (gdb) break main ... (gdb) r ... Cannot insert breakpoint 1. Cannot access memory at address 0x42445c process basically hangs very consistently? Even with native gcc 4.9.x I was getting this behavior. Turns out that (as far as I can tell) what was occuring is that I was linking against a library that had some export symbols in it. I was creating a static executable. Somehow this confused the heck out of it. Any thoughts as to whether the root cause of the problem is ld or gdb? Hmm. Sounds like libtool which falls back to statis linking when one of the libraries it needs to link against is not available (as a shared object). The missing library is mentioned somewhere in its (verbose output) in a form which doesn't facilitate reading. Search for I have the ability iirc. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0.4 released
Hi, On Wed, Aug 05, 2015, JonY wrote: Hello all, v4.0.4 is released! (v4.0.3 had a major bug, therefore skipped) This release fixes a couple of bugs found in the last release: * Major performance to winpthread mutex and spinlock implementation courtesy of Mattias Engdegård. * tchar.h now included in w32api mode installation. And here are the downloads: http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0.4.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0.4.tar.bz2.asc http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0.4.tar.bz2.sig This is great news. However I'm wondering about the general versioning scheme. Wouldn't it have made more sense to name it 4.1.0? In other words, when do we use that middle number and set it to something else than 0? Also, you should update the website. (btw, I'm aware of one registration issue on the wiki for the website and so far it hasn't been fully diagnosed partly due to a lack of time and due to its complexity but I'll get back to it as soon as possible) -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] About the recent sourceforge events
Hi, One more service provider to mention and I think that one is very notable: launchpad. Historically, launchpad had only supported code hosting through bazaar but this is no longer the case: http://blog.launchpad.net/general/git-code-hosting-beta It's still beta but it seems it is already usable and launchpad has all the features currently used by mingw-w64 on sourceforge: mailing-lists, code hosting, forum, bug tracker, file hosting, ... and the UI isn't too clumsy. I haven't yet tried to setup a project there but I have fairly high hopes for it. -- Adrien Nader -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wchar_t vs char
On Tue, Jun 30, 2015, Alexandre Pereira Nunes wrote: Only UTF32 has fixed length encoding (I overheard people saying it's not exactly true even there, because it has unrepresentable code points, but I never confirmed). Unicode allows you to take a character like 'e' and add twenty different types of accents on it at the same time. Quite obviously this cannot work with a fixed-length encoding. -- Adrien Nader -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Please keep the website's download section up-to-date
Hi, On Thu, Jul 02, 2015, Stephen Kitt wrote: Hi Adrien, On Mon, 22 Jun 2015 23:29:17 +0200, Adrien Nader adr...@notk.org wrote: There have been concerns on various places on the Internet that the download page on the mingw-w64 website at http://mingw-w64.org/doku.php/download is not consistently kept up-to-date. The website is a simple and friendly wiki with open registration and if/when mingw-w64 moves away from sourceforge, it will be the place which will not be impacted during the transition. Considering this topic has gotten much hotter recently, it is really important to not completely rely on the sourceforge file release system for listing as some of you currently do. I tried to register but I can't get the registration page to work... I clicked on Login at the bootom of the page, then Register on the login page, filled in my details, but clicking on Register always brings me back to the same registration page. Thanks for caring about this. :) You should have received a confirmation e-mail. I know that at least office365 loves marking them as spam so you should also check there. (and gmail loves marking everything not @gmail.com as spam) Note that I was on a business trip and I'm still catching up with the past few days so I haven't checked in depth. -- Adrien Nader -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Please keep the website's download section up-to-date
Hi, There have been concerns on various places on the Internet that the download page on the mingw-w64 website at http://mingw-w64.org/doku.php/download is not consistently kept up-to-date. The website is a simple and friendly wiki with open registration and if/when mingw-w64 moves away from sourceforge, it will be the place which will not be impacted during the transition. Considering this topic has gotten much hotter recently, it is really important to not completely rely on the sourceforge file release system for listing as some of you currently do. -- Adrien Nader -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-64 and MSVC x64 ABI
Hi, On Thu, Jun 18, 2015, lh_mouse wrote: g++ and clang++ use Itanium ABI while MSVC uses some M$ specific, unpublished ABI. Hence it is not surprising that they are incompatible with each other. As far as I know, GCC is very close to MSVC's C++ ABI currently and only one or two things are different. I regularly ask Kaï about this and invariably I forget about the exact status (I don't do C++ nor MSVC) but it's definitely getting more and more similar. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] About the recent sourceforge events
On Thu, Jun 11, 2015, Ruben Van Boxem wrote: 2015-06-10 23:24 GMT+02:00 Adrien Nader adr...@notk.org: My initial notes for possible other service providers: http://librelist.com/ for mailing-lists - activity status unknown (not asked) - dispute resolution process unknown (not asked) - only mailing-lists http://www.tuxfamily.org/en/about for everything but bug tracker; but bug tracker software can be installed without trouble - not terribly active but definitely maintained - admins are known and are free software activists, makes it possible to take over in case some more admin is needed http://github.com for code hosting, web pages hosting (not binaries), light bug tracker, not mailing-lists nor forums - possible network effect (although I have some doubts considering the difficulty of most tasks) - hosting of large binaries is not guaranteed at all - hosting of binaries is couple to actual releases https://notabug.org/ only code hosting? - the gogs software is fairly new and doesn't have all features needed as far as I know http://codingteam.net everything but forum and mailing-lists - has a fairly nice look - the website warns that their current resources are not enough for livecd-style downloads and it's probably the same with large binaries that are currently in the file release system http://savannah.nongnu.org or http://gna.org everything but forums - mailing-lists! - well-known - need to check the current mingw-w64 usage of file downloads matches well - need to check how much graphical communication can be done on the project page (remember there is already a website to serve as frontend) Here's another two to add to the list: http://www.codeplex.com/ (see http://www.codeplex.com/) - mailing lists - source code - downloads - issue tracker - wiki - continuous integration bitbucket.org - might be limited to 5 users collaborating on a project - source code, - downloads, - issue tracker - wiki - no mailing lists and of course the always available option: Thanks. For mailing-lists, POQDavid on IRC has reminded me of http://www.freelists.org/ . Again, only mailing-lists but that's the most annoying thing to handle across all the features provided by sourceforge. Private server/hosting - costs money Not the main issue. - needs someone maintaining the guts Main issue, by far. Hosting is cheap enough and can be sponsored but admin time not so much. Plus it's a job that is high-risk and low reward and consideration. - can do everything at once - can it handle the load? Load shouldn't be an issue. 10k downloads per day of 100MB is 1TB, which is around 100Mbps. If we were to reach such a bandwidth in practice, we'd be sooner kicked off from the free hosting than from a dedicated server. I think it is a good idea to at least have project names taken on the large hosting sites (codeplex, github, savannah) so that the name is not taken by anyone else. The project can then link to the main site and mirror the git repository. On github there's already https://github.com/mingw-w64 but I have no idea who is behind that. I've registered projects on codeplex and bitbucket. I was feeling a bit lazy for savannah: worst case we get in touch with the admins there. Bitbucket apparently didn't want to keep hyphens so it's at https://bitbucket.org/mingww64/mingw-w64 . For codeplex, they require several more steps which I really don't feel like doing now (push code, add a description, chose a licence [ mingw-w64 doesn't fit in their license choices ] and another one which I've forgotten). The project will be deleted in 30 days if thie steps aren't done. We'll see by then. We couldn't keep the hyphen either. If Sourceforge continues its actions like this, MinGW-w64 needs to keep its options open. No action is required now, but at least opening some doors never hurts, and reserving a project name with other hosting sites only spreads MinGW-w64 availability and fame. That's really the spirit. Noone feels like doing the work currently but we should also make sure sourceforge cannot do bad stuff easily. I've been unable to track down how many people get on the sourceforge page directly rather than through what is now at http://mingw-w64.org and how they get there. It's quite opaque and sometimes dubious. Unfortunately that means that putting direct links to files and screenshots and anything else will not make most people safe in case something happens. Unfortunately^2 this also means we'll have to think about redistributions of binaries by sourceforge or another group in the future. Installers that come with adware is something that has been seen for VLC, Firefox and OpenOffice at least. They mostly solved that through trademarks as far as I know but that's probably a topic for another day. -- Adrien Nader
[Mingw-w64-public] About the recent sourceforge events
Hi, You might have seen news about sourceforge.net hijacking projects or project names to distribute adware (or worse). Following this, several projects have started to move away from sourceforge. Since we use it, moving away from it is a question that we must bring up (this is not a vote thread). As of today, we are not moving away from sourceforge.net nor planning a move. We are merely assessing the current and possible future situations. We haven't have troubles ourselves so far. First, a recap of what has happened. For several years, sourceforge.net has proposed projects to wrap their installers in installers for adware. Revenue is shared between SF and the project. This has been accepted by Filezilla at least and the blame lies on both filezilla and sourceforge (one for thinking about it, the other for accepting it). Two weeks ago, the GIMP people found out that a Windows installer, that wasn't updated anymore but was still available for download, had been wrapped in the same kind of adware installer without any consent from them. [1] A number of projects have since then been complaining about similar things too. One notable is nmap. To the best of my knowledge, the issue is different and is actually about large DOWNLOAD THIS-style ads in the download page, i.e. much bigger than the actual button. Recap done. This isn't a very fun topic but as I said above, it must be brought up. Should the mingw-w64 project seek to move entirely or partially away from Sourceforge? If at least one service should be moved away from it, how can its features continue to be provided in the future? Currently the website is a dokuwiki, hosted elsewhere, with a domain name upon which we have full control. Since it is a wiki, we don't have a use for a separate service. The mailing-lists, file downloads, bug tracker, forums and git hosting are all services provided by sourceforge. Apart from the forums, all of these are heavily used (and even the forums have seen an increase in usage recently). It probably makes no sense to move anything if the file downloads don't move. Sourceforge is one of the few services providing all of these for free. Please answer with your thoughts on the matter (but again, no vote, no +1 or similar) and how the services could be replaced. [1] https://mail.gnome.org/archives/gimp-developer-list/2015-May/msg00144.html -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] About the recent sourceforge events
My initial notes for possible other service providers: http://librelist.com/ for mailing-lists - activity status unknown (not asked) - dispute resolution process unknown (not asked) - only mailing-lists http://www.tuxfamily.org/en/about for everything but bug tracker; but bug tracker software can be installed without trouble - not terribly active but definitely maintained - admins are known and are free software activists, makes it possible to take over in case some more admin is needed http://github.com for code hosting, web pages hosting (not binaries), light bug tracker, not mailing-lists nor forums - possible network effect (although I have some doubts considering the difficulty of most tasks) - hosting of large binaries is not guaranteed at all - hosting of binaries is couple to actual releases https://notabug.org/ only code hosting? - the gogs software is fairly new and doesn't have all features needed as far as I know http://codingteam.net everything but forum and mailing-lists - has a fairly nice look - the website warns that their current resources are not enough for livecd-style downloads and it's probably the same with large binaries that are currently in the file release system http://savannah.nongnu.org or http://gna.org everything but forums - mailing-lists! - well-known - need to check the current mingw-w64 usage of file downloads matches well - need to check how much graphical communication can be done on the project page (remember there is already a website to serve as frontend) -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64.org
Hi, I don't think I had sent a proper notice about this yet. I was able to register the mingw-w64.org domain recently and changed the redirection on mingw-w64.sourceforge.net to point to that domain. The mingw-w64.yaxm.org domain has been made to point to that new domain too. The website also got a responsivity improvement: RSS data was being fetched for each page visit and added latency corresponding to that. If you have a website and link to mingw-w64.sourceforge.net, please update your links since we have more control on the domain name features and need the search engines to pick up. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Preferred build system, installation methods and download page links.
for Windows and therefore improve the quality of Windows support in free software while also requiring less time. It is also going to support Mac OS X and *BSD systems soon. Actually it should already pretty much work and if Apple wasn't the crap company it is (want to test your software on their operating system? buy expensive hardware from them), it would already be finished. Even on Windows it comes with very few strings attached. I've tested with several IDEs and was able to setup everything easily. The only two exceptions were Codelite (the issue really looked like a bug in codelite) and iirc Netbeans (it required an msys-style installation: posix makefiles and shell). What bothers me with the MSYS2 crowd on this mailing-list is their bias. It's a very natural one and I'm not blaming anyone at all. My point is that I could say that Linux is the OS on which people build and use mingw-w64, and most here would probably agree. However the reality is that this mailing-list and the people directly involved in the project are not at all representative of the users. We're not even the 1%, we're closer to the 0.1%. Half of the proponents of msys2 seem to have used Arch Linux first. I doubt this is representative of the actual users. Most probably use IDEs and would never want to abandon them. Requiring command-line, even for short amounts of time, is the same story. (by the way: please don't think about masquerading anything with an msys-style behaviour as a typical windows executable, it'd be a dis-service to users who would probably get difficult-to-understand bugs) Long mail already so I'll try to summarize without forgetting too many things: - platform support is different and support for compiling on windows is a minor and natural cost (deploying GCC's .dll files was the first reason) - the vast majority of people does not want to deal with something command-line and/or posix/linux - I'm not saying msys2 is bad - approach to packaging, distribution and maintenance are different; doesn't make one better but for sure, there are people to prefer each one over the other Regards, Adrien Nader http://win-builds.org -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] A logo for MinGW-w64
On Wed, Apr 15, 2015, Earnie wrote: Caution, MINGW is a registered trademark. Its use must get permission from the owners of the trademark. Why does this only get mentioned when it comes to the logo for mingw-w64? -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] A logo for MinGW-w64
Hi, First of all, thanks for making these. A logo has been lacking for quite some time and it only became more apparent with the new website since there's a place ready for it but left empty. The topic was discussed a bit on IRC and people were already fairly happy (well, the snakes one was a bit surprising :P ). By the way, I'm not sure we can use the GNU gnu since we're not a GNU project even though it is in the original name. About holding a contest, I believe this is a good idea for the various reasons already mentioned. I have absolutely no experience with that however and fairly little free time. I'll help with any admin stuff I can however. Is there a preferred platform for voting? There are a few vote/poll plugins for dokuwiki but it might lead to fewer voters (since it'll require a separate registration; that said I don't know how to prevent people from voting several times without some kind of registration). -- Adrien Nader -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes - download2
Hi, I wasn't happy with the download page since it had become way too big so I re-thought it a bit and made a demo at http://mingw-w64.yaxm.org/doku.php/download2 It's only a demo and only has a few lines but these should be enough to get a good feeling of what the final page will be. The data is not necessarily correct currently. I'm not saying more since I'd like to get a feedback from people who first encounter the page. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes - download2
Just a small note: with this approach there will be one additional page per toolchain provider with the full details there. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
(catching up with my mails LIFO-style, the best way to cause huge delays) On Wed, Mar 25, 2015, Ruben Van Boxem wrote: 2015-03-24 21:20 GMT+01:00 Adrien Nader adr...@notk.org: Hi, On Tue, Mar 24, 2015, David Macek wrote: On 20. 3. 2015 22:51, Adrien Nader wrote: Hi, I've just pushed a redirect from http://mingw-w64.sourceforge.net to http://mingw-w64.yaxm.org in order to serve a new website. [snip] Any constructive criticism is welcome; don't hesitate. Hi. I took a look on the website and I've got some notes which may or may not be applicable to other visitors: === Downloads/Others: The first paragraph in the tab talks about OS X builds straight away, as if Others == OSX. This also led to an impression that Rubenv's builds are also for OS X. Also most of the contents of the tab seems to belong to other tabs. I imagine that if a visitor was interested only in toolchains for Windows, he/she could be led to believe that the three options in the first tab were the only one, because he/she would never even look at the Others tab and discovered the link to SF.net file repository. The following organisation would make more sense to me: I propose 1) moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or completely outside of them), and 4) renaming the tab from Other to OS X. I don't think moving these mentions from the Others tab to the other tabs will confuse users as to which one to download, as the gray boxes with logos serve well to make their contents seem as more trust-worthy than the plain text around. The Others tab has not received much love and that dates back to the creation of the download page on the previous website. When I put rubenvb and opensuse toolchains back when I created the download page (it's been some time already), the reactions I had received from both upstreams were at best meh and without many more details so I couldn't do a lot. I really wanted to put them somewhere though (I think Opensuse's effort started at least 7 years ago and rubenvb toolchains were widespread). Ideally they'd be in a proper place: the others section would ideally only contain the link to Sourceforge's FRS. That requires the corresponding toolchain creator to provide information about their releases. I think I sent you an email with the required info as you asked for way back when. If I didn't, my fault, but I'm not too worried about my toolchains. They are dated now and should really be retired from the download page. I don't remember receiving such a mail. Since that was already a fairly long time ago, I don't remember well but maybe you had sent some infos but not enough details which was probably quite a lot of work considering the diversity of your toolchains. Following Vincent Torri's mail, I did some changes this morning and I just noticed I had not done these changes for every block but only for the ones that fell under Windows and Linux tabs. I've now corrected it. Basically I've removed title elements and added blue-colored blocks instead. They should make it easier to tell each block apart. Can you check the page again and tell me if it looks better? Also, the OS X situation currently is not very good as there is toolchain provider and the toolchains that are available are old, experimental and unsupported. I'm not worrying about it at the moment since it should change soon (more on that later on). === Downloads/Source: This may be just my profession talking, but links to various stuff on SF.net with SourceForge as the title seem misleading. === Downloads/Linux: I know Arch Linux users are generally competent, but I'd like to see the link point to something actually related to mingw-w64, rather than just to AUR homepage. This may be a good link: https://aur.archlinux.org/packages/?SeB=nK=mingw-w64SB=cPP=250 I'm not an Arch Linux user and the link in place was the only one I had. I've updated the page, thanks. Also, wouldn't it be better to also mention the packages in official Arch repos? https://www.archlinux.org/packages/?q=mingw-w64 They don't seem outdated or anything. I wasn't aware of these packages (maybe they're newer than the arch-linux-related update). I'm not sure how they relate to AUR ones; I'm under the impression the toolchain is in the base and non-toolchain packages should be built from AUR but I need a confirmation from at least one actual user. I can confirm whatever you need: I made the original AUR packages, these were absorbed into the binary [Community] repository, and they contain a complete toolchain (c,c++,objc,obj-c++,fortran,ada) with the latest released versions and is updated regularly. Development versions naturally belong in the AUR for which everything
Re: [Mingw-w64-public] [ANN] Website changes
On Tue, Mar 31, 2015, Stephen Kitt wrote: On a related note, I'll try to spend time next week-end to improve the layout of the tables a bit as they'd probably benefit from cell borders (I find them a bit difficult to read at times with their current style). That would improve the readability of merged cells in particular! It was bothering me so I did it. I've also made the cell text vertically-centered. While at it I've enlarged the website (it was limited to 70em, now it's limited to 80em) [ I have many screens with many resolutions and pixel densities around but haven't had time to test with them ] and removed the scrollbars in the download tabs. Of course the whole operation should have taken a few minutes but since it involves CSS it took much more than that and the result is a bit uncertain but it seems to work fine. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
Hi, On Sat, Mar 28, 2015, Jason Curl wrote: On 20/03/2015 22:51, Adrien Nader wrote: Any constructive criticism is welcome; don't hesitate. Hi, on the page: http://mingw-w64.yaxm.org/doku.php/documentation the link to libmangle is broken. Clicking on it takes me here: http://mingw-w64.yaxm.orglibmangle/ Thanks for the notice. This was due to an overly simple rewrite rule. Libmangle's API documentation is still on sourceforge servers. Note that since the redirects use the HTTP 301 code, your browser is going to be a bit reticent to asking the server again for the actual location of the page (i.e. clear your cache). -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
Hi, On Sun, Mar 29, 2015, Stephen Kitt wrote: Hi, On Tue, 24 Mar 2015 21:20:04 +0100, Adrien Nader adr...@notk.org wrote: [...] There's an additional reason: I'm seeing cygwin similarly to fedora/opensuse/arch. If someone is already using these, the entries on the website will make him check his version requirements and look at his distro package manager. They probably won't make anyone start using these distros however. Some distros have recent versions, some don't (debian, ubuntu) and I believe this page can help the user by providing something simple to read. [...] Would it actually be possible to mention the Debian and Ubuntu toolchains on the download page? Most people find MinGW-w64 via the MinGW-w64 web site rather than via their distribution, and I regularly get emails from people surprised to find out that the toolchain is packaged in Debian/Ubuntu: since it's not mentioned on the MinGW-w64 website they figure that their only solution is to download one of the Win-builds. Anyway, we currently support: * Debian 7 (Wheezy): builds for i686, x86_64; gcc 4.6.3, MinGW-w64 2.0.3, with C, C++, Fortran, Ada, Objective-C and Objective-C++ compilers; C11/C++11 threading isn't supported; the package manager is Apt/Dpkg; installation is done within Debian (https://packages.debian.org/mingw-w64) * Debian 8 (Jessie): as above, with gcc 4.9.1, MinGW-w64 3.2.0; C11/C++11 threading is supported (a Win32 threading variant is also available) * Debian has MinGW-w64 4.0.1 in the experimental repositories * Ubuntu 12.04 (Precise Pangolin): as above, with gcc 4.6.3, MinGW-w64 2.0.1 (https://launchpad.net/ubuntu/+source/mingw-w64) * Ubuntu 14.04 (Trusty Tahr): as above, with gcc 4.8.2, MinGW-w64 3.1.0, C11/C++11 threading (using winpthreads) * Ubuntu 14.10 (Utopic Unicorn): as above, with gcc 4.9.1, MinGW-w64 3.1.0, C11/C++11 threading (a Win32 threading variant is also available) * Ubuntu 15.04 (Vivid Vervet): as above, with gcc 4.9.2, MinGW-w64 3.2.0 The only additional software currently available is gdb and nsis. Thanks for the list. Can you check the information is correct? I've not added a line for debian experimental since it's expiremental and changes quite often: it needs someone actively updating the page. I'll ping you when the user registration stuff is fixed if you want. On a related note, I'll try to spend time next week-end to improve the layout of the tables a bit as they'd probably benefit from cell borders (I find them a bit difficult to read at times with their current style). -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
On Tue, Mar 24, 2015, Ray Donnelly wrote: On Tue, Mar 24, 2015 at 9:46 AM, Ray Donnelly mingw.andr...@gmail.com wrote: On Tue, Mar 24, 2015 at 8:36 AM, Adrien Nader adr...@notk.org wrote: On Tue, Mar 24, 2015, Ray Donnelly wrote: On 24 Mar 2015 07:06, Adrien Nader adr...@notk.org wrote: Hi, On Sat, Mar 21, 2015, Norbert Pfeiler wrote: Hi, it’s nice to see an update on the website, looks good. What I’d like to see though, is a mention of msys2 in the downloads section. The difficulty with an msys2 entry on the page for downloads has so far been that it's not really like other download entries. There could be a new tab for tools but it might be not very visible (I'm not 100% happy with the current tab stuff on the download page but I think it's good enough for /now/). I'm definitely after ideas on how to properly organize things while remaining focused on the user (probably 99.99% of people use mingw-w64 through IDEs unlike 99.99% of the people on this mailing-list; and they tend to not look very far on a website). Have you actually used MSYS2? It is very similar in scope to win-builds. I know what it does and how. My concern is that just throwing another link on the page is not going to help any visitor. But maybe what you have in mind is to just insert it at the same level as other downloads for the runs on windows tab but then the unique stuff about msys2 is not going to be visible. When I mention the 99.99% of users, I'm sad about it: most people really don't spend a lot of brainpower when it comes to download something. I believe that if a link is added in the middle of one of the page, without further UX consideration, it'll simply be not visible to people who care and confusing to the others (those who use IDEs). Now, if the majority thinks it should be added right now, provide the block content and I'll copy it immediately. I guess you should take a poll on IRC regarding the majority, here's some text. Is that meant to be condescending? Let's say it isn't. I'm never ever going to define majority as people on IRC who are online and active at one given moment. But anyway, the whole point of the website is to help new users. More than half the people I know of on the IRC channel are running Linux and I'm not expecting them to give an in-depth analysis of MSYS2. MSYS2 is a modern version of MSYS, both of which are Cygwin (POSIX compatibility layer) forks with the aim of better interoperability with native Windows software. It aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains. It comes with a port of ArchLinux's Pacman package manager. Three repos are provided with over 1000 packages. Actually we'd prefer MSYS2 is a modern rewrite of MSYS .. I'm afraid this is not going to be enough. More than two decade ago, the Web was born. And it had hyperlinks from day one. Where does that even go? Next to the other entries currently there? It needs a block title, a download link, the CRT and GCC versions in use, the languages supported by the toolchains, and so on. Look at the current page and make something that fit in. I still believe MSYS2 will not fit in properly and I still believe it would be better served by a better general organization of the website (actually I don't care about MSYS2: I care about users) but the last thing I want to do is spend time arguing on the Internet so please provide something that I can integrate (I don't care for markup but I need the data) and that is useful to the visitors. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
Hi, On Sat, Mar 21, 2015, Vincent Torri wrote: hey imho, you should add a paypal link with a nice icon on the front page, and not only in the 'donate' page. I don't really like the paypal logo for technical reason: I think you're not actually allowed to host it yourself and you need to have the visitor's browser fetch it on every visit from paypal server (great, right?). Anyway, it'd probably look out of place if it were the only logo on the page: there's a need for more pictures on the page. I can re-use some from the previous website (and there was a money one) but there will still be a large hole: a project logo. Until then I'm very reluctant to put a company's logo somewhere since it could be ambiguous. I'm going to add a few pictures so tell me what you think (you need to wait for at least 30 minutes after this mail is sent :) ). -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
Hi, On Sat, Mar 21, 2015, Norbert Pfeiler wrote: Hi, it’s nice to see an update on the website, looks good. What I’d like to see though, is a mention of msys2 in the downloads section. The difficulty with an msys2 entry on the page for downloads has so far been that it's not really like other download entries. There could be a new tab for tools but it might be not very visible (I'm not 100% happy with the current tab stuff on the download page but I think it's good enough for /now/). I'm definitely after ideas on how to properly organize things while remaining focused on the user (probably 99.99% of people use mingw-w64 through IDEs unlike 99.99% of the people on this mailing-list; and they tend to not look very far on a website). -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Website changes
Hi, On Tue, Mar 24, 2015, David Macek wrote: On 20. 3. 2015 22:51, Adrien Nader wrote: Hi, I've just pushed a redirect from http://mingw-w64.sourceforge.net to http://mingw-w64.yaxm.org in order to serve a new website. [snip] Any constructive criticism is welcome; don't hesitate. Hi. I took a look on the website and I've got some notes which may or may not be applicable to other visitors: === Downloads/Others: The first paragraph in the tab talks about OS X builds straight away, as if Others == OSX. This also led to an impression that Rubenv's builds are also for OS X. Also most of the contents of the tab seems to belong to other tabs. I imagine that if a visitor was interested only in toolchains for Windows, he/she could be led to believe that the three options in the first tab were the only one, because he/she would never even look at the Others tab and discovered the link to SF.net file repository. The following organisation would make more sense to me: I propose 1) moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or completely outside of them), and 4) renaming the tab from Other to OS X. I don't think moving these mentions from the Others tab to the other tabs will confuse users as to which one to download, as the gray boxes with logos serve well to make their contents seem as more trust-worthy than the plain text around. The Others tab has not received much love and that dates back to the creation of the download page on the previous website. When I put rubenvb and opensuse toolchains back when I created the download page (it's been some time already), the reactions I had received from both upstreams were at best meh and without many more details so I couldn't do a lot. I really wanted to put them somewhere though (I think Opensuse's effort started at least 7 years ago and rubenvb toolchains were widespread). Ideally they'd be in a proper place: the others section would ideally only contain the link to Sourceforge's FRS. That requires the corresponding toolchain creator to provide information about their releases. Following Vincent Torri's mail, I did some changes this morning and I just noticed I had not done these changes for every block but only for the ones that fell under Windows and Linux tabs. I've now corrected it. Basically I've removed title elements and added blue-colored blocks instead. They should make it easier to tell each block apart. Can you check the page again and tell me if it looks better? Also, the OS X situation currently is not very good as there is toolchain provider and the toolchains that are available are old, experimental and unsupported. I'm not worrying about it at the moment since it should change soon (more on that later on). === Downloads/Source: This may be just my profession talking, but links to various stuff on SF.net with SourceForge as the title seem misleading. === Downloads/Linux: I know Arch Linux users are generally competent, but I'd like to see the link point to something actually related to mingw-w64, rather than just to AUR homepage. This may be a good link: https://aur.archlinux.org/packages/?SeB=nK=mingw-w64SB=cPP=250 I'm not an Arch Linux user and the link in place was the only one I had. I've updated the page, thanks. Also, wouldn't it be better to also mention the packages in official Arch repos? https://www.archlinux.org/packages/?q=mingw-w64 They don't seem outdated or anything. I wasn't aware of these packages (maybe they're newer than the arch-linux-related update). I'm not sure how they relate to AUR ones; I'm under the impression the toolchain is in the base and non-toolchain packages should be built from AUR but I need a confirmation from at least one actual user. === Downloads/Windows: Mentioning Cygwin while omitting MSYS2 seems weird, given the numbers of packages they provide. I'm definitely in favor of mentioning MSYS2 in this tab. Is there a reason Cygwin is first in this list? Jonathan gave me the relevant information and, to the best of my knowledge, it is still (mostly) correct. There's an additional reason: I'm seeing cygwin similarly to fedora/opensuse/arch. If someone is already using these, the entries on the website will make him check his version requirements and look at his distro package manager. They probably won't make anyone start using these distros however. Some distros have recent versions, some don't (debian, ubuntu) and I believe this page can help the user by providing something simple to read. MSYS2 is different in that there's a lot more to say. I also don't want to make all the content myself and had had no actual feedback on that front before. Cygwin is first because the lists are sorted alphabetically. I don't think I want to start changing that. === Overall, the website looks very good IMO. Good to hear. :) I
[Mingw-w64-public] [ANN] Website changes
Hi, I've just pushed a redirect from http://mingw-w64.sourceforge.net to http://mingw-w64.yaxm.org in order to serve a new website. I have been taking care of the website for at least a couple years now. Not that I particularly enjoy doing PHP, CSS and Javascript but there was a need. However I suck at design and I had very little time available, which meant all the changes I could do were minimal. Last week I finally bit the bullet and spent half a day assessing whether something based on dokuwiki could work and then spent a day moving the data from the website to that dokuwiki and tweak its them and plugins. This was discussed a bit over IRC and the switch has been hurried by the release of 4.0: I was feeling miserable each time I had to update anything on the website and I really didn't feel like taking one hour just to add a section to the existing layout, especially knowing the website replacement was going to occur soon. The now-old website is still available, only masked through a redirect. Please speak up if you are not pleased with the new one. One notable change is that the website is not served through sourceforge.net anymore. I had started with everything on SF but more often than not, the pages would fail to load. Unfortunately this means there is a user-visible redirection on a temporary subdomain; this is expected to remain for one month at most. NB: this does not change anything else; nothing but the website that has been visible on http://mingw-w64.sourceforge.net changes. The wiki from sourceforge is going to be abandoned. Well. Noone has touched wiki2 since it was set up a year ago so it's not a big loss. Dokuwiki should be a nicer place for wiki changes (faster, cuter, and fully integrated into the website obviously). The only minor downside currently is that users cannot register themselves to change the website. This is minor since I can do it on request and because the set of pages that is currently up will not be editable by most people anyway (i.e. main page, downloads). This will be fixed. On a final note I'd like to thank the author of the initial mingw-w64 website. As far as I remember he had a company named CodeCamel but currently the website is MIA but the domain name has been parked with seemingly-innocuous link spam. That website has served mingw-w64 well for around 5 years. Its replacement did not happen out of discontent but because a lot has happened over these 5 years, both the web (mobile, many new viewport sizes, saner browsers, ...) and for mingw-w64 (so many more users, contributors, activity on all fronts and much more content). Working with sourceforge.net SSH access was the painful part as it was slow and not having a CSS theme used (and tested) by many other websites made the process brittle and time-consuming. I wished there had been time to bring the topic on the mailing-list before doing the switch but v4.0 timing made that hard and I've also taken great care to not lose anything in the process. Any constructive criticism is welcome; don't hesitate. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Native Win32 std::thread
Hi, To add a bit to Ruben's answer. Winpthreads is a library designed to provide pthread's API and its typical ABI since many software assume pthread_t is an integer (it's the case on Linux and many other OSes). Pthreads-win32 has a different ABI where pthread_t is a struct instead (as far as I remember, in winpthreads, the integer is used to lookup the actual struct). I don't know how the performance of the two compare but I've already had cases where that ABI was assumed and winpthreads' approach basically saved the day. I haven't heard many complaints about its stability either but I've read several posts about it having a lower performance. In other words: it works but it's not as fast as it could be, and obviously there are always more things to do than people can spend time on. I think we also didn't get many real-world benchmarks showing there's a performance issue and that made it more difficult to improve winpthreads. The relicensing of mingw-std-threads happened only a few weeks ago and I don't think anyone has been able to spend time on it (no-one had looked at it in-depth before because the license made it unusable for mingw-w64). Having a real-world usage and motivation, it would be really great if you were able to spend some time on improving winpthreads (maybe even beating MSVC as is done with the math library :) ). Version 4 of mingw-w64 is about to be released and such changes will therefore only be in version 5 but that also means it's the right time to introduce large changes (plus the time between major releases is getting much smaller: 5 isn't that far away either). I've just spent some more time looking at winpthreads and it's slightly more complex than it uses kernel objects while it should use userland ones because both are used and it would be valuable to have at least a profile with winpthreads to see which branches are taken in practice. Regards, Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0-rc3 released
Hi, On Wed, Mar 04, 2015, Stephen Kitt wrote: Hi, On Wed, 04 Mar 2015 21:51:51 +0800, JonY jo...@users.sourceforge.net wrote: Without further ado: http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0-rc3.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0-rc3.tar.bz2.sig The signature fails for me: % gpg --verify mingw-w64-v4.0-rc3.tar.bz2.sig mingw-w64-v4.0-rc3.tar.bz2 gpg: Signature made Wed 04 Mar 2015 14:32:07 CET gpg:using DSA key 0x93BDB53CD4EBC740 gpg: BAD signature from JonY jo...@users.sourceforge.net [unknown] The file is truncated. -- Adrien Nader -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [URGENT] Project _and_ tutors for GSoC 2015
Hi, The deadline for organizations is only a few days ahead and if we want mingw-w64 to take part in it, we need to do it _now_. There are some project ideas at http://mingw-w64.sourceforge.net/contribute.php This is by no mean an exhaustive list but at least it's a start. GSoC needs something more: the corresponding tutors. If you have an idea, please send it here. If you have an idea and can tutor for it (or for another idea), please reply here too. Having only one tutor per idea or task isn't enough: the more the better. This is sent a bit in a hurry and I've probably forgotten stuff but basically, if we don't get a nice list of projects and tutors in the next 3 days, mingw-w64 won't be in GSoC 2015. -- Adrien Nader -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.5.0 - fully-bootstrapped free software distribution for Windows
-compiled from Linux for Windows is probably close to a full-time part-time job, i.e. something that will take all the time for someone doing part-time on it. My perception is probably flawed since I've made the initial packaging and it includes things that have probably never been done before and definitely deviate from what upstream had in mind (i.e. cross-compile qmake itself). It is also unfortunately to be expected that each new version of Qt breaks something for this packaging (cross-compile to Windows). As such, additional maintainers are looked for. There is no reason to be afraid and this is not about abandoning the package unless someone steps up. This is entirely in order to be able to better track upstream releases. Security Updates This part has mostly been a failure. The work involved was larger than expected and was let slip by without bound. Basically, the work (reading, updating the source, rebuilding, testing, uploading, announcing) is sometimes too much to do immediately after the availability of a security fix. With no strict bound and with the need to spend time on large changes in the build architecture, the updates have slipped by one day at a time. As usual, Frederick P. Brooks got it right: Q: How does a large software project get to be one year late? A: One day at a time. The larger architecture have been done. There will be others but they should be less pervasive and shouldn't block working on other tasks for as much time. More importantly, at least for this release, the official goal is to handle most security updates in 3 days at most and let none slip by more than 8 days. This should be at least as good as most large Linux distributions. Any security update lagging behind for more than that should be considered unnoticed and a poke warranted. PS [1] It obviously takes some time to extract the 25MB or so (8MB compressed) but it is fast enough and can most probably be made faster. The main advantage however is that this solves the issue of replacing files which are in-use: the package manager depends on .dll files and therefore would have been unable to ever replace these without resorting to complex tricks. [2] Perhaps the best proof is the following top-level code: let init_count = ref 0 let init () = if !init_count = 0 then ( do_the_actual_init (); incr init_count; ) else () let () = init () On Windows I had to add an explicit call to the init function from somewhere else in the code. -- Adrien Nader http://win-builds.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How to recognize symlinks in WIN32?
On Thu, Jan 15, 2015, Greg Jung wrote: Thanks all, let me summarize the situation: cygwin has its own trick to make a symlnk where the native OS doesn't cooperate, which is a simple file beginning with the char[11]='!symlink' then 0xFF,0xFE, then wide-char name of where the link points. In windows a symlink creator needs elevated privilege and so native symlinks may not be sufficient. cygwin lstat is trained to recognize this. The first clue is that it is a system file - if the system attribute is erased, cygwin looks at a simple file. (It doesn't care that it is marked hidden or not). Then symlinks would have '!symlink',0xff,0xfe as first 12 bytes; incorporating winsymlinks:native invokes the cygwin ln command to create native symlinks if the shell is run as administrator, cywin links if not. winsymlinks:nativestrict would break non-native symlink creation. That's all very useful thanks for the help. In a few words: cygwin, and therefore msys*, are additional layers which provide almost posix on top of win32 and do their very own stuff. Win32 and POSIX symlinks have little in common besides the name and you shouldn't have to take special care for files which are created by either since they're emulating the functionality, even on systems without reparse points, junctions and win32 symlinks (i.e. they use dirty tricks to do it). (and actually I think msys doesn't symlink but copies) -- Adrien Nader -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] dongdheng 20141215 seriously gutted
Hi, On Thu, Dec 18, 2014, Jim Michaels wrote: there is like all of 5 header files in the include dir. not sure what's going on. - It's actually very simple. These are daily builds and this means they get the bugs from binutils, from gcc, from mingw-w64 and possibly also from mpfr, gmp, ppl and a metric tonne of other problems simply because they're all development snapshots. It's difficult to guess the source of the issues but mingw-w64 is fairly low activity compared to GCC so in doubt I'd first look there (well, first check the build logs along with the changelog of mingw-w64.git). It's also likely the issue is not specific to Windows and would be better raised at GCC's bugzilla. The only conclusion I can draw from your report is that you're expecting such daily/experimental builds to work while you should probably expect the opposite and merely _wish_ that the daily builds work. -- Adrien Nader http://win-builds.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFE: New stable release
Hi, On Mon, Dec 15, 2014, Michael Cronenworth wrote: Hello, The current stable release branch is not able to build the wine-gecko project while the latest git checkout is. There are 5 new files and a dozen headers with missing or incorrect definitions that wine-gecko expects. When will the next stable branch release be made against what is in git master? Just to be sure, you mean 4.x and therefore all the other experimental features? -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFE: New stable release
On Mon, Dec 15, 2014, Michael Cronenworth wrote: On 12/15/2014 10:25 AM, Adrien Nader wrote: Just to be sure, you mean 4.x and therefore all the other experimental features? Yes, I suspect you would call it 4.x as the 3.x branch would require substantial changes. I've mentionned it on IRC and I'd like to record this here too. As far as I know, a 4.0 version is not something that could be released that quickly, especially at this time of the year and with the large changes it has. I believe the landscape of Windows builds has changed, thanks to mingw-w64 among others. Nowadays more and more people want to use the newer features more and more quickly. I dislike the idea of users running on git snapshots but it seems many chose to do so because they need the new features that are only available there. I really dislike making such proposal for projects where I'm not directly very active on the code side but should the release process be changed? Maybe smaller and more frequent releases? It seemed to me that a release every 6-month or so (very roughly) would fit. I'm not arguing for strict time-based release but rather looking at the tree something like 6 months after the last release and if it brings new things then work towards a feature release. This would definitely make version numbers increase much faster than currently. By at most 2 versions a year, i.e. not that much after all. When I look at the main changes for 3.0 and the ones already in git, I'd say both changesets definitely deserve(d) a release. I don't think that even a quarter of the changes listed in each case are enough for a release: this wouldn't give mingw-w64 a reputation for doing releases only for the sake of doing releases and increasing the version numbers. This is only my personal opinion, based on what I've seen users do and request and how I've seen the code evolve. There are many people involved and their opinions are needed too. :) -- Adrien Nader http://win-builds.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.5-rc3 - simpler, more packages, GUI package manager, almost final release
Hi, The third release candidate for Win-builds 1.5 is now available. Win-builds is a fully-free and open-source, fully-bootstrapped and multi-platform project which provides compilers, libraries and tools for Windows along with cross-compilers from Linux (or any system with a GNU userspace). The 1.5 version greatly improves setup on both Windows and Linux. On Linux installation has been simplified down to cloning 4 git repositories and running make. On Windows, a graphical installer is provided and installation is completely usecase-agnostic: msys*, cygwin, IDEs, or bare cmd.exe. The compatibility for Linux versions has been maintained back to Ubuntu 12.04 and Debian squeeze (oldstable) although with a few known restrictions. On Windows, the compatibility goal is = Vista (it should still work on XP but it can't be officially supported anymore). Documentation has been updated for 1.5 and thanks to the improved ease-of-use, is noticeably shorter (writing less doc was the actual motivation behind these changes :) ). There are several new packages and many updates. The link to the full list is given in the links at the end of this message. In RC3, all the available security updates have been applied. Moreover, installation on Linux is now twice as fast since the build of Qt has been stripped down. This should be the last candidate before the 1.5.0 release and is now the version advertised on the website. The install steps for 1.4 (i.e. the previous release) are going to be changed since some choices were poor. The documentation will be updated accordingly. Special thanks to #RERB for all the time it gives when it comes to writing announces. Website: http://win-builds.org Screenshot of the GUI: http://win-builds.org/screenshot.png Package list: http://win-builds.org/1.5-rc3/packages/windows_64/package_list.html Build logs: http://win-builds.org/1.5-rc3/logs/ Installation on MSYS* and Cygwin: http://win-builds.org/1.5-rc3/msys-cygwin.html Installation on Linux: http://win-builds.org/1.5-rc3/linux.html Bug tracker, mailing-lists and IRC: See http://win-builds.org/support.html -- Adrien Nader http://win-builds.org -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.5-rc2 - simpler, more packages, GUI package manager
Hi, A new release candidate for Win-builds 1.5 is available. The focus for this 1.5 version has been simplicity and stability while also updating packages and adding new ones. Compared to RC1, this release is almost exclusively made up of bugfixes. The only notable exception is with the GTK+ 2 stack which has been updated because of the large number of bugfixes included in the newer versions. The installation on Windows has been improved and a portable installer is now available. A screenshot of the GUI can be seen at http://notk.org/~adrien/wb_temp/temp/screenshot.png . Several new testers have stepped up and the linux installation has been checked on distributions like Arch Linux and Exherbo in addition to several releases of Debian, Ubuntu and Slackware. Other notable changes since 1.5 RC1: - expanded documentation, notably on installation behind proxies and packaging; it is now very close to complete - work-in-progress comparison with other systems has been put at http://www.notk.org/~adrien/wb_temp/temp/comparison.html (will be moved to www.win-builds.org with the rest of the website update) - qmake.exe is now relocatable - update to mingw-w64 v3.3.0 - win-builds-switch outputs the environment variable it changes - fixed gdk-pixbuf not locating its files in 64 bits - fontconfig remaps the sans font to dejavu sans - fontconfig searches for fonts in ../share/fonts - yypkg sometimes failed to find some libraries dynamically loaded at runtime - there is no make.exe file/symlink installed anymore to avoid incompatibilities with msys*; users should call mingw32-make to get it - djvulibre had its executables with .exe on 64 bits systems - Qt failed to _re_build - add libcheck which I've needed for work and used extensively - use yypkg 1.9-rc7 which itself has many small interface, features and stability improvements What's left for the final release: - checking all the components are up-to-date when it comes to security fixes; this will lead to another RC, probably not more As usual, bugs and feature requests can be reported on the mailing-lists or on the bug tracker. Website: http://www.win-builds.org Package list: http://win-builds.org/1.5-rc2/packages/windows_64/package_list.html Installation on MSYS* and Cygwin: http://win-builds.org/1.5-rc1/msys-cygwin.html Installation on Linux: http://win-builds.org/1.5-rc1/linux.html Support informations: http://www.win-builds.org/support.html Package list: http://www.win-builds.org/packages.html Sources: http://cgit.notk.org/adrien/yypkg/ -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Wine Gecko build error
Hi, On Thu, Dec 04, 2014, Michael Cronenworth wrote: Hello, I am attempting to build wine-gecko 2.34 for Fedora, but I'm having an issue with winpthreads that doesn't make sense on first glance. gcc - 4.9.2 crt, headers, winpthreads - latest git checkout (2014-12-03) Build log: https://kojipkgs.fedoraproject.org//work/tasks/1017/8291017/build.log Search for pthread_t to find errors similar to: /usr/i686-w64-mingw32/sys-root/mingw/include/c++/i686-w64-mingw32/bits/gthr-default.h:47:9: error: 'pthread_t' does not name a type typedef pthread_t __gthread_t; I have the following in gthr-default.h: #define __GTHREADS 1 #define __GTHREADS_CXX0X 1 #include pthread.h Can you check you have it too? Also, typically, these issues are best debugged with the output of 'gcc -E'/'g++ -E' for the failing command (just copy the command, add -E, change the file that follows -o and store it somewhere [ it is probably too big for a mailing-list attachment ]). -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Build MinGW-w64 from Git on Linux
On Thu, Nov 27, 2014, lh_mouse wrote:
Install headers into your system directory please.
Specifically, if you are using mingwbuilds, you should set --prefix= to
/i686-w64-mingw32 or /x86_64-w64-mingw32.
The value for --prefix shouldn't be an issue here. This is a cross from
linux and nothing like msys is involved.
You've however reminded me of something by mentioning these quite
unusual values.
A bit more than a year ago there was a change in mingw-w64 and --prefix
must now be similar to the following:
--prefix=/${PREFIX}/${TARGET_TRIPLET} \
(taken from my build scripts at
http://cgit.notk.org/adrien/yypkg/mingw.git/tree/mingw-w64/mingw-w64.SlackBuild#n67
)
Meanwhile, everything else is configured with --prefix=/${PREFIX}
(including gcc, binutils but not winpthreads or other things from inside
the mingw-w64 tarballs).
Therefore you need to rebuild the headers set with a modified prefix,
rebuild gcc-core, build the crt with the modified prefix, (possibly
build winpthreads and kludge a bit [1], ) build the full gcc.
[1] See
http://cgit.notk.org/adrien/yypkg/mingw.git/tree/winpthreads/winpthreads.SlackBuild#n55
This kludge is quite official. Fedora for instance does it differently
and instead builds a first full gcc which cannot provide C++11 threading
support then winpthreads, then rebuilds a full gcc whih will then be
able to provide that threading support.
(I've forgotten some of the details: it's been quite some time and I
tend to offload my brain memory to my IRC logs which unfortunately have
a large access latency)
Regards,
Adrien Nader
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Build MinGW-w64 from Git on Linux
On Wed, Nov 26, 2014, Erik de Castro Lopo wrote: Erik de Castro Lopo wrote: I'm having a bit of trouble building MinGW-w64 from source. I asked on IRC and was told something along the lines of: export MYPREFIX=$HOME/MinGW/64 (cd mingw-w64-headers ./configure --prefix=$MYPREFIX make install) ./configure --prefix=$MYPREFIX make When I run that I get: configure: error: Please check if the mingw-w64 header set and the build/host option are set properly. configure: error: ./configure failed for mingw-w64-crt but the configure --help output doesn't really help me very much. Config.log output is here: http://www.mega-nerd.com/tmp/mingw-w64-config.log Erik Arf, that wasn't the file I had in mind but it's definitely not your fault: the organization of the sources can be a bit surprising at first. Basically there is a toplevel directory which is just a proxy to the others. If you look at its --help, you will see: --without-headers Skip building the mingw-w64 headers --without-crt Skip building the mingw-w64 crt --with-libraries=ARGBuild the extra mingw-w64 libs, where ARG is one of libmangle, pseh, or all --with-tools=ARGBuild the extra mingw-w64 tools, where ARG is one of gendef, genidl, or all There are a number of subdirectories, among which: mingw-w64-headers, mingw-w64-crt, mingw-w64-libraries and mingw-w64-tools. Inside the -libraries and -tools directories are again subdirectories: libmangle, pseh, winpthreads, winstorecompat(*) for the first one and gendef, genidl, genpeimg, widl (in 3.x). As I said, the toplevel configure is a proxy: when one of the aforementioned option is enabled, it will simply enter the corresponding directory and call the configure that is inside with roughly the same arguments as it was called (it strips the options listed above as they make no sense in subdirectories). This means that to debug the configure process of mingw-w64-crt, you need to look inside mingw-w64-crt and open the config.log file that is there instead of the toplevel one. I've seen several projects come in the form of several subdirectories of which several need to be built but having the toplevel configure is uncommon. It's something that GCC does however and I guess part of the inspiration came from there. :) (*) the fact that the toplevel configure doesn't mention winpthreads and winstorecompat might well be a bug. -- Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Wt-interest] Building Wt with mingw-w64 -- prefer Mingw-builds or Win-builds?
Hi, On Sat, Nov 22, 2014, K. Frank wrote: Hello Lists! Should I use Mingw-builds or Win-builds to build Wt? First of all, both should work. I am the lead dev of win-builds so obviously I'm not an expert in mingw-builds. NB: everything below applies to the new 1.5 release which is imminent (there should only be some documentation left to do). By design it focuses on stability and maintainability. It also has very few patches which are all absolutely necessary. For the 1.4 release, there have been security updates too even though that didn't play out too well due to a few poor choices which are now solved. In other words, it will be possible to install 1.5 and have security-only updates for a while. The best way to understand the other differences is probably to look at how the toolchains are built: - mingw-builds builds on Windows inside MSYS2 - win-builds cross-compiles from Linux (including a native toolchain and the corresponding tools [even the awfully-difficult-to-build-qmake.exe]) The reasons win-builds is done that way are numerous. The explanation below is a bit long but the question is getting more common and it's a good occasion to provide a full picture. Linux is fully posix; not almost-posix like cygwin or a mixture of almost-posix and win32 like msys*; this avoid the translation and interpretation layers of cygwin and msys and makes the whole system therefore cleaner. It gives more trust in the binaries: the whole chain is free software and without antivirus software (or virus) that sometimes (read often) change the contents of files (especially for compilers and interpreters). Everyone can rebuild and check no malicious content has been injected. There is no software cost in doing so and it's _fast_ (a couple hours for a full rebuild on an inexpensive machine from 2009 for the 1.5 version; half of the time is caused by Qt). From-scratch rebuilds are routinely done to make sure that everything stays reproductible and that if something builds, it's not only sheer luck and astral alignement. The ability to easily rebuild also makes it easy to customize the build, add or remove dependencies and change versions. Rebuilding the whole package archive from scratch is fully working on Slackware -current and Debian Jessie with no change. On Debian stable (the one before Jessie), Ubuntu 12.04, Ubuntu 14.04, there are a few small caveats which are all in the documentation and all of which are caused by the host systems (outdated versions of autotools being the main issue). Tests under Arch Linux and MSYS are currently in-progress and looking good so far. This compatibility is a goal of the win-builds project, not just something that happens to work. The whole project can be used from Linux or from Windows just the same: the tool and library packages are the same across operating systems and the package manager has been built to handle both from the ground-up. This is especially important for people who mainly work on Linux and happen to build for Windows or for mixed teams (some on Windows, some on Linux). All of the above also has had the consequence that WB is quite agnostic to where and how it can be used: it assumes very little about the usecase and therefore works everywhere. I am going to attempt to build Wt natively on 64-bit windows using mingw-w64. I am encouraged by Wim's comment in an earlier thread that it ought to be possible: http://permalink.gmane.org/gmane.comp.web.witty.general/9973 Before doing so I intend to upgrade to a recent mingw-w64. Will I be more likely to be successful using the Mingw-builds or the Win-builds version of the toolchain? All else being equal, I would probably go with Mingw-builds because it appears to offer gcc 4.9.0. As I said at the beginning of this message, both should work. About the GCC version though: 4.9.0 was quite heavily bugged and while 4.9.1 was much better it still had its issues. I don't know about GCC 4.9.2; I haven't read many complaints about it but it came after the WB version freeze so it hasn't been studied for inclusion. In any case, you should probably avoid 4.9.0 and 4.9.1. Win-builds does offer a number of pre-built packages, but according to the Wt wiki: http://redmine.webtoolkit.eu/projects/wt/wiki/Installing_Wt_on_MinGW Wt's only dependency is boost, so the Win-builds packages don't look relevant to my Wt project. Boost isn't currently packaged since there had been no demand so far. The relevant entry in the bug tracker was opened a couple weeks ago and is at http://win-builds.org/bugs/index.php?do=detailstask_id=86 . It is scheduled for 1.6 and should therefore be packaged in roughly 4 to 6 weeks (or earlier if someone else does it of course :) ). Regards, Adrien Nader -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports
Re: [Mingw-w64-public] windows 32 bit memory address space
No, it's impossible. 2 ** 32 = 4GB so the whole system is limited to 4GB in total and there's 1GB (or 2GB) which is not usable by applications. The only solution is to move to 64bit applications. Actually the limitation on memory allocations is the main reason for the creation of 64bit systems. Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.5-rc1 - simpler, more packages, GUI package manager
Hi, I am happy to announce the first release candidate leading to the next release of win-builds: 1.5. Win-builds is a fully-free/open-source, fully-bootstrapped and multi-platform project which provides compilers, libraries and tools for Windows along with cross-compilers from Linux (or any system with a GNU userspace). This version greatly improves setup on both Windows and Linux. On Linux installation has been simplified down to cloning 4 git repositories and running make. On Windows, a graphical installer is provided and installation is completely usecase-agnostic: msys*, cygwin, IDEs, or bare cmd.exe. The meta-build-system has been expanded for it to be as simple as make WINDOWS_64=package_name. The compatibility for Linux versions has been maintained back to Ubuntu 12.04 and Debian squeeze (oldstable) although with a few restrictions. On Windows, the compatibility goal is = Vista (it should still work on XP but it can't be officially supported anymore). Documentation has been updated for 1.5 and thanks to the improved ease-of-use, is noticeably shorter (writing less doc was the actual motivation behind these changes :) ). There are several new packages and many updates plus a few GTK+-related ones before the actual release. Screenshot of the GUI: http://win-builds.org/screenshot.png Package list: http://win-builds.org/1.5-rc1/packages/windows_64/package_list.html Build logs: http://win-builds.org/1.5-rc1/logs/ Installation on MSYS* and Cygwin: http://win-builds.org/1.5-rc1/msys-cygwin.html Installation on Linux: http://win-builds.org/1.5-rc1/linux.html Bug tracker, mailing-lists and IRC: See http://win-builds.org/support.html Rough roadmap to the final release and known issues in RC1: - GTK+ doesn't fully respect --libdir and therefore has a slight issue with gdk-pixbuf on 64b - default linker path might be incomplete and specifying -L/installation/path/lib (or lib64) might be needed on Windows - make.exe is not renamed to mingw32-make.exe and might therefore take precedence over MSYS' - documentation for setup with IDEs needs to be done - documentation for packaging hasn't been updated for 1.5 - libarchive's ABI is not the one intended by the upstream developers for large-file handling - installation on Windows shouldn't even require explicit unzipping of the installer. Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Win-builds 1.5-rc1 - simpler, more packages, GUI package manager
On Thu, Oct 23, 2014, niXman wrote: Adrien Nader 2014-10-23 00:33: Screenshot of the GUI: http://win-builds.org/screenshot.png Hi, Tell me please, what technologies/libraries/programming_language are used to create this GIU installer? Graphical toolkit is EFLs from http://enlightenment.org (Enlightenment Foundation Libraries) and is written in C. The application itself is written in OCaml and uses the ocaml-efl bindings ( https://forge.ocamlcore.org/projects/ocaml-efl/ ; https://github.com/axiles/ocaml-efl ). Why: - Qt isn't friendly for cross-compilation to Windows (it's expressly stated to be user supported, i.e. it breaks all the time) and is more difficult to use from statically-compiled languages that aren't C++ (the core of the application was already written). - The choice of EFLs happened before the recent GTK+ updates and improvements so there was little question there. - EFLs' windows port is not perfect but actively maintained and quickly fixed when issues are found (mostly because all developers are supposed to keep it working, not only a couple ones). Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] localtime_r guard to _POSIX or _POSIX_THREAD_SAFE_FUNCTIONS
Hi Ray,
On Tue, Oct 21, 2014, Ray Donnelly wrote:
On Tue, Oct 21, 2014 at 10:57 AM, JonY jo...@users.sourceforge.net wrote:
On 10/21/2014 17:50, JonY wrote:
On 10/21/2014 03:58, Ray Donnelly wrote:
Comments welcome.
Hi,
Do you mind writing better comments for the patch? A single line
followed by a blank line and then a longer description.
Ignore the C11 part and mingw-w64-crt, a better description for git
should be fine.
Thanks Jon,
For my patch, Comments welcome. wasn't the commit message :-)
From the patch itself:
commit message
localtime_r guard to _POSIX or _POSIX_THREAD_SAFE_FUNCTIONS
From http://www.unix.org/whitepapers/reentrant.html
This is accomplished in the standard by associating the reentrancy
specifications with a separate option, {_POSIX_THREAD_SAFE_FUNCTIONS},
which is declared to be mandatory for implementations supporting the
threads option
In pthread_unistd.h we define:
_POSIX_THREAD_SAFE_FUNCTIONS 200112L
/commit message
.. for the previous patch by Martell, perhaps I should add the
following comment:
Remove localtime_r from pthread.h which was a legacy hack for
compatibility with pthreads-win32. time.h is a more correct place for
localtime*, both for _POSIX compliance (
http://pubs.opengroup.org/onlinepubs/009695399/functions/localtime.html
) and MS for compatibility (
http://msdn.microsoft.com/en-us/library/bf12f0hc(v=vs.80).aspx )
Let me know and I'll get on it.
I also mentionned the need of a better commit message on IRC. My concern
is that since it will probably break some programs, having a
particularly good commit message was important because it is likely many
people will read it.
The comment you just mentioned is good. I think I'd also like to see a
mention of how to be able to either avoid getting localtime_r or making
sure it is available.
Thanks,
Adrien Nader
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
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] update download page with archlinux mingw stack
Hi, On Tue, Oct 21, 2014, xantares 09 wrote: Hello list, I'd to contribute to the download page (http://mingw-w64.sourceforge.net/download.php) to be updated to provide information on the available mingw stack that you can download and which would be located in a new sub-tab Archlinux Project - cross compiler for Linux: Here are the relevant fields: - arch=i686, x86_64 - gcc=4.9.1 - crt=3.2.0 - languages = Ada, C, C++, Fortran,Objective-C, Objective-C++ - cxx11: Supported - package manager: pacman/yaourt - installation: From AUR repository (https://aur.archlinux.org/) - additional software: admesh [snip] Thanks for the work and for the infos. I'm a bit too busy to update right but it should be done at some point next week. :) -- Adrien Nader -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6
On Mon, Oct 20, 2014, Óscar Fuentes wrote: Ruben Van Boxem vanboxem.ru...@gmail.com writes: As stated, the problem is not related to MinGW-w64, it is about how you configure the CMake/Clang combo for cross-compiling. I beg to differ, and it is quite related to using MinGW-w64. It's just not about GCC. Currently, Clang as-is cannot cross-compile to the MinGW-w64 targets. Clang is not under the control of MinGW-w64. Nor this project distributes Clang binaries with any promise of support. So if Clang has a problem targeting MinGW-w64, that's something to discuss on the Clang lists. As a project, mingw-w64 wishes to have clang and llvm supported. There have been recent reports of troubles with it however but we'd prefer it to work. OTOH if CMake invokes Clang without the desired options and switches, it is a problem with how CMake is used. On the other side, the llvm project needs to do a bit of work too or at least to state they want to support mingw-w64 and are ready to at least try to not break its support. Don't get me wrong, I'm not upset for this question being posted here. It's just that by asking it on clang-users or cmake-users the OP would get more chances of getting help. I think the discussion is relevant but at least some troubles seem to come from clang so the issue is worth raising there too imho. -- Adrien Nader -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6
On Mon, Oct 20, 2014, Óscar Fuentes wrote: Adrien Nader adr...@notk.org writes: As a project, mingw-w64 wishes to have clang and llvm supported. There have been recent reports of troubles with it however but we'd prefer it to work. Nice. Preferences are a good starting point for achieving things ;-) On the other side, the llvm project needs to do a bit of work too or at least to state they want to support mingw-w64 and are ready to at least try to not break its support. You think about the LLVM project as if it had preferences and stated goals. Reality is that the community drives what the project does. If there is no one pushing hard for MinGW-w64 support and contributing hard work to it, things will stay the same (or change for the worse). So far the drive behind MinGW-w64 (or MinGW* at all) is weak. Ruben and a few others contribute patches, but without a champion within the core developers community, they are fighting an uphill battle. There is a group of prominent contributors that would be somewhat pleased if MinGW* support were officially suppressed. Those developers think that only VS is relevant on Windows and Clang is not to be taken seriously on that platform until VS compatibility is achieved. Definitely. And just for others reading, a few very-publicized links along with quotes from the top of each page. http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html Over the past several months, contributors from Google and elsewhere in the community have begun actively working on bringing an LLVM toolchain to Windows in a way that would support and enhance a fully native development experience. This toolchain works with Visual Studio and the Windows development process that Windows developers are already using, making LLVM tools and technologies available to them. http://blog.llvm.org/2014/07/clangllvm-on-windows-update.html It's time for an update on Clang's support for building native Windows programs, compatible with Visual C++! http://llvm.org/docs/GettingStartedVS.html Welcome to LLVM on Windows! This document only covers LLVM on Windows using Visual Studio, not mingw or cygwin. (that one is the top answer for a query for llvm windows) The current development with the most manpower, including large corporate backings, is definitely for a direct integration with Visual Studio, with executables that replace the ones from VS and mimic them (like a cl.exe for compilation). And... reusing proprietary bits from Visual Studio. It's open-source and everything and you can put the effort you wish in it and do a ton of work. But meanwhile there are several people paid to work on it with the sole purpose of integrating with Visual Studio, reusing everything that cannot be replaced directly by something from LLVM, no matter if it's proprietary or not. Good luck is the best thing I can give currently. This is a corporate-driven project and no matter what you do, you risk seeing your work removed because it doesn't please someone from a company. It could happen with any project, corporate-driven or not, but it's more likely when a company is behind it and given the current state, I'm not optimistic. (hello Intel by the way) There could be a fork but no-one would follow, just like only Google has been able to fork WebKit. All the other players in the webkit/blink space are completely dwarfed by Google or Apple and it's impossible to do anything not wanted by these. Don't get me wrong, I'm not upset for this question being posted here. It's just that by asking it on clang-users or cmake-users the OP would get more chances of getting help. I think the discussion is relevant but at least some troubles seem to come from clang so the issue is worth raising there too imho. Furthermore, it is a good thing to send the message that some people cares about MinGW* support on LLVM/Clang. Just to be sure: I care about that support but I don't believe upstream wants it. My point is only that if there is no strong technical reason to support it, it should be done. Except that if LLVM upstream actively wants to not be supported, it's going to be difficult to do so. I'm afraid we might well be in this situation. NB: If you are from the LLVM project (I mean this for anyone reading this message, not for someone in particular), please get an _official_ statement that mingw-w64 is something the project wants support for. Only a statement, it's not much work and it'll help going forward a lot. -- Adrien Nader -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https
Re: [Mingw-w64-public] Errors while compiling openssl
It looks like you're missing the make tool on the host. It's not a tool specific to cross-compilation. You'll want to at least install the build-essentials package from Debian. As for openssl in particular, the list of things to change is long... http://cgit.notk.org/adrien/yypkg/slackware64-current.git/tree/n/openssl/openssl.SlackBuild#n46 -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 packager contributions
Hi,
On a related note, there has been an increasing number of people asking
which topics could be worked on. So far there has been no list of easy
tasks since most things were in flux and there were large and complex
issues to deal with first.
Now that things are getting more stable, I believe such a list could be
made. For instance, it should be possible to implement SEH for 32bits
without having to change too many components.
The idea here is to make newcomers to the project pick a subject they'd
like to see improved and contribute to it in a way or another. This list
should also make it possible to take part in GSoC and similar events.
It will be displayed on the top-right corner of the website (the
elements that had been there have been moved and merged in order to make
room for such highlights).
Feel free to send your ideas. A few on top of my head:
- SEH for 32bits
- Thorough analysis of the status of {a,t,u}san and fixing what could be
broken (two separate tasks)
- Same for LTO
--
Adrien Nader
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 packager contributions
On Fri, Aug 22, 2014, Adrien Nader wrote:
Feel free to send your ideas. A few on top of my head:
- SEH for 32bits
- Thorough analysis of the status of {a,t,u}san and fixing what could be
broken (two separate tasks)
- Same for LTO
Also:
- compiler plugin for visual studio
- ability to output PDB (there are several existing projects to look at
first, including Roslyn, mono and a few others I can find again in my
IRC logs)
--
Adrien Nader
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 packager contributions
On Fri, Aug 22, 2014, JonY wrote:
On 8/22/2014 20:57, Adrien Nader wrote:
On Fri, Aug 22, 2014, Adrien Nader wrote:
Feel free to send your ideas. A few on top of my head:
- SEH for 32bits
- Thorough analysis of the status of {a,t,u}san and fixing what could be
broken (two separate tasks)
- Same for LTO
Also:
- compiler plugin for visual studio
- ability to output PDB (there are several existing projects to look at
first, including Roslyn, mono and a few others I can find again in my
IRC logs)
C11 threading and atomics :)
Implementations of these using the Win32 API directly (i.e. without
winpthreads).
(_I_ do not mind but some do so I'm adding it to the list)
--
Adrien Nader
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Successfully using Mingw-w64 too!
I'm adding it now. Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 0/5] strongSwan ported to Windows - Header patches
Hi, On Wed, Jun 25, 2014, Martin Willi wrote: Hi, We successfully ported the strongSwan IPsec solution to the Windows platform using the MinGW-W64 toolchain. Many thanks to the MinGW-W64 developers for bringing GCC to Windows and making this port possible. For those interested, some early additional information is available at [1]. There are no source or binary releases at this point, though. [1]http://wiki.strongswan.org/projects/strongswan/wiki/Windows I'm going to add a link to strongswan on the website and I'd prefer to link to http://strongswan.org directly but it doesn't mention the Windows port. Is it currently stable enough and if so, could you mention it in runs on Linux 2.6 and 3.x kernels, Android, Maemo, FreeBSD, and Mac OS X? Regards, Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Ceemple uses mingw-w64
Hi, I'm adding it now. Sorry about the delay: I had fallen behind and never really caught up. -- Adrien Nader -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [WBSA] CVE-2014-0195/0198/0221/0224/3470/5298 openssl update (Win-builds security advisory)
Again, high-profile security vulnerability in an SSL/TLS library. Package: openssl CVE ID : CVE-2014-0195 CVE-2014-0198 CVE-2014-0221 CVE-2014-0224 CVE-2014-3470 (CVE-2014-5298 under specific circumstances) Multiple vulnerabilities have been discovered in OpenSSL: CVE-2014-0195 Jueri Aedla discovered that a buffer overflow in processing DTLS fragments could lead to the execution of arbitrary code or denial of service. CVE-2014-0198 It was discovered that incorrect memory handling in OpenSSL's do_ssl3_write() function could result in denial of service. CVE-2014-0221 Imre Rad discovered the processing of DTLS hello packets is susceptible to denial of service. CVE-2014-0224 KIKUCHI Masashi discovered that carefully crafted handshakes can force the use of weak keys, resulting in potential man-in-the-middle attacks. CVE-2014-3470 Felix Groebert and Ivan Fratric discovered that the implementation of anonymous ECDH ciphersuites is suspectible to denial of service. CVE-2010-5298 A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. [ win-builds packages are not vulnerable; this CVE is mentionned for completeness' sake ] Additional information can be found at http://www.openssl.org/news/secadv_20140605.txt For win-builds 1.4, this problem has been fixed in version 1.0.1h-1. You should update your openssl package. If you are unsure how to update packages, visit the Package updates section of the documentation at http://win-builds.org/documentation.html#package_updates Mailing list: security-requ...@lists.win-builds.org -- Adrien Nader Free Software for windows with package manager: http://win-builds.org -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [WBSA] CVE-2014-3466 gnutls update (Win-builds security advisory)
Hi, I normally wouldn't post that here but considering how quickly after release it happened, here is a copy of the recent win-builds security advisory. Package: gnutls CVE ID : CVE-2014-3466 Joonas Kuorilehto discovered that GNU TLS performed insufficient validation of session IDs during TLS/SSL handshakes. A malicious server could use this to execute arbitrary code or perform denial or service. For win-builds 1.4, this problem has been fixed in version 3.1.25-1. You should update your gnutls package. If you are unsure how to update packages, visit the Package updates section of the documentation at http://win-builds.org/documentation.html#package_updates Mailing list: secur...@lists.win-builds.org Subscription: http://win-builds.org/support.html -- Adrien Nader Free Software for windows with package manager: http://win-builds.org -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.4.0 - package management on/for Windows
Hi, The 1.4.0 release of win-builds is now officially available at http://win-builds.org . The win-builds.org project is a package manager along with free software packages. Everything can be ran on Windows (with or without MSYS*/Cygwin), Linux and other systems. It focuses on stability and versatility. The main changes in this version are bug fixes and usability improvements. Packages have been updated too, in particular wrt security issues. GDB, libao, libid3tag, madplay, libmad, libsndfile, libtasn1, pcre, harfbuzz, fribidi, have been added. Most EFL packages (eet, embryo, edje, ecore, evas, eina) have been merged together by upstream into a single efl package. This brings the package count to over 60. Installation has been greatly simplified; package updates even more so: double-clicking on yypkg.exe is enough to update packages. All pango, cairo, gdk, fontconfig caches are properly created at the end of installation; moreover, fontconfig's fc-cache stopped leaking memory. While there was an attempt to handle security updates in the previous versions, some things didn't work out so well. This version fixes them and security updates will be provided. Tooling on Linux has been made simpler and more efficient. Build procedure has been changed slightly: it now builds the cross-toolchain on each machine and reuses the windows packages, giving great flexibility while saving most of the build time. It has been tested on Exherbo, Slackware Linux, Debian Jessie and is compatible back to wheezie and Ubuntu 12.04. Documentation has been updated and improved. There are also countless improvements which add up and make for a much improved and matured release. Note however that it isn't possible to update a 1.3 installation to 1.4 without manual intervention because of the tooling changes. If really needed, get in touch on the bug tracker. Website: http://win-builds.org Downloads: http://win-builds.org/download.html Documentation: http://win-builds.org/documentation.html Bug Tracker: http://win-builds.org/bugs/ Mailing-lists: http://win-builds.org/support.html Git repositories: http://cgit.notk.org/adrien/yypkg/ Happy installation, Adrien Nader -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [ANN] Win-builds 1.4-beta2 - package management on/for Windows
On Sun, May 25, 2014, Vincent R. wrote: I wanted to test the package manager but it's not possible to download it : The requested URL /web-test/1.4-beta3/yypkg-1.4-beta3.exe was not found on this server. It's expected since this was a temporary location to not disrupt the website during the beta phase. Have a look at http://win-builds.org directly. ;-) -- Adrien Nader -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.4-beta2 - package management on/for Windows
Hi, I'm happy to announce the availability of 1.4 beta2 at http://win-builds.org/web-test/ This version is very close to beta1 and its 60 packages plus the following fixes: - at the end of installation on Windows, libwinpthread.dll must be manually copied from triplet/bin/libwinpthread-1.dll to bin/ (will be fixed in next update by setting --bindir) Solved through 'mv'; libtool has no way to honor a 'bindir' in its install mode. - some symlinks for ICU libs are broken Fixed through small patches to the build system. - libarchive is built with _FILE_OFFSET_BITS set to 32 Actually wrong: _FILE_OFFSET_BITS is set to 64 but this is not enough to get 64 bits sizes in struct stat. Not patched since issue is a serious and ABI-breaking change which only upstream can decide how to fix properly. Will be reported there soon. - yypkg.exe adapts its UI whether it is started from command-line or not but the detection is not reliable (code to fix is already written) Fixed through better detection of the parent process. Main changes left for the release: - check harfbuzz' dependencies (probably won't change) - yypkg will also attempt to automatically discover where it is installed when run from the command-line (currently the path has to be specified) - yypkg will be able to install from file:// mirrors in addition to http:// ones - installation on cygwin puts spurious end of line markers in paths in configuration files The following notes still apply: Note: - this version is not compatible with an installation of 1.3; if you wish to install it at the same location as 1.3, simply rename the 1.3 installation directory to something else (e.g. append .bak to its name) - the list of dependencies to install on linux is still partial; input is needed to improve distribution coverage Regards, Adrien Nader -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Poll] Move to git
On Sat, May 10, 2014, Adrien Nader wrote: Hi, As a vengeance to this error I got a few seconds ago: web/htdocs/users.php : svn:mime-type is not set [X] Yes, move to git [ ] No, continue with SVN And forgot to state the SF ID: adrien-n. -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [ANN] Win-builds 1.4-beta1 - package management on/for Windows
Hi, I am pleased to announce the availability of the 1.4-beta1 release of win-builds.org, available at http://win-builds.org/web-test . The win-builds.org project is a package manager along with accompanying free software packages. Everything can be ran on Windows (with or without MSYS*/Cygwin), Linux and other systems. It focuses on stability and versatility. This version has focused on improving all the issues found during the stabilization phase of the 1.3 version but couldn't be fixed without changes too large for a stabilization phase. Despite being at beta1, this version should be safe to try. In particular, it doesn't set any environment variable and will not overwrite anything. Main changes: - much simpler installation and package update on Windows - all package manager tools have been merged in a statically-linked executable which is its own self-deploying installer - numerous small bug fixes - package updates - removal of the chroot for Linux usage; build has ben fully tested on Debian Jessie and Slackware Linux - updated documentation Known issues (all of which are to be fixed in the coming days): - at the end of installation on Windows, libwinpthread.dll must be manually copied from triplet/bin/libwinpthread-1.dll to bin/ (will be fixed in next update by setting --bindir) - some symlinks for ICU libs are broken - libarchive is built with _FILE_OFFSET_BITS set to 32 - yypkg.exe adapts its UI whether it is started from command-line or not but the detection is not reliable (code to fix is already written) Note: - this version is not compatible with an installation of 1.3; if you wish to install it at the same location as 1.3, simply rename the 1.3 installation directory to something else (e.g. append .bak to its name) - the list of dependencies to install on linux is still partial; input is needed to improve distribution coverage Every comment is welcome. Happy testing. Regards, Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Poll] Move to git
Hi, As a vengeance to this error I got a few seconds ago: web/htdocs/users.php : svn:mime-type is not set [X] Yes, move to git [ ] No, continue with SVN -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On Tue, May 06, 2014, niXman wrote: niXman 2014-05-06 19:18: I hope that someone from the project administrators, will place the link to installer on the green button on the main page of the project. ping? I've updated the link on the website download page and someone (I don't know who) changed the featured download link on sourceforge's file release system to point to it (it was pointing to the sources before). -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to remove libgcc_s_sjlj-1.dll dependency
Hi, On Mon, May 05, 2014, YIRAN LI wrote: Hi, I'm building an opensource project on mingw32 and found the generated dll depends on libgcc_s_sjlj-1.dll. The function referenced is __divdi3. I tried to add ldflags = -static- libgcc, but seems it doesn't work. Could any one let me know how can I get rid of this dependency? Not something I usually do and top of my head, so this might not be enough. The flags you use should rather be -static -static-libgcc (both of them and notice the different spelling). HTH, Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
On Mon, May 05, 2014, JonY wrote: This is a simple change in vim's configuration file (in the case SF doesn't changing that in some Web UI). I don't think I can check on jon_y's repo (seems I don't have the rights to access it through ssh). Right now, I made it readonly except to administrators, I'll try to allow you access to it. Thanks, works. From /home/git/p/mingw-w64/mingw-w64.git/config: [receive] denyNonFastforwards = true I don't know if you're the one who put it there or if it's by default but in any case, this is what forbids rewriting history. -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to remove libgcc_s_sjlj-1.dll dependency
On Mon, May 05, 2014, YIRAN LI wrote: 2014-05-05 17:32 GMT+10:00 lh_mouse lh_mo...@126.com: 0) Try -static first. I have been using this option since long ago and it never fails; 1) Try -static-libgcc -static-libstdc++. These two should be used together. Using only one of them does not work, at least on my machine. 2) There is no space in '-static-libgcc'. Thanks, I used -static, but seems it causes the project to generate static libs instead of dlls. I think it should be the problem of the project (libtheora) and I've sent out a mail to libtheora's mail list. You use -static and possible -static-something when building the final executable and only it. If you are not able to easily single out the build of the final executable (because it is a tool built as part of a larger project), a very efficient way is to build as usual, find the corresponding compilation command, copy-paste it and add -static yourself. It's not terribly clean but it's the easiest way to do it. -- Adrien Nader -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 may move to git in the future
completely coincidentally, another project I'm on is switching from a very old system to git, and doing it very poorly. Then, of course, after reading, I saw that the primary reason has to do with a concern I raised 3 years ago.. But anyway, take it all for what it's worth -- just another email in the inbox. Have fun, happy hacking. Please come back, we miss you :) =) -- Adrien Nader -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
