using CRT with DLLs [RESOLVED, aka Verg is a dope]

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

Recommended Posts

I've searched around... but can't seem to come up with a solution to this... Much of our base code is built into static .libs, with either the /MT or /MTd switch, depending on which type of configuration (Debug/Release/etc...) Naturally, these switches map directly to which version(s) of the CRT are linked in. Now, building a DLL using this code seems to be impossible; if I link with /MT or /MTd, the linker complains that it can't find a "main" (or symbol "_main")... this being a DLL, there isn't one... ... and if I link the DLL using /MD or /MDd, there are conflicts (symbols already being defined, etc...) ----------------- Does this mean: I have to build all the base code with the /MD and /MDd switches and link them in? Isn't linking with /MD(d) virtually guaranteeing I'll have to redistribute MSVCRT(71)(D).dll with any app that uses the .dll? ----------------- And... if I build the DLL with the /MD versions of the CRT... can it still be called from code built with the /MT versions? Thanks for any reply. Chad [EDIT TO ADD] I've seen this from MSDN... but it doesn't really answer the question... although I'm nearly positive I'll have to re-build each of the .libs just for the .dll... and almost sure the .dll would still work with /MT(d) code calling it... just not "positive". That's really the only question... hopefully, I don't have to build *everything* with /MD(d)... [Edited by - Verg on July 24, 2005 11:49:08 AM]

Share on other sites
Ah, nevermind... this seems to answer it:

You can link your DLL with CRTDLL.LIB/MSVCRT.LIB regardless of what your .EXE is linked with if you avoid mixing CRT data structures and passing CRT file handles or CRT FILE* pointers to other modules.When mixing library types adhere to the following:•	CRT file handles may only be operated on by the CRT module that created them.•	CRT FILE* pointers may only be operated on by the CRT module that created them.•	Memory allocated with the CRT function malloc() may only be freed or reallocated by the CRT module that allocated it.To illustrate this, consider the following example:   - .EXE is linked with MSVCRT.LIB   - DLL A is linked with LIBCMT.LIB   - DLL B is linked with CRTDLL.LIB				If the .EXE creates a CRT file handle using _create() or _open(), this file handle may only be passed to _lseek(), _read(), _write(), _close(), etc. in the .EXE file. Do not pass this CRT file handle to either DLL. Do not pass a CRT file handle obtained from either DLL to the other DLL or to the .EXE.If DLL A allocates a block of memory with malloc(), only DLL A may call free(), _expand(), or realloc() to operate on that block. You cannot call malloc() from DLL A and try to free that block from the .EXE or from DLL B.NOTE: If all three modules were linked with CRTDLL.LIB or all three were linked with MSVCRT.LIb, these restrictions would not apply.When linking DLLs with LIBC.LIB, be aware that if there is a possibility that such a DLL will be called by a multithreaded program, the DLL will not support multiple threads running in the DLL at the same time, which can cause major problems. If there is a possibility that the DLL will be called by multithreaded programs, be sure to link it with one of the libraries that support multithreaded programs (LIBCMT.LIB, CRTDLL.LIB or MSVCRT.LIB).

• What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 9
• 11
• 9
• 9
• Forum Statistics

• Total Topics
634135
• Total Posts
3015753
×

Important Information

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!