- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
When I compiled the source with tbb, I got a warning that I should not compile it with static runtime libraries.
How serious is this warning? What if I ignore it? What can happen?
I am not in favour of dlls.
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - aftershock4
Hi,
When I compiled the source with tbb, I got a warning that I should not compile it with static runtime libraries.
How serious is this warning? What if I ignore it? What can happen?
I am not in favour of dlls.
I once had some obscure trouble with the allocators before (a few months ago), can't remember exactly what it was, and thus decided to go with shared libraries (dlls). But I also remember in the far past (2 years ago) using static linking just fine.
If it seems to work, it's probably working, but then again your entering unsupported land, so proceed with care, and have a very good test harness, that can catch the differences between your blank (the runtime) and test (the static) programs.
Also you need to be sure that non of the other libraries you are using depends on TBB, or your schedulers might have problems (although I've never been in this situation, so I can't assure you anything)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - robert.jay.gould
I once had some obscure trouble with the allocators before (a few months ago), can't remember exactly what it was, and thus decided to go with shared libraries (dlls). But I also remember in the far past (2 years ago) using static linking just fine.
If it seems to work, it's probably working, but then again your entering unsupported land, so proceed with care, and have a very good test harness, that can catch the differences between your blank (the runtime) and test (the static) programs.
Also you need to be sure that non of the other libraries you are using depends on TBB, or your schedulers might have problems (although I've never been in this situation, so I can't assure you anything)
Robert, it seems your answer is more about static linking with TBB, while the question seems to be about static linking with MS runtime.
Nevertheless, I agree with what you said, except for the last part - if TBB is linked dynamically by all modules using it, then they share one copy of TBB scheduler, thread pool, etc. and have no problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Alexey Kukanov (Intel)
Robert, it seems your answer is more about static linking with TBB, while the question seems to be about static linking with MS runtime.
Nevertheless, I agree with what you said, except for the last part - if TBB is linked dynamically by all modules using it, then they share one copy of TBB scheduler, thread pool, etc. and have no problem.
Sorry, I guess I wasn't clear enough on my last point. What I meant was that if you statically link TBB into your application, and also use some other library which dynamically links TBB (thus the application has a static and a runtime version of TBB at the same time) you'll likely (definitely?) have more than one copy of the scheduler and thread pools.
But this also goes the other way too, if you are developing a library, and you statically use TBB, you might cause trouble to your users when they want to use TBB, or worse link with other libraries using TBB (now they might not even be aware of what's wrong). This is the actually dangerous part of statically linking TBB IMHO.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, what Robert wrote in #3 is all correct. Linking TBB statically is generallybad idea for a multimodular app.
Linking TBB dynamically while linking C++ runtime library (RTL) statically is not a supported configuration either; we do not test it and we do not know what problems it can have.
The usual problem of this kind is memory management, but as far as I can tell TBB usage does not demand an app to free memory allocated by TBB, or vice versa.
Other source of problem would be some runtime state variables such as errno that are used to transfer information across modules. The only TBB part that sets errnois its scalable memory allocator (to comply with standard imposed requirements on malloc & Co); so checking errno value after a call to scalable_malloc will get meaningless results when the app uses static RTL and TBB uses DLL RTL.
I think exception handling and run-time type information (RTTI) requires some support from C++ RTL, so having the app and TBB working with different copies of RTL migth cause problems with exception support in TBB.
Linking TBB dynamically while linking C++ runtime library (RTL) statically is not a supported configuration either; we do not test it and we do not know what problems it can have.
The usual problem of this kind is memory management, but as far as I can tell TBB usage does not demand an app to free memory allocated by TBB, or vice versa.
Other source of problem would be some runtime state variables such as errno that are used to transfer information across modules. The only TBB part that sets errnois its scalable memory allocator (to comply with standard imposed requirements on malloc & Co); so checking errno value after a call to scalable_malloc will get meaningless results when the app uses static RTL and TBB uses DLL RTL.
I think exception handling and run-time type information (RTTI) requires some support from C++ RTL, so having the app and TBB working with different copies of RTL migth cause problems with exception support in TBB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Alexey Kukanov (Intel)
Yes, what Robert wrote in #3 is all correct. Linking TBB statically is generallybad idea for a multimodular app.
Linking TBB dynamically while linking C++ runtime library (RTL) statically is not a supported configuration either; we do not test it and we do not know what problems it can have.
The usual problem of this kind is memory management, but as far as I can tell TBB usage does not demand an app to free memory allocated by TBB, or vice versa.
Other source of problem would be some runtime state variables such as errno that are used to transfer information across modules. The only TBB part that sets errnois its scalable memory allocator (to comply with standard imposed requirements on malloc & Co); so checking errno value after a call to scalable_malloc will get meaningless results when the app uses static RTL and TBB uses DLL RTL.
I think exception handling and run-time type information (RTTI) requires some support from C++ RTL, so having the app and TBB working with different copies of RTL migth cause problems with exception support in TBB.
Linking TBB dynamically while linking C++ runtime library (RTL) statically is not a supported configuration either; we do not test it and we do not know what problems it can have.
The usual problem of this kind is memory management, but as far as I can tell TBB usage does not demand an app to free memory allocated by TBB, or vice versa.
Other source of problem would be some runtime state variables such as errno that are used to transfer information across modules. The only TBB part that sets errnois its scalable memory allocator (to comply with standard imposed requirements on malloc & Co); so checking errno value after a call to scalable_malloc will get meaningless results when the app uses static RTL and TBB uses DLL RTL.
I think exception handling and run-time type information (RTTI) requires some support from C++ RTL, so having the app and TBB working with different copies of RTL migth cause problems with exception support in TBB.
I have modified the commercially aligned release makefile to statically link with the MS run-time and it seems to work just fine. However, I think I tried the same thing with the development release and it failed at run-time (this was a while ago, so I don't remember axactly what happened).
Is there any chance of this becoming an officially supported build configuration?
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - pvonkaenel
Is there any chance of this becoming an officially supported build configuration?
It isn't impossible, but it isn't in plans either.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page