Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64
No, that's a zlib compressed binary. Starting from offset 0x100 (256): f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88 Byte 262 is 0x1a (26) 2015-06-22 17:21 GMT+02:00 LRN lrn1...@gmail.com: On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: Hi, Without eof, it still returns 262 bytes which is wrong. That's a very arbitrary number. Is the file opened in binary mode? Anything significant around the 262th byte in the file contents? -- O ascii ribbon - stop html email! - www.asciiribbon.org -- 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 -- 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] Include and lib search paths for mingw-64
Edward Diener eldlistmaili...@tropicsoft.com writes: Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. As I mentioned on other message on this thread, you must set PATH anyways for executing the resulting binaries of your compilation. There is no possible workaround for this, other than installing libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? That's not an answer to my question: how do you deal with multiple installs of VS? (I'm sure you have several of them, unless you use multiple machines, one for each) To recap: what you are experiencing is not a consequence of oversight or lazyness from the MinGW(-w64) developers, but the less annoying solution for the problem of installing one or more MinGW(-w64) instances without causing havoc. -- 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] Include and lib search paths for mingw-64
On 6/21/2015 10:43 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: At the end, adapting your PATH setting works the best. Just a simple .bat file solves the problem for those of us that need to constantly experiment with multiple installs: @rem mingw-w64-492.bat @PATH=path-to-the-bin-directory;%PATH% @%* Now invoke that .bat with mingw-w64-492.bat g++ foo.cpp -o foo.exe mingw-w64-492.bat foo.exe Sure, but the point is that this should never be needed. The easiest solution is that any dll that cc1plus.exe needs should have been installed in the same directory as cc1plus.exe. Your other solution of putting the needed dlls in %WINDIR%/System32 is not very good unless all versions of such dlls are backward compatible since each new installation of mingw-64 might have its own version of a dll. I am surprised that such good programmers should understand so little about producing a self-enclosed installation of mingw-64 ( or mingw ) to the point of not being able to create a distribution that just works automatically when any executable, such as gcc, is invoked directly from the command line. Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? -- 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] Opening unicode filenames with MinGW-w64
On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: Hi, Without eof, it still returns 262 bytes which is wrong. That's a very arbitrary number. Is the file opened in binary mode? Anything significant around the 262th byte in the file contents? -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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
[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] Include and lib search paths for mingw-64
On 6/22/2015 4:50 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: As I mentioned on other message on this thread, you must set PATH anyways for executing the resulting binaries of your compilation. There is no possible workaround for this, other than installing libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. Maybe your frustration does not allow you to understand what I wrote. Please read it again. I expect some difficulty with the concept of having multiple installs of the toolset, with varying versions and configurations, but there is no excuse for not understanding the point about the generated executables depending on the same (and more) dlls that cc1plus.exe depends on. Unless you pretend to emit your executables to the same bin directory where those dlls are, the cleanest solution is to add the bin directory to PATH. Yes, they could install cc1plus.exe on the same bin directory where g++.exe is. That would make you happy (at the cost of making others miserable) until the moment you realize that you need to set PATH anyways. Please explain to me why I would need to set PATH anyways to a particular toolchains bin directory if the dlls needed by any particular executable in a toolchain were in the same directory as the executable itself. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. The model that MinGW(-w64) follows does not depend on what MS does or doesn't. But the fact that both toolsets have similar requirements wrt setting environment variables (with MinGW being the simplest, BTW) does tell us something about the space solution for the general problem. -- 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] Include and lib search paths for mingw-64
On 6/22/2015 8:17 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Maybe your frustration does not allow you to understand what I wrote. Please read it again. I expect some difficulty with the concept of having multiple installs of the toolset, with varying versions and configurations, but there is no excuse for not understanding the point about the generated executables depending on the same (and more) dlls that cc1plus.exe depends on. Unless you pretend to emit your executables to the same bin directory where those dlls are, the cleanest solution is to add the bin directory to PATH. Yes, they could install cc1plus.exe on the same bin directory where g++.exe is. That would make you happy (at the cost of making others miserable) until the moment you realize that you need to set PATH anyways. Please explain to me why I would need to set PATH anyways to a particular toolchains bin directory if the dlls needed by any particular executable in a toolchain were in the same directory as the executable itself. Ok, I'll try with different wording: Do you plan to create your executables in the bin directory of the toolchain? Surely not. As those executables compiled by you will depend on the same dlls that cc1plus.exe et al. depend on, you need to add the directory that holds those dlls to PATH (or copy them to the directory that holds your executable.) You have made a good point, but see my subsequent answers... My usage of mingw-64 might be to only compile, or to compile/link, without the need to run anything immediately. So moving cc1plus.exe to `bin' makes the toolchain self contained, but it is no solution as soon as you try to execute the programs you created with that toolchain. One of the most favored methods of doing what you suggested is to copy whatever dlls are needed by the module created into the same directory where the module was created. This is no different from my suggestion that the same thing be done with a mingw-64 toolchain. But however I decided to do things it should be up to me to make that decision and not up to mingw-64 to create their own toolchain so that I am forced to add some toolchain's bin directory to my PATH just to compile and/or link my module. Furthermore with multiple toolchains your method of adding the toolchains bin directory to the PATH is asking for problems. What happens after I finish my compile/link cycle and test my program from within some batch file created simply for that purpose by temporarily putting some mingw-64's toolchain's bin directory in my PATH. I now go to run my program and the temporary addition to my PATH is gone and my program refuses to start. Now I have to go back and work out which mingw-64 toolchain created the program and which dlls I need from that toolchain. Clearly I am not going to add multiple toolchain bin directories to my PATH permanently, since any given module will now be picking up its dlls from the first toolchain bin directory in my PATH, which may not be the dlls that I need. In fact the whole business of adding any compiler toolchain's bin directory to the PATH permanently is a recipe for disaster. And if you think that the correct way to actually permanently execute my program is to do so from a batch file so that the correct toolchain's bin directory is in the PATH you are in a programming world which I am all too glad never to want to enter. I am not saying there is no place in programming where installing the latest same-named, totally backward compatible dll into a directory permananently in the PATH has its value. But that place is not multiple mingw-64 toolchains with their proliferation of dlls for compile and/or run-time use. I do understand why you say that the toolchain's bin directly may need to be added to the PATH in order to run my program directly after the compile/link cycle. But I would still heavily prefer that mingw-64 create their toolchains so that I can compile/link my program without having to manipulate the PATH variable in any way. Once I finish compile/link of my module(s) how I choose to ensure that the needed modules are in the correct place to run my program should be up to me. -- 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] Opening unicode filenames with MinGW-w64
Hi,
I have tried to open the file with _wfopen(), pass it to __gnu_cxx::
stdio_filebufchar, and set it as the buffer of an std::istream.
The file is open properly, first bytes are OK, but after 263 read bytes I
get an eof(), while the file is 39MB large.
Reading works well with a standard std::ifstream and a non-unicode file
name, and I am testing the simplest way possible:
int i = 0;
while(!stream.eof())
{
char a;
stream.read(a, 1);
i++;
}
info(%d,i);
If nobody has an idea, I will give up for a Qt-based solution but I
was hoping making a source code that would compile without any
external library (with some preprocessing for detecting the Windows
case)
Thanks,
Etienne
2015-06-19 16:59 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com:
2015-06-19 16:56 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com:
2015-06-19 16:45 GMT+02:00 Etienne Sandré-Chardonnal
etienne.san...@m4x.org:
Dear all
I have found this old gcc discussion from Ruben :
http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html
Is this available in recent mingw releases? I cannot find any of these
extensions in 4.9.2 headers (and it does not work)
No, unfortunately, it is not. You must manually work around this
shortcoming by e.g. using the libstdc++ extension:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_io.html
Note that proper memory management is kind of tricky (you need to take
care of the file descriptor or FILE* yourself)
Correction: onl the FILE* if you use that constructor. File descriptors
are handled by the stdio_filebuf destructor.
See: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00070.html
Ruben
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
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] Include and lib search paths for mingw-64
JonY jo...@users.sourceforge.net writes: This. This is the reason why it was never changed, because it was never seen as a problem, its just something you did. I setup PATH depending on which compiler version I want to use, all sharing the same mingw-w64 install, courtesy of hardcoded paths. And anyways you need to set PATH for executing the resulting executables, because most often those depend on some gcc or MinGW-w64 related dll such as libstdc++ (unless you make the effort of doing a static link). -- 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] Include and lib search paths for mingw-64
On 6/22/2015 10:43, Óscar Fuentes wrote: I am surprised that such good programmers should understand so little about producing a self-enclosed installation of mingw-64 ( or mingw ) to the point of not being able to create a distribution that just works automatically when any executable, such as gcc, is invoked directly from the command line. Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on a regular basis. This. This is the reason why it was never changed, because it was never seen as a problem, its just something you did. I setup PATH depending on which compiler version I want to use, all sharing the same mingw-w64 install, courtesy of hardcoded paths. 0xD4EBC740.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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] Include and lib search paths for mingw-64
Edward, I'm really flashed about the enormous patience and tolerance from this community. However, you may or may not noticed, that there are different builds with configurations for mingw-w64 based toolchains available. What you need for your purpose is a toolchain that is based on statically linked gcc runtimes. That means, the binaries build by the compiler do not depend on the runtime DLLs delivered by the toolchain. What comes into my mind is: TDMs toolchain: http://tdm-gcc.tdragon.net and equation.com: http://www.equation.com/servlet/equation.cmd?fa=programminglog I didn't test the fully relocability of these toolchains itself (without setting the PATH) , but the compiled binaries are self-contained. This procedure is not recommened for C++ programming with heavy use of exceptions though, because exceptions can't be propagated across DLL boundaries (TDM's toolchain has patches to allow this AFAIK). My own set of builds of the toolchain are more targeted to the needs of python extension development but may be of interest too: see https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy-2015-04-readme.pdf And you are free to build the mingw-w64 based gcc toolchains yourself and offer patches. Carl 2015-06-22 20:15 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com: On 6/22/2015 12:02 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. As I mentioned on other message on this thread, you must set PATH anyways for executing the resulting binaries of your compilation. There is no possible workaround for this, other than installing libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? That's not an answer to my question: how do you deal with multiple installs of VS? (I'm sure you have several of them, unless you use multiple machines, one for each) To recap: what you are experiencing is not a consequence of oversight or lazyness from the MinGW(-w64) developers, but the less annoying solution for the problem of installing one or more MinGW(-w64) instances without causing havoc. -- 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 ___
Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64
On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote: On 2015-06-22 17:21 GMT+02:00 LRN wrote: On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: Hi, Without eof, it still returns 262 bytes which is wrong. That's a very arbitrary number. Is the file opened in binary mode? Anything significant around the 262th byte in the file contents? No, that's a zlib compressed binary. Starting from offset 0x100 (256): f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88 Byte 262 is 0x1a (26) Sorry, i've got nothing. -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- 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] Opening unicode filenames with MinGW-w64
Op 22-jun.-2015 19:48 schreef LRN lrn1...@gmail.com: On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote: On 2015-06-22 17:21 GMT+02:00 LRN wrote: On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: Hi, Without eof, it still returns 262 bytes which is wrong. That's a very arbitrary number. Is the file opened in binary mode? Anything significant around the 262th byte in the file contents? No, that's a zlib compressed binary. Starting from offset 0x100 (256): f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88 Byte 262 is 0x1a (26) Can you send the file or a similar one that displays the issue? Ruben Sorry, i've got nothing. -- O ascii ribbon - stop html email! - www.asciiribbon.org -- 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 -- 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] Include and lib search paths for mingw-64
On 6/22/2015 12:02 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Apparently those programmers are not so inconvenienced as you are by having to use methods like the .bat mentioned above. And I can assure you that some of those programmers have quite a few gcc installs on their machines, that they use on a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. As I mentioned on other message on this thread, you must set PATH anyways for executing the resulting binaries of your compilation. There is no possible workaround for this, other than installing libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? That's not an answer to my question: how do you deal with multiple installs of VS? (I'm sure you have several of them, unless you use multiple machines, one for each) To recap: what you are experiencing is not a consequence of oversight or lazyness from the MinGW(-w64) developers, but the less annoying solution for the problem of installing one or more MinGW(-w64) instances without causing havoc. -- 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] Opening unicode filenames with MinGW-w64
0x1a / 26 / Ctrl+Z is the old DOS EOF character: https://en.wikipedia.org/wiki/Substitute_character Was this file opened in text mode? See the MSDN documentation for _fopen() for details, mode t. On 06/22/2015 09:09 AM, Etienne Sandré-Chardonnal wrote: No, that's a zlib compressed binary. Starting from offset 0x100 (256): f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88 Byte 262 is 0x1a (26) 2015-06-22 17:21 GMT+02:00 LRN lrn1...@gmail.com mailto:lrn1...@gmail.com: HTH, -- Mook -- 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] Opening unicode filenames with MinGW-w64
2015-06-22 13:21 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org
:
Hi,
I have tried to open the file with _wfopen(), pass it to __gnu_cxx::
stdio_filebufchar, and set it as the buffer of an std::istream.
The file is open properly, first bytes are OK, but after 263 read bytes I
get an eof(), while the file is 39MB large.
Reading works well with a standard std::ifstream and a non-unicode file
name, and I am testing the simplest way possible:
int i = 0;
while(!stream.eof())
{
char a;
stream.read(a, 1);
i++;
}
info(%d,i);
If nobody has an idea, I will give up for a Qt-based solution but I was
hoping making a source code that would compile without any external library
(with some preprocessing for detecting the Windows case)
That is not the right way to read from a C++ istream. Do something like
this:
std::size_t i = 0;
char a;
while(stream.read(a, 1))
{
++i;
}
info(%d, i);
I.e. put the read action in the condition of the loop. Checking eof doesn't
get you what you want, see here:
http://stackoverflow.com/questions/5605125/why-is-iostreameof-inside-a-loop-condition-considered-wrong
Also, if you're using Qt anyways, it is indeed much preferred to use its
I/O system, so that you don't rely on a libstdc++ extension.
Cheers,
Ruben
--
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] Opening unicode filenames with MinGW-w64
Hi, Without eof, it still returns 262 bytes which is wrong. I ended up writing my own streambuf reading from a FILE* and this now returns the proper value (around 40MB) The custom streambuf is based on this : http://www.mr-edd.co.uk/blog/beginners_guide_streambuf There is definitely a bug in this extension : __gnu_cxx::stdio_filebuf Cheers, Etienne -- 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
