Never trust update
Alas, I just hosed my MinGW.
Never, never trust 'update'.
(Now I'm trying to figure out how to get 4.8 installed. Failing that, I'm going to try to get 4.7.0 back.)
Never, never trust 'update'.
(Now I'm trying to figure out how to get 4.8 installed. Failing that, I'm going to try to get 4.7.0 back.)
I feel your pain.
I don't use MinGW, but I use Arch Linux, bleading edge distro that has its moments. When the update breaks it's a real mess.
I don't use MinGW, but I use Arch Linux, bleading edge distro that has its moments. When the update breaks it's a real mess.
It's the reason I don't use Kubuntu (or any other *ubuntu) anymore too...
After getting a bunch of broken MinGW builds (because "there is no disk in the drive", apparently, even with old builds), I've finally installed the MinGW-w64 build, which I kind of like. Alas, it's libstdc++-6.dll is incompatible with the official MinGW one but named identically -- meaning I can't just dump them both into C:\Windows\SysWOW64.
All I wanted was to be able to use <thread>/pthread. :O(
(VS compiles it fine. I shoulda been happy with that.)
So now that I've got to recompile a lot of stuff... I wonder if I'll mess around with Clang/LLVM or something.
Fedora keeps me happy too... I don't remember if I played around with Arch Linux before. It looks nice. (If I did, I got one of the broken ones, and put it away...)
After getting a bunch of broken MinGW builds (because "there is no disk in the drive", apparently, even with old builds), I've finally installed the MinGW-w64 build, which I kind of like. Alas, it's libstdc++-6.dll is incompatible with the official MinGW one but named identically -- meaning I can't just dump them both into C:\Windows\SysWOW64.
All I wanted was to be able to use <thread>/pthread. :O(
(VS compiles it fine. I shoulda been happy with that.)
So now that I've got to recompile a lot of stuff... I wonder if I'll mess around with Clang/LLVM or something.
Fedora keeps me happy too... I don't remember if I played around with Arch Linux before. It looks nice. (If I did, I got one of the broken ones, and put it away...)
Clang is a work in progress. The last time I checked, it didn't support deferred/sync flags on std::async for example ... this imperfect world we live in.
| Alas, it's libstdc++-6.dll is incompatible with the official MinGW one but named identically -- meaning I can't just dump them both into C:\Windows\SysWOW64. |
@ Duoas: If you were to argue that you shouldn't have to do this yourself then you would have a valid point, I'm certain that no one here would disagree with you. However, if you are truly dead set on accomplishing this, then that issue is a solved problem:
You could use a '.config' file to set the search path to the local directory before anything else. IIRC you're old enough to remember when DLL redirection was the goto exploit for the lazy, this would be using it for it's intended purpose.
I suggest you to use MinGW-w64 from here, it has support for threads:
http://tdragon.net/recentgcc/
libstdc++ is linked statically by default, don't worry about that and can create both x86 and x64 binaries.
http://tdragon.net/recentgcc/
libstdc++ is linked statically by default, don't worry about that and can create both x86 and x64 binaries.
Getting any compiler to work has always been a huge messy pain for me. Thankfully the good people over at LLVM are making excellent progress with the Windows version of clang.
In any other language (even C), getting compilers and libraries to work is easy. In C++? I usually give up and return months later to find that it magically works.
In any other language (even C), getting compilers and libraries to work is easy. In C++? I usually give up and return months later to find that it magically works.
@kbw
:OS
@Computergeek01
Hmm, I hadn't thought of that. DLL redirection is for overriding a specific program's DLL choice. And, AFAIK, it only allows redirection of the target directory, not the target basefile name. And if I were to try to distribute a program I wrote, I can't just poke the DLL in some non-standard spot on the user's system. It would have to go in the application directory -- obviating the need for redirection...
Though, I wonder if I can update the exe's symbol table to want to use a differently named DLL... I'll have to look at that.
(The whole point, though, was just for my own personal system... Since I don't normally keep any compiler's executable in my system path. It automatically adds it only when I use it from the command shell.)
(Oh, and you don't need a separate file -- use a Manifest :O)
Thanks!
@modoran
Wow, definitely going to mess with that.
I had previously thought that there were nebulous legal issues with statically linking the GNU runtime... But having re-read I see that I just need to have a link to the GNU libc somewhere in the documentation.
Thanks!
:OS
@Computergeek01
Hmm, I hadn't thought of that. DLL redirection is for overriding a specific program's DLL choice. And, AFAIK, it only allows redirection of the target directory, not the target basefile name. And if I were to try to distribute a program I wrote, I can't just poke the DLL in some non-standard spot on the user's system. It would have to go in the application directory -- obviating the need for redirection...
Though, I wonder if I can update the exe's symbol table to want to use a differently named DLL... I'll have to look at that.
(The whole point, though, was just for my own personal system... Since I don't normally keep any compiler's executable in my system path. It automatically adds it only when I use it from the command shell.)
(Oh, and you don't need a separate file -- use a Manifest :O)
Thanks!
@modoran
Wow, definitely going to mess with that.
I had previously thought that there were nebulous legal issues with statically linking the GNU runtime... But having re-read I see that I just need to have a link to the GNU libc somewhere in the documentation.
Thanks!
| (Oh, and you don't need a separate file -- use a Manifest :O) |
But whether you compile it into the executable or not, a manifest is a separate file... Any way yeah a manifest file is the ideal solution for executable files that you are distributing. But for something you didn't compile like MingW and you're using your self it seems like more work for just about the same result. I'm sure you already know, but remember to redirect everything in the tool chain to the same library. I broke MIDL for a day or two with that mistake.
| And if I were to try to distribute a program I wrote, I can't just poke the DLL in some non-standard spot on the user's system. |
That's exactly what Windows Side by Side is for though whether you use a .config file or a manifest. The "standard spot" for manifest files would be 'C:\Windows\WinSxS".
I hope that you're not seriously considering renaming the DLL. That just feels "hackish".
Hmm, I don't know anything about side by side assemblies (other than they exist). I've got some learning to do...
:o>
| "hackish" |
:o>
I switched to MingW-w64 a week ago, version 4.9.1:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
(Oh wow the 4.9.2 folder was created 3hs ago)
About win32/pthread threads:
I didn't personally test it on my own, but from what people says, pthread allows <thread>, but it seems like it's not as fast as regular win32 threads.
The SJLJ exception system is the old one. The SEH is the one Windows uses.
Using SJLJ an exception within a windows callback will not propagate, whereas it will using the SEH.
About DLLs, lately I've been redistributing all the DLLs with my EXE's.
I now have multiple DLLs named equally, but some are for x86, some for x64, and I really can't rename them.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
(Oh wow the 4.9.2 folder was created 3hs ago)
About win32/pthread threads:
I didn't personally test it on my own, but from what people says, pthread allows <thread>, but it seems like it's not as fast as regular win32 threads.
The SJLJ exception system is the old one. The SEH is the one Windows uses.
Using SJLJ an exception within a windows callback will not propagate, whereas it will using the SEH.
About DLLs, lately I've been redistributing all the DLLs with my EXE's.
I now have multiple DLLs named equally, but some are for x86, some for x64, and I really can't rename them.
Last edited on
Topic archived. No new replies allowed.