What would be nice is a pcem build that requires no external dll's but the main problem is ppl not including them in builds (not sure the real reason why) distributing it with out the dlls is useless you may as well not bother at all as its very version dll specific you cant just get them from the internet and expect it to work. unless you have the mingw dirs in your system path (worst thing you can ever do)

Last edited by therock247uk on Tue 18 Nov, 2014 3:36 am, edited 1 time in total.

therock247uk wrote:What would be nice is a pcem build that requires no external dll's but the main problem is ppl not including them in builds (not sure the real reason why) distributing it with out the dlls is useless you may as well not bother at all as its very version dll specific you cant just get them from the internet and expect it to work.

yeah.

For now I can link libalut statically as well (but it requires exporting symbols from EXE(which may look a bit odd) or modifying alut.h NOT to put anything in ALUT_API macro) so PCem will require openal32.dll only.

It is documented on Vogons that newer versions of mingw/gcc will not build against static runtime libraries. Furthermore, statically compiling certain libraries will break multithreading operations. This is also documented.

truth wrote:It is documented on Vogons that newer versions of mingw/gcc will not build against static runtime libraries. Furthermore, statically compiling certain libraries will break multithreading operations. This is also documented.

The thing that confuses me about this is that my builds always have stdc++ and libgcc linked statically, and only OpenAL linked dynamically, using the same Makefile as everyone else. What am I doing differently?

The c/c++ runtimes may be dynamically linked but located in another directory than pcem (win32), such as the /bin directory of mingw which is typically a directory in the user's PATH. At least this is my experience with the newer gcc versions and I could verify again. I use gcc 4.6.x to avoid the issue. Further, the gcc 4.8.x has bugs, including the problem in defaulting to at least one parameter which breaks some existing software, the same software which builds correctly with older gcc versions.

I haven't tested the possibility of whether the runtimes are linking statically yet requiring a dynamic link, too (in the newer gcc versions). One method is to copy the files to a system without mingw and see if the expected error occurs.