[uuid] PR to remove auto-linking to advapi32 when BOOST_ALL_NO_LIB is defined
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ? My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library. What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.
On Thu, Sep 15, 2016 at 11:04 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uu id/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.
I agree with the PR. Someone defining BOOST_ALL_NO_LIB expects to have control of what they are linking. And they expect to get link errors for libs they need to link it. And it might be they are in the use case where they are creating a DLL/SO of their own and can incorporate external, in this case UUID, DLL code themselves. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 9/15/2016 12:19 PM, Rene Rivera wrote:
On Thu, Sep 15, 2016 at 11:04 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uu id/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.
I agree with the PR. Someone defining expects to have control of what they are linking. And they expect to get link errors for libs they need to link it. And it might be they are in the use case where they are creating a DLL/SO of their own and can incorporate external, in this case UUID, DLL code themselves.
But if they use the part of the code in the header file which needs to link with a DLL/SO which has no static library, they will need to specify that DLL/SO for the linker anyway, else they will have linker errors. This will be the same if they create a DLL/SO of their own or not AFAICS. I can understand your saying that BOOST_ALL_NO_LIB should refer to all cases, whether the library is a Boost library or not, whether the library has a static library equiavalent or not. But I am wondering if that is the official config macro intent. The part of the PR with which I do agree is that if another DLL is being used for WIN_CE then the autolinking pragma has to be corrected for that situation. But whether or not the #pragma should be removed in favor of config auto-linking I still do not know.
On September 15, 2016 12:19:01 PM EDT, Rene Rivera <grafikrobot@gmail.com> wrote:
On Thu, Sep 15, 2016 at 11:04 AM, Edward Diener <eldiener@tropicsoft.com> wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uu id/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
I agree with the PR. Someone defining BOOST_ALL_NO_LIB expects to have control of what they are linking. And they expect to get link errors for libs they need to link it. And it might be they are in the use case where they are creating a DLL/SO of their own and can incorporate external, in this case UUID, DLL code themselves.
That sounds right to me. The breakage will be at link time, so it isn't a big deal. -- Rob (Sent from my portable computation device.)
AMDG On 09/15/2016 10:04 AM, Edward Diener wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.
The real question is whether BOOST_ALL_NO_LIB disables all auto-linking (including system libraries) or only auto-linking for Boost libraries. I've always assumed the latter. In Christ, Steven Watanabe
On 9/15/2016 12:25 PM, Steven Watanabe wrote:
AMDG
On 09/15/2016 10:04 AM, Edward Diener wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ). If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
What I am afraid of is breaking user code even if BOOST_ALL_NO_LIB is defined by producing link errors. But perhaps I am wrong and this should be considered justified when BOOST_ALL_NO_LIB is being used.
The real question is whether BOOST_ALL_NO_LIB disables all auto-linking (including system libraries) or only auto-linking for Boost libraries. I've always assumed the latter.
Good point. To me there are two different cases of which your post is one of them. The other is if a shared library has no static lib equivalent. In Boost this almost never occurs but in Windows all the base Windows DLLs exist in that form and not as static libs. The same could be true for other shared libraries.
On 09/15/16 19:04, Edward Diener wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ).
I've added a comment to the PR.
If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
I think it doesn't matter whether auto-linking drings in a static or a shared library - you can't even tell at this point. My understanding that the macro is supposed to turn auto-linking completely off. That said, as I described in the comment, this may break things when a reader-only library with external dependencies, such as Boost.UUID, is used in a copmilable Boost library. When Boost libraries are built BOOST_ALL_NO_LIB is always defined (presumably, to allow Boost.Build manage dependencies itself?), so the external depenency of Boost.UUID would be missing. I think we should (a) decide if BOOST_ALL_NO_LIB needs to be defined while building Boost and (b) if it does, provide a way for users to disable auto-linking while it is still partially enabled in cases like Boost.UUID.
On 09/15/16 19:45, Andrey Semashev wrote:
On 09/15/16 19:04, Edward Diener wrote:
I don't know how to resolve a PR for uuid ( https://github.com/boostorg/uuid/pull/11 ).
I've added a comment to the PR.
If a library exists only as a DLL and not as a static library should BOOST_ALL_NO_LIB still be considered in effect ?
My viewpoint is 'no' but the person who created the PR believes that the BOOST_ALL_NO_LIB config macro should turn off any #pragma auto-linking in code even when their is no other way to use a library other than as a shared library.
I think it doesn't matter whether auto-linking drings in a static or a shared library - you can't even tell at this point. My understanding that the macro is supposed to turn auto-linking completely off.
That said, as I described in the comment, this may break things when a reader-only library with external dependencies,
That should be "header-only".
such as Boost.UUID, is used in a copmilable Boost library. When Boost libraries are built BOOST_ALL_NO_LIB is always defined (presumably, to allow Boost.Build manage dependencies itself?), so the external depenency of Boost.UUID would be missing.
I think we should (a) decide if BOOST_ALL_NO_LIB needs to be defined while building Boost and (b) if it does, provide a way for users to disable auto-linking while it is still partially enabled in cases like Boost.UUID.
participants (5)
-
Andrey Semashev -
Edward Diener -
Rene Rivera -
Rob Stewart -
Steven Watanabe