Activity for Keith Marshall
-
Keith Marshall modified ticket #1648
mingw-get source nonesuch -- fails silently
-
The command: $ mingw-get licence nonesuch exhibits a similar silent failure. Since both source and licence actions are processed within the same internal code path, the attached source-nonesuch.patch corrects both manifestations of this defect.
-
Is this still needed? I don't think so. Closing as "out-of-date".
-
Sync mingw32-runtime.xml from the published version
-
mingw-get: select a mirror for downloading
-
Closing as "rejected". Web technologies have moved on, and I don't believe that there is any viable way to implement this, or any benefit to be gained.
-
MingWrt v5+ introduces SSE instruction that prevents execution on non-SSE OS
-
Closing, since the original issue should have been resolved, and no consequent x86-64 issue has been raised.
-
FWIW, I encountered the same issue when attempting to build freeglut-3.2.1 on Arch Linux, with GCC-11.1, and came up with much the same work-around as the OP. I agree that your SVN-1863 update is a much better solution; however, while investigating, I did notice that the src/fg_gl2.h file header incorrectly identifies the file as fg_gl2.c, and that's still wrong in SVN. Not a big deal, I realize, but you may want to correct it some time.
-
winnt.h: #define for FILE_DELETE_ON_CLOSE is wrong.
-
I know this 6+ years old, but I've just stumbled on it again; clearly, no action was ever taken, and since Earnie is no longer playing an active rôle, I decided to follow up myself. Unfortunately, the original report appears to misrepresent fact — the cited MSDN reference does not stipulate a value of 0x4000000 for FILE_DELETE_ON_CLOSE; this is the documented value for FILE_FLAG_DELETE_ON_CLOSE ... a different entity, which does appear to be correctly defined, (albeit irrationally as an equivalent...
-
mingw-get requires element feature
-
I don't understand the motivation for this request. Firstly, IMO, a requirements specification needs to be explicit, at least to the component level, (which your example isn't). Secondly, AFAICT, the existing mechanism fully supports the capability you appear to be seeking: <requires eq="mingw32-libgcc-*-mingw32-dll-1.tar" /> will match the currently installed version of the DLL component, with ABI version 1, (and, to me, ambiguity in an ABI version number makes no sense whatsoever); if there is...
-
FWIW, after a protracted disappearance — yielding HTTP error 404 — of MSDN documentation for the NMPGSCROLL structured data type, it has now reappeared on docs.microsoft.com, with the fwKeys field now documented to be of type WORD. There now seems to be no doubt that this was the correct resolution.
-
bsdtar does not restore file modification times
-
Charles Wilson surely isn't going to follow this up now, since he is no longer an active project contributor; Cesar, would you care to comment?
-
gettextize refers to missing files in
-
Charles Wilson surely isn't going to follow this up now, since he is no longer an active project contributor; Cesar, would you care to comment?
-
Perl *** couldn't commit memory for cygwin heap, Win32 error
-
I'm sorely tempted to just close this, as "invalid". The "cannot commit memory for cygwin heap" is often a symptom of misuse: attempting to start MSYS utilities directly from cmd.exe, which is unsupported, instead of from a properly initiated MSYS shell session, as they should be used; the OP's use of backslashes in example path names strongly hints that he (or she) is engaged in precisely such improper usage. Other than that, I completely agree with you, Earnie, that there absolutely should not...
-
[compile error]gettext still using nl_langinfo
-
Hmm. I must have overlooked this previously. I am aware of a conflict between the requirements of GNU gettext, and the minimal langinfo.h stub shipped with mingw-catgets-1.0-dev.tar.gz. Ideally, GNU gettext needs a more robust test, for the suitability of any pre-installed langinfo.h, but that would need an upstream resolution. Alternatively, our mingw-catgets needs to stop installing a publicly visible langinfo.h, but right now, that's a low priority issue for me, (in what is, after all, a contributed...
-
Problem with bzip2 package
-
I assume my 2013-02-04 resolution was acceptable; Charles Wilson is unlikely to offer any alternative now.
-
gnu tar can't archive big files
-
Perhaps Cesar would care to comment? Charles Wilson is unlikely to do so, since he is no longer an active MinGW.org Project participant.
-
mgwport is dead; use mingw-pkg (available here) instead.
-
"mgwport all" does not do download step
-
mgwport is dead.
-
Glade3-3.6.7 crashes with new zlib 1.2.7
-
Is this perhaps a user environment issue? I don't know, but I'm fairly certain Charles Wilson will not be pursuing it, (since he is no longer an active project participant); perhaps Cesar would care to comment? FWIW, running MSYS under wine seems like a fairly futile exercise, to me, but if the issue is reproducible in MSYS on Windows, (and the OP seems to indicate that it is), then some follow up action would appear to be appropriate.
-
Bision m4 -g (--gnu) option not recognized.
-
Is this still an issue? It's fairly certain that Charles Wilson is unlikely to follow it up, since he is no longer a MinGW.org Project participant. My own inclination is to close, but perhaps Cesar would care to comment?
-
Perl 5.6 is 6 year old
-
Since Charles Wilson is no longer an active MinGW.org Project participant, we are unlikely to see any follow-up action from him; perhaps Cesar would care to comment? IIRC, perl is an absolute pig to build ...
-
autoconf-2.69 does not biuld
-
Is this still an issue? I haven't used MSYS, for any significant development work, in over five years now, but I do use autoconf-2.69 on my LinuxMint box; I don't recall what version I last used on MSYS. Since Charles Wilson is no longer an active MinGW.org Project participant, we may be fairly certain that he will not follow this up; perhaps Cesar would care to comment?
-
Add HPN patches to OpenSSH
-
Since Charles Wilson is no longer an active MinGW.org Project participant, perhaps Cesar could comment on this?
-
mgwmake should use multiple make jobs
-
I'm rejecting this, for the following reasons:– The original contributor, Charles Wilson, is no longer an active MinGW.org participant. mgwport never worked for me anyway, on my LinuxMint host. I prefer to promote mingw-pkg, (currently available here), as the modern replacement. You, yourself, have acknowledeged that there may be obstacles to adoption of this particular feature.
-
commctrl.h: NMPGSCROLL.fwKeys uses wrong type
-
Thanks for the test case. I will not look at Microsoft headers; nor will I look at equivalent mingw-w64 or wine headers, because both projects are notorious for their blatant disregard for Microsoft's EULA. However, on the basis of the evidence of your test case, I will take your word for it: thus, I've committed https://osdn.net/projects/mingw/scm/git/mingw-org-wsl/commits/2dcc5878a9edc9a84837638af134f4398a2730d9 BTW, there is a bug in your test case, which causes it to fail with a "Failed to create...
-
To avoid this, I'd recommend you use PGP/MIME instead of inline-PGP, which won't change the message in any way. At one time, the list in question lived on SourceForge, and use of PGP/MIME was causing some other problem, (which I can't recall now), so I deselected it. If memory serves, the issue with SourceForge was that their mailman servers were rewriting PGP/MIME signed messages, and adding content in a manner which invalidated the signature. The list has now been moved to OSDN.net, so it may be...
-
Thanks, Patrick The problem is that inline-PGP is not suitable for such messages. If you don't rewrap the message before the signature is made, then Thunderbird will rewrap the message, and the signature is destroyed. To avoid this, I'd recommend you use PGP/MIME instead of inline-PGP, which won't change the message in any way. At one time, the list in question lived on SourceForge, and use of PGP/MIME was causing some other problem, (which I can't recall now), so I deselected it. The list has now...
-
I'm on LinuxMint Debian Edition 1, and upgrading to LMDE2 isn't a convenient option right now. Thunderbird is v38.4.0, (and says it is up to date); Enigmail is v1.9.7, using /usr/bin/gpg2 When posting signed-only plain text to a mailing list, (which frowns on HTML postings), Enigmail utterly destroys the layout of pre-formatted text, when it appears in quoted context. For example, Thunderbird's composition window shows:– On 17/04/18 11:38, Keith Marshall wrote: > A possibly more robust implementation...
-
std::experimental::filesystem::rename does not overwrite existing file
-
GCC's own (upstream) documentation indicates that C++ filesystem support is a) experimental, and b) "rudimentary" (translation: "unlikely to work") on non-POSIX platforms (specifically Windows). Our GCC-6.3.0 distribution doesn't even attempt to support it, so I see no point in pursuing this any further.
-
Thank you for this report. First, may I point out that this project (MinGW.org) does not distribute any version of g++ later than g++-6.3.0, so you clearly aren't using a product which have provided, and thus, we should hardly be expected to support it. That said, our own g++-6.3.0 distribution may well be similarly affected, so we may still benefit from follow-up. Without detailed investigation, I'm inclined to suggest referring this upstream, to the GCC libstdc++ developers/maintainers. On the...
-
Without seeing the content of your /etc/profile, I couldn't possibly comment on likely cause. However, I observe that you appear to be using MSYS2 rather than MSYS. The former is an unofficial fork, which we neither sanction nor support. I'll assign this to our official MSYS maintainer for comment, but since you do appear to be using an unsupported fork, it is likely that he will simply close this as "invalid", (i.e. "not our problem").
-
default `/etc/profile` redirect me to $HOME (while using tmux)
-
Incorrect additional backslash
-
Two comments: You should use preview, before posting; I should not have to correct your markup, after the event. You are filing against the wrong project. We do not have any <sapi.h> ... perhaps we should, but that's an entirely different issue. The hints are in your path name. Perhaps you acquired this as a Qt distributed component, in which case you should be filing a Qt bug; (we do not support Qt). Alternatively, you may have acquired it from the mingw-w64 project ... a renegate project which...
-
Update dependency on libgcc for gettext manifest
-
It's gone through several iterations since this was posted -- all references now appear to be correct.
-
cross compile-script adaptation for gcc 4.3/4.4
-
I'm no longer maintaining the cross-scripts; they haven't really been useful, since GCC-3.4.5 fell out of favour. Furthermore, I didn't require this hack, for any of GCC-4.8.2, GCC-4.9.3, GCC-5.3.0, or GCC-6.3.0, so I guess it's no longer relevant.
-
Fixed since release of mingwrt-3.22.
-
missing declaration of _vscwprintf
-
tmpnam and tmpfile
-
Two comments: 1. This tracker is for issues arising from tools provided by the MinGW.org project. You are using tools from the mingw-w64 project -- a renegade project infringing our trademark; we do not support them. 2. If your issue is with the initial \ on the return value from tmpnam(), you should read the relevant MSDN documentation; this is correct behaviour! This is not a MinGW.org bug.
-
[patch] add Registry API functions and macros introduced in Windows Vista
-
I applied [61755e] and [eb0892], representing the previously attached winreg-updates.patch and winreg-cleanup.patch respectively; this will be included in w32api-5.1.
-
Unfortunately, your patch is against a 4.x-dev branch of w32api, so is incompatible with, and doesn't apply cleanly to legacy or 5.x-trunk branches. OTOH, with the exception of one regression, which is easily corrected, there is no compelling reason not to merge the 4.x-dev version of <winreg.h> into the 5.1-trunk branch, so that your patch can be applied; attached winreg-updates.patch effectively folds your patch into the ensuing difference from the legacy branch, while winreg-cleanup.patch then...
-
Irrespective of any discussion regarding inclusion in mingwrt-4.0 vs. mingwrt-4.1, all mingwrt-4.x releases are dead and buried; this is fixed in all current mingwrt-3.x and mingwrt-5.x releases.
-
glob() may fold case in command args with no globbing tokens.
-
mingwrt-4.x is dead and buried. This issue should no longer arise, with latest mingwrt-3.x releases, or with any mingwrt-5.x release.
-
MinGW startup code pollutes the namespace by calling opendir and readdir
-
WSL: all complex math functions are missing
-
No longer an issue, for any mingwrt-3.x or mingwrt-5.x release.
-
[patch] add Registry API functions and macros introduced in Windows Vista
-
Thank you for the patch. I shall consider incorporating it, for w32api-5.1.
-
WSL: libmingwex.a lacks llround, llroundf, and llroundl functions
-
mingwrt-4.x is dead, and buried; this issue should have gone with it, and should no longer arise with any mingwrt-3.x or mingwrt-5.x release.
-
This should no longer be an issue, with any mingwrt-3.x or mingwrt-5.x release.
-
WSL: libmingwex.a contains superflouos qnan.o and arithchk.o
-
The issue of missing default definition for _WIN32_IE is addressed by commit [980877]; this will be incuded in w32api-5.1.
-
Shell_NotifyIcon support macros
-
Add the POSIX function strtok_r()
-
I've committed [8ea0d1]; this will be included in mingwrt-5.1.
-
Support strtok() re-entrancy, per request [#2342].
-
I committed [ecc51c], for inclusion in the upcoming mingwrt-5.1 release.
-
Implement the POSIX interface to high-resolution timers
-
I'm presently experimenting, to get to install MinGW in PCEM Win95 guest for debugging an application. I know it is far-fetched. Do you have any advice regarding the version I could try, btw. Or is it a fool's errand? I don't know, but it really would be better to ask on the MinGW-Users mailing list, or to open a new ticket, to discuss the new topic. (The mailing list gets better exposure to a broader corpus of users, one of whom may just know the answer). MinGW GUI setup actually doesn't run in...
-
MingWrt v5+ introduces SSE instruction that prevents execution on non-SSE OS
-
I pushed a slightly modified version of my previously proposed patch, (fixing some CFI directive usage issues), as [fa00fd]. There may be some x86-64 compatibility issues, arising out of this, so I'm leaving the ticket open.
-
Would you be interested in joining the project, in the capacity of "tester", with a particular emphasis on legacy systems support? Am I right in assuming that there won't be any time bound pressure to complete the tasks at hand? Correct. We place no demands whatsoever, on our project contributors; each is allowed to work at their own pace, as their own time constraints permit, while contributing as much, or as little, as they wish. If not so && still you would like to consider me as a tester, then...
-
For completeness, it is probably worth mentioning that, if you define _ISOC99_SOURCE, or _XOPEN_SOURCE >= 600, or _POSIX_C_SOURCE >= 200112L, as in this example: #define _ISOC99_SOURCE #include <stdio.h> #include <stdlib.h> ssize_t get_input( char **lineptr, int *len ) { printf( "Enter value (RETURN to quit): " ); fflush( stdout ); return getline( lineptr, len, stdin ); } int main() { ssize_t stop; size_t buflen = 256; char *input = malloc( buflen ); while( (stop = get_input( &input, &buflen )) >...
-
I'm sorry, but the only error here is in your expectations. You are using Microsoft's implementation of scanf(), (because that is all that MinGW has ever used for this function, and its siblings), so the behaviour is as Microsoft have specified it, (and there appears to be nothing in their documentation to suggest how infinities and nans might be converted, so you cannot expect any particular result). Whatever results you see on Debian Jessie, (or any other Linux distribution, or other non-Windows...
-
I'm sorry, but the only error here is in your expectations. You are using Microsoft's implementation of scanf(), (because that is all that MinGW has ever used for this function, and its siblings), so the behaviour is as Microsoft have specified it, (and there appears to be nothing in their documentation to suggest how infinities and nans might be converted, so you cannot expect any particular result). Whatever results you see on Debian Jessie, (or any other Linux distribution, or other non-Windows...
-
scanf doesn't parse non-finite floating point strings like "Inf" and "NaN"
-
I'm sorry, but the only error here is in your expectations. You are using Microsoft's implementation of scanf(), (because that is all that MinGW has ever used for this function, and its siblings), so the behaviour is as Microsoft have specified it, (and there appears to be nothing in their documentation to suggest how infinities and nans might be converted, so you cannot expect any particular result). Whatever results you see on Debian Jessie, (or any other Linux distribution, or other non-Windows...
-
I was probably sounding more naive than necessary on my earlier reply. I should have worded it as "I never felt qualified enough to propose it as a proper patch". What I meant by 'lacked the knowhow' was not w.r.t 'generating diff or applying a patch(which,thankfully, I do know)', rather, it was about the possible (ill?)effects of the 'added' code on other systems (that weren't tested by me). Ah, okay. I misunderstood that you may not have been comfortable with the procedure for creating, and submitting...
-
I was probably sounding more naive than necessary on my earlier reply. I should have worded it as "I never felt qualified enough to propose it as a proper patch". What I meant by 'lacked the knowhow' was not w.r.t 'generating diff or applying a patch(which,thankfully, I do know)', rather, it was about the possible (ill?)effects of the 'added' code on other systems (that weren't tested by me). Ah, okay. I misunderstood that you may not have been comfortable with the procedure for creating, and submitting...
-
I was probably sounding more naive than necessary on my earlier reply. I should have worded it as "I never felt qualified enough to propose it as a proper patch". What I meant by 'lacked the knowhow' was not w.r.t 'generating diff or applying a patch(which,thankfully, I do know)', rather, it was about the possible (ill?)effects of the 'added' code on other systems (that weren't tested by me). Ah, okay. I misunderstood that you may not have been comfortable with the procedure for creating, and submitting...
-
you should have provided patches, rather than complete replacement files I never felt qualified enough to propose a proper patch ... FWIW, this is how I generated cpu_features.original.patch, in my build directory, from your first proposed replacement for cpu_features.c: $ mkdir a b $ ln ../mingwrt/cpu_features.c a/ ; # original project version $ mv ~/Downloads/cpu_features.c b/ ; # your first replacement $ vi b/cpu_features.c ; # to tidy indentation/layout $ diff -u a/cpu_features.c b/ > cpu_features.original.patch...
-
Right now, there is no completely viable alternative. We are exploring the practicalities of migrating our package hosting to OSDN.net, but at present only mingw-get-setup.exe has been migrated, (and that still in experimental phase, so, although working, may be subject to change). You may wish to try that, but please be aware that it will still refer to SourceForge for additional packages.
-
Actually, if the OP can perform the installation on another PC, which is not behind the offending firewall, then the entire installation tree may be cloned to removable media, (USB storage, say), and then run from there, on any PC, (behind the firewall, or otherwise). Indeed, the installation could be targetted to removable media, from the outset, without requiring a permanent copy on the installing PC's hard drive; once a removable installation has been achieved, that may be cloned to fixed storage...
-
Right now, there is no completely viable alternative. We are exploring the practicalities of migrating our package hosting to OSDN.net, but at present only mingw-get-setup.exe has been migrated, (and that still in experimental phase, so, although working, may be subject to change). You may wish to try that, but please be aware that it will still refer to SourceForge for additional packages.
-
Alternative non-SourceForge Installer
1 >