PureBasic Forums - English

Not really a feature request, maybe you want to move it under documention bugs even if not a bug ?

In any case, for 5.40 you wrote:

Updated: the Windows compiler to VC++ 2013 for better code generation

http://www.purebasic.fr/english/viewtop ... 32#p474532


Could you please add this info to the manual, add the same for the other platforms, and keep this updated in the future ?

Sometimes when I have to build a c/c++ library, using the same compiler version you used to build the PB libraries can make life a lot easier.

Less problems with unresolved symbols when linking, and sometime smaller executables.

Probably it's most useful to know this on Windows, but may be useful for linux and osx too.

Ideally the compiler flags used should be mentioned too, or maybe you could make accessible the make files used to build the package, or anything else useful to access this kind of information.

Thank you.

Can you give an example of linking problems when using a PureBasic DLL? If I'm not mistaken, everything is statically linked and has no dependency on Visual Studio's mcvcrt.

Mistrel wrote:Can you give an example of linking problems when using a PureBasic DLL?

I can't.

In fact using dll is the easiest way to avoid the problems you have with static linking.
You can easily link dlls to executables built by different versions of the same compiler and even by different compilers.

But I wasn't talking about dll, I was talking about libraries built with a c/c+ compiler and statically linked to a PB program to create a single executable.

Maybe I should have mentioned the word 'static', but since this is a well known problem encountered only with static libraries I've omitted it, a dll is just an exe with some exports mapped to the the same address space of the calling process and so does not suffer of the same linking problems.

Ok, yes; I understand now.

If every you want maximum portability when compiling a form of static library on Windows where you don't know the version of the CRT you're linking with, use the compiler from the DDK instead of Visual Studio to link against the Kernel msvcrt.dll rather than a userspace one.

As for your suggestion specifically, maybe Fred could add the Visual Studio msvcrt DLL redistributable to the SDK folder?