Autolinking when an autolinked function/class is never used
I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ? What is invariably happening when this situation occurs is that a header file which has autolinking code ( #pragma comment(lib,"somelib") in VC++ for example ) is included for functions/classes which are not in the autolinked library at all. This is because the Boost developer has not placed all the autolinked functionality for a particular library in its own header file, preferring instead to place declarations in logically related header files. While the latter is understandable as far as organization of a library is concerned it destroys the ability of that library to enforce autolinking only when the end-user requires it. Despite the fact that library developers, of Boost libraries which are not completely header only, go for orthogonality when creating their header files I would like to see things changed so that using a library which does not require the built library to be linked in when using functionality of that library does not being in autolinking. I realize that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off autolinking but this places a burden on the end user which should not be there. I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.
AMDG Edward Diener wrote:
I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ?
This can't be made to work perfectly because it will always be based on what is #included rather than what is actually used. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Edward Diener wrote:
I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ?
This can't be made to work perfectly because it will always be based on what is #included rather than what is actually used.
Yes, but if all autolinking functionality was placed in separate header file(s), and the end-user only #includes that header file which contains the functionality he uses, then it does work.
On Friday 11 July 2008 23:02:51 Edward Diener wrote:
I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.
If the distribution of unnecessary DLLs is all you are concerned about, then I think your problems are solved. I haven't looked at this particular case, but I know that in a similar case, one of my headers uses WSAGetLastError(), which requires me to link in WinSock libraries only to tell me later that the according lib was discarded because it is unused. So, just link as usual and then check if the resulting binary actually needs the DLL, otherwise I think it is a minor inconvenience one can live with or get around it as you documented. cheers Uli
Edward Diener wrote:
I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.
This is a known issue with that specific library: I did make an attempt at refactoring the headers at one point to fix this, but it went beyond my understanding of the library, so this really need Jeff Garland's help to be done correctly. John.
John Maddock wrote:
Edward Diener wrote:
I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.
This is a known issue with that specific library: I did make an attempt at refactoring the headers at one point to fix this, but it went beyond my understanding of the library, so this really need Jeff Garland's help to be done correctly.
Thanks for letting me know it is a known issue. I hope this can be enforced for all libraries for the sake of Boost end-users, to not have libraries linked in when they are not needed.
participants (4)
-
Edward Diener -
John Maddock -
Steven Watanabe -
Ulrich Eckhardt