Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


#ActualHodgman

Posted 07 February 2013 - 11:08 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs?

Uh, kind of, not really.
The DLL itself isn't affected by these settings (i.e. there's no such thing as a multithreaded DLL/EXE vs a singlethreaded DLL/EXE) - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too... So that's 3 binary choices, leading to 8 different versions of the runtime that you can choose from.

Trouble appears when different parts of your program (different DLLs/EXEs/libs) are linked against different versions of the runtime, especially if standard objects are shared between these different parts of your program. Sometimes these conflicts straight up cause your program to fail at the linker step due to conflicts, other times it successfully links but crashes on startup due to a mixture of runtimes operating on the same objects (with different layouts), and sometimes it crashes later when you're calling code that crosses a module boundary...

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you ever integrate some middleware in the future that does require the use of multiple threads, then you might be forced to use the MT version of the runtime at that point anyway.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have. To be safe, go back and rebuild all your 3rd party code... unsure.png 
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out... I usually just check the build configuration that was used to generate the exe/lib/dll in the first place.


#5Hodgman

Posted 07 February 2013 - 11:06 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs?

Uh, kind of, not really.
The DLL itself isn't affected by these settings (i.e. there's no such thing as a multithreaded DLL/EXE vs a singlethreaded DLL/EXE) - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too... So that's 3 binary choices, leading to 8 different versions of the runtime that you can choose from.

Trouble appears when different parts of your program (different DLLs/EXEs/libs) are linked against different versions of the runtime, especially if standard objects are shared between these different parts of your program.

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you ever integrate some middleware in the future that does require the use of multiple threads, then you might be forced to use the MT version of the runtime at that point anyway.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have. To be safe, go back and rebuild all your 3rd party code... unsure.png 
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out... I usually just check the build configuration that was used to generate the exe/lib/dll in the first place.


#4Hodgman

Posted 07 February 2013 - 11:05 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs?

Uh, kind of, not really.
The DLL itself isn't affected by these settings (i.e. there's no such thing as a multithreaded DLL/EXE vs a singlethreaded DLL/EXE) - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too... So that's 3 binary choices, leading to 8 different versions of the runtime that you can choose from.

Trouble appears when different parts of your program (different DLLs/EXEs/libs) are linked against different versions of the runtime, especially if standard objects are shared between these different parts of your program.

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you ever integrate some middleware in the future that does require the use of multiple threads, then you might be forced to use the MT version of the runtime at that point anyway.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have. To be safe, go back and rebuild all your 3rd party code... unsure.png 
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out...


#3Hodgman

Posted 07 February 2013 - 11:02 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

Uh, kind of, not really.
The DLL itself isn't affected by these settings - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too... So that's 3 binary choices, leading to 8 different versions of the runtime that you can choose from.

Trouble appears when different parts of your program are linked against different versions of the runtime, especially if standard objects are shared between these different parts of your program.

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you ever integrate some middleware in the future that does require the use of multiple threads, then you might be forced to use the MT version of the runtime at that point anyway.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have. To be safe, go back and rebuild all your 3rd party code... unsure.png 
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out...


#2Hodgman

Posted 07 February 2013 - 10:59 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

Uh, kind of, not really.
The DLL itself isn't affected by these settings - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too...

Trouble appears when different parts of your program are linked against different versions of the runtime, especially if standard objects are passed between these different parts of your program.

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you ever integrate some middleware in the future that does require the use of multiple threads, then you might be forced to use the MT version of the runtime at that point anyway.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have. To be safe, go back and rebuild all your 3rd party code... unsure.png 
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out...


#1Hodgman

Posted 07 February 2013 - 10:57 PM

When compiling DLLs, a DLL can either be single-threaded or multithreaded, right? And it can either be a debug or release build, right?
When compiling an executable, every DLL connected to it must be the same thread type (single vs multithreaded) and the same build type (debug vs release), correct?
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

Uh, kind of, not really.
The DLL itself isn't affected by these settings - what you're talking about is the version of the C++ runtime (C and C++ standard libraries) that your DLL/EXE is linked against. As well as linking against the runtime as either single-threaded/thread-safe debug/release DLLs, you've also got the choice of linking to the single/thread-safe debug/release static-library versions of the runtime too...

Trouble appears when different parts of your program are linked against different versions of the runtime, especially if standard objects are passed between these different parts of your program.

I don't actually use multithreaded code in my project.
Should I be building all the third-party libraries as multithreaded DLLs anyway?

Yeah you should probably use the multithreaded (i.e. thread-safe) versions, as they're the most common choice. If you even integrate some middleware that does require the use of multiple threads, then you might be forced to use this version of the runtime.

I've built the Boost libraries as 'multithreaded DLLs', and I don't know if I built the other third-party libraries with that or not.
What is the difference between 'multithreaded DLLs' and regular DLLs? How do I check if a DLL is multithreaded or not?

It's a pain of C++ that you'll need to rebuild all of your 3rd party code to use the same version of the runtime, or trust the 3rd party provider that they've used the same version as you have.
I'm not sure how to check which version has been linked in... I guess by inspecting the symbols in the library you could find out...

PARTNERS