Hi. First post here :)
I just spent a couple of hours figuring out why a c++ program I compiled on windows (not my main OS) would not run. I am linking my program with libstdc++ and compiling with the MinGW toolset.
Now, I have pd-extended installed on the same machine and when it installed, it put it's own copy of libstdc++ in c:\WINDOWS\system32. The way Windows loads libraries is: first looks on the directory where the exe is, then it looks on the system folder and then it looks on the PATH.
The problem with my program was, then, that the MinGW linker did not like the version of libstdc++ put in the system folder by pd-extended installer. Uninstalling pd-extended "fixed" the issue.
So, I just want to throw this out there: Should the pd-extended installers avoid putting libraries on the system folder to avoid this kind of confusion?
My 2 cents.
Thanks!
:)
Sounds like there is some problem there. Handling DLLs on windows is painful. At the very least, you should make a bug report on this topic. Contributing a well tested fix would be even better!
.hc
Rafael Vega wrote:
Hi. First post here :)
I just spent a couple of hours figuring out why a c++ program I compiled on windows (not my main OS) would not run. I am linking my program with libstdc++ and compiling with the MinGW toolset.
Now, I have pd-extended installed on the same machine and when it installed, it put it's own copy of libstdc++ in c:\WINDOWS\system32. The way Windows loads libraries is: first looks on the directory where the exe is, then it looks on the system folder and then it looks on the PATH.
The problem with my program was, then, that the MinGW linker did not like the version of libstdc++ put in the system folder by pd-extended installer. Uninstalling pd-extended "fixed" the issue.
So, I just want to throw this out there: Should the pd-extended installers avoid putting libraries on the system folder to avoid this kind of confusion?
My 2 cents.
Thanks!
:)
This body part will be downloaded on demand.