Sign in to follow this  

No Dynamic CRT in GCC/MingW?

This topic is 4357 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was just wondering since it appears to me that both GCC/MingW dont have a dynamic CRT/CPRT. So how do applications which use dynamic linked libraries(dll/so) work in Linux/Win32(MingW)? Wont they each be having their own heap which could cause problems? Does this mean that is is impossible to new a variable in a DLL and delete it in an exe or vice-versa? Will it affect the porting of my applications created in MSVC?

Share this post


Link to post
Share on other sites
Quote:
Original post by GamerSg
I was just wondering since it appears to me that both GCC/MingW dont have a dynamic CRT/CPRT. So how do applications which use dynamic linked libraries(dll/so) work in Linux/Win32(MingW)?

Wont they each be having their own heap which could cause problems?
Does this mean that is is impossible to new a variable in a DLL and delete it in an exe or vice-versa?
Will it affect the porting of my applications created in MSVC?


In general you should never assume that different DLL's share the same heap. i.e. doing 'new' in one DLL and then 'delete' in another is always a bad idea. It is platform and compiler dependend. One way to solve this is to make sure the memory management of some object is always done in the same module. Ref counting can help with this (this is how we solve it in Crystal Space).

Greetings,

Share this post


Link to post
Share on other sites
Yes, i have tried my best so far to avoid newing/deleting in different places, but besides new/deleting are there any other differences i should take note of when comparing dynamic C/C++ runtimes with static ones.

Share this post


Link to post
Share on other sites
Quote:
Original post by GamerSg
In general you should never assume that different DLL's share the same heap. i.e. doing 'new' in one DLL and then 'delete' in another is always a bad idea.

Overload the global new/delete in the DLL, and replace them with two function pointer calls. Set these FPs to two functions in the main exe, which allocate and free memory respectively. Now all your new/delete calls in the DLL will be routed over to the main exe, and you can mix calls at will.

Quote:
Original post by GamerSg
Yes, i have tried my best so far to avoid newing/deleting in different places, but besides new/deleting are there any other differences i should take note of when comparing dynamic C/C++ runtimes with static ones.

Every CRT function that allocates memory internally over malloc/free, and/or keeps a static copy of some management structure. FILE and fstreams, for example, should never be passed over DLL boundaries. You may however write a wrapper class around them, and make sure they are always handled within the same module.

Share this post


Link to post
Share on other sites
Quote:
Original post by GamerSg
I was just wondering since it appears to me that both GCC/MingW dont have a dynamic CRT/CPRT. So how do applications which use dynamic linked libraries(dll/so) work in Linux/Win32(MingW)?

What gave you the impression that either MingW or Linux do not use a dynamically-loaded C runtime? They both do (you can also statically link the C runtime in, but it takes extra work and is rarely done).
Quote:

Wont they each be having their own heap which could cause problems?
Does this mean that is is impossible to new a variable in a DLL and delete it in an exe or vice-versa?
Will it affect the porting of my applications created in MSVC?

GCC on MingW produces PEI-COFF binaries, and use the same symbolic namespacing as the Microsoft compiler-produced PEI-COFF binaries. You can link together modules produced by either compiler into an executable or DLL.

GCC on Linux produces ELF binaries, which have a flat namespace. A flat namespace is far simpler to program to. Generally speaking anything you write for Windows can be ported easily to Linux (or any other ELF-based platform), at least when it comes to the rules of cross-module lifetimes, etc. It doesn't necessarily work the other way.

For example, in Linux it's technically okay to create an object in one DSO and destroy it in another, because the flat namespace means only one instance of the global operator new can exist in an executing image. This is not necessarily true in Windows (or, just as pointedly, in Mac OS X, which uses MACH-O binaries with a two-level namespace).


Share this post


Link to post
Share on other sites

This topic is 4357 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this