Including a system link library for every test, but only on mingw-w64 builds?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
guessing not since I believe this is a MSVC concept, so I am looking for a
bjam recipe that will allow me to add the link library bcrypt.lib to all of
the tests in a project's test directory if the build is on a windows system
and not using msvc toolset.  Are these any examples out there?

Thanks,

Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
AMDG

On 11/06/2017 01:48 PM, James E. King, III via Boost wrote:
> Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
> guessing not since I believe this is a MSVC concept, so I am looking for a
> bjam recipe that will allow me to add the link library bcrypt.lib to all of
> the tests in a project's test directory if the build is on a windows system
> and not using msvc toolset.  Are these any examples out there?
>

The conditional would look like
<toolset>gcc,<target-os>windows:...

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/6/17 12:48 PM, James E. King, III via Boost wrote:
> Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
> guessing not since I believe this is a MSVC concept, so I am looking for a
> bjam recipe that will allow me to add the link library bcrypt.lib to all of
> the tests in a project's test directory if the build is on a windows system
> and not using msvc toolset.  Are these any examples out there?


autolink isn't an just a msvc concept anymore.  The boost autolink
supports two functions:

a) creating and linking to a library with the correct abi
b) making the symbols to be exported from the library and imported into
the application visible.  This is not supported under the name
"visibility" for gcc and clang compilers.

Problem is that the C++ syntax decoration varies on various
environments.  And this has lead - as you likely know - to problems in
getting the visibility/export/import annotations correct for the
serialization library - and likely others.  It's a mine field.

Robert Ramey

>
> Thanks,
>
> Jim
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
On 11/07/17 00:39, Robert Ramey via Boost wrote:

> On 11/6/17 12:48 PM, James E. King, III via Boost wrote:
>> Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
>> guessing not since I believe this is a MSVC concept, so I am looking
>> for a
>> bjam recipe that will allow me to add the link library bcrypt.lib to
>> all of
>> the tests in a project's test directory if the build is on a windows
>> system
>> and not using msvc toolset.  Are these any examples out there?
>
> autolink isn't an just a msvc concept anymore.  The boost autolink
> supports two functions:
>
> a) creating and linking to a library with the correct abi
> b) making the symbols to be exported from the library and imported into
> the application visible.  This is not supported under the name
> "visibility" for gcc and clang compilers.

Autolinking (and the tool implemented in config/auto_link.hpp) has
nothing to do with exporting or importing symbols. For that you use
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT, which are also provided by
Boost.Config but are not part of the autolinking.

You can see that gcc does not support autolinking from auto_link.hpp:

//
// Only include what follows for known and supported compilers:
//
#if defined(BOOST_MSVC) \
     || defined(__BORLANDC__) \
     || (defined(__MWERKS__) && defined(_WIN32) && (__MWERKS__ >= 0x3000)) \
     || (defined(__ICL) && defined(_MSC_EXTENSIONS) && (_MSC_VER >= 1200))

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
On 11/6/17 1:51 PM, Andrey Semashev via Boost wrote:

> On 11/07/17 00:39, Robert Ramey via Boost wrote:
>> On 11/6/17 12:48 PM, James E. King, III via Boost wrote:
>>> Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
>>> guessing not since I believe this is a MSVC concept, so I am looking
>>> for a
>>> bjam recipe that will allow me to add the link library bcrypt.lib to
>>> all of
>>> the tests in a project's test directory if the build is on a windows
>>> system
>>> and not using msvc toolset.  Are these any examples out there?
>>
>> autolink isn't an just a msvc concept anymore.  The boost autolink
>> supports two functions:
>>
>> a) creating and linking to a library with the correct abi
>> b) making the symbols to be exported from the library and imported
>> into the application visible.  This is not supported under the name
>> "visibility" for gcc and clang compilers.
>
> Autolinking (and the tool implemented in config/auto_link.hpp) has
> nothing to do with exporting or importing symbols. For that you use
> BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT, which are also provided by
> Boost.Config but are not part of the autolinking.
>
> You can see that gcc does not support autolinking from auto_link.hpp:

OK

But the msvc autolinking decorations resolve to
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT.  So msvc "automatically"
implements limited visibililty.  This can and I think is meant to
support generated limited visibility with gcc/clang compilers while
supporting autolinking as well for msvc.

It has gotten slightly sticky with mingw which is a "windows" platform
with DLLS, autolinking etc but a gcc compiler.

If one aims to make a portable library which supports limited visibility
with gcc/clang and autolinking with msvc, you'll be dealing with all of
this at once.

One solution is two avoid using limited visibility for gcc/clang and
your life will be easier.  But if your library is large - like the
serialization library, users will complain about the size of shared
libraries.


Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
On 11/07/17 02:25, Robert Ramey via Boost wrote:

> On 11/6/17 1:51 PM, Andrey Semashev via Boost wrote:
>>
>> Autolinking (and the tool implemented in config/auto_link.hpp) has
>> nothing to do with exporting or importing symbols. For that you use
>> BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT, which are also provided by
>> Boost.Config but are not part of the autolinking.
>>
>> You can see that gcc does not support autolinking from auto_link.hpp:
>
> OK
>
> But the msvc autolinking decorations resolve to
> BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT.

It works backwards.

1. You mark the symbols you want with
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT, depending on whether your
library is built or used.

2. You define a few config macros and #include
<boost/config/auto_link.hpp>. This is a no-op when your library is built
and expands into pragmas to bring your library to the linker when your
library is used. It does not decorate any symbols.

The two steps are independent; you can do one thing without the other.
Just doing #2 won't do #1 for you and vice versa. You do both steps on
all platforms, but #2 is a no-op everywhere but Windows.

> So msvc "automatically"
> implements limited visibililty.  This can and I think is meant to
> support generated limited visibility with gcc/clang compilers while
> supporting autolinking as well for msvc.

MSVC (or rather, Windows) doesn't support visibility because Windows
runtime linker works differently. I'm not sure if gcc's
__attribute__((visibility)) does anything on Windows, probably nothing.

BOOST_SYMBOL_* macros expand to dllexport/dllimport attributes, which is
something different than visibility. Instead of just making the symbol
visible, it alters its mangling; dllexport also generates a stub for the
symbol in the .lib file that is to be consumed by the users of the .dll.

> If one aims to make a portable library which supports limited visibility
> with gcc/clang and autolinking with msvc, you'll be dealing with all of
> this at once.
>
> One solution is two avoid using limited visibility for gcc/clang and
> your life will be easier.  But if your library is large - like the
> serialization library, users will complain about the size of shared
> libraries.

Using hidden visibility is fine and even encouraged. Since Windows
doesn't support visibility but doesn't export any symbols by default,
the behavior there is actually quite close to hidden visibility. But you
have to be careful to mark certain symbols visible with
BOOST_SYMBOL_VISIBLE, like exception types and the types you plan to use
with typeid/dynamic_cast. This is a no-op on Windows and is easy to
forget if you don't test on other platforms.
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT will still have the intended
effect on all systems, Windows and not.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 7/11/2017 10:51, Andrey Semashev wrote:
> You can see that gcc does not support autolinking from auto_link.hpp:

I think it's an ecosystem issue.

One of the main reasons why MSVC can support autolinking is that by
default the linker does not care what order libraries are linked in --
anything in loose objects always wins over libraries, and it will search
all the libraries for remaining unresolved symbols and error out if it
finds symbols duplicated in multiple libraries.  Consequently Windows
libraries generally rely on callback APIs and the like, not weak
symbols.  (Although there are ways to use weak symbols, they're less
popular.)

Meanwhile ELF binaries and linkers have traditionally had a specified
linking order, where a symbol will only resolve to a library listed
after it.  This doesn't lend itself well to auto-linking, since it's
harder to control the order.  They also make no distinction between
individual .o files and a .a file containing .o files.

(GCC does have a mode where it can link libraries in any order, similar
to MSVC, but it's only recommended to resolve mutual dependencies and
not for general use, since ELF libraries are more likely to rely on the
existence of weak symbols to do link-time overrides, which in turn only
works properly with ordered linking.)

It's just one of those things with the weight of tradition behind it,
and isn't likely to be "fixed" any time soon.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
On 11/07/17 04:39, Gavin Lambert via Boost wrote:

> On 7/11/2017 10:51, Andrey Semashev wrote:
>> You can see that gcc does not support autolinking from auto_link.hpp:
>
> I think it's an ecosystem issue.
>
> One of the main reasons why MSVC can support autolinking is that by
> default the linker does not care what order libraries are linked in --
> anything in loose objects always wins over libraries, and it will search
> all the libraries for remaining unresolved symbols and error out if it
> finds symbols duplicated in multiple libraries.  Consequently Windows
> libraries generally rely on callback APIs and the like, not weak
> symbols.  (Although there are ways to use weak symbols, they're less
> popular.)
>
> Meanwhile ELF binaries and linkers have traditionally had a specified
> linking order, where a symbol will only resolve to a library listed
> after it.  This doesn't lend itself well to auto-linking, since it's
> harder to control the order.  They also make no distinction between
> individual .o files and a .a file containing .o files.
>
> (GCC does have a mode where it can link libraries in any order, similar
> to MSVC, but it's only recommended to resolve mutual dependencies and
> not for general use, since ELF libraries are more likely to rely on the
> existence of weak symbols to do link-time overrides, which in turn only
> works properly with ordered linking.)
>
> It's just one of those things with the weight of tradition behind it,
> and isn't likely to be "fixed" any time soon.

Exactly, only I tend to think that the ecosystem was built around the
different design of shared libraries on Windows rather than the other
way around.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Nov 6, 2017 at 4:03 PM, Steven Watanabe via Boost <
[hidden email]> wrote:

> AMDG
>
> On 11/06/2017 01:48 PM, James E. King, III via Boost wrote:
> > Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
> > guessing not since I believe this is a MSVC concept, so I am looking for
> a
> > bjam recipe that will allow me to add the link library bcrypt.lib to all
> of
> > the tests in a project's test directory if the build is on a windows
> system
> > and not using msvc toolset.  Are these any examples out there?
> >
>
> The conditional would look like
> <toolset>gcc,<target-os>windows:...
>

That allows me to make a conditional <cxxflags> or <link> or whatnot, by
appending it to the end.

How do I apply this to control whether a bjam directive (like [ run ... ])
is executed on a given platform?
I am trying to use this technique to run the same test multiple times with
different macros to engage
mocking so that error paths can be tested, and some combinations of macros
are superfluous on some
platforms.  I would also like to use this technique to prevent a short
benchmark from building and running
in the debug variant.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Including a system link library for every test, but only on mingw-w64 builds?

Boost - Dev mailing list
James E. King, III wrote:
> On Mon, Nov 6, 2017 at 4:03 PM, Steven Watanabe via Boost
> <[hidden email]> wrote:

> > The conditional would look like <toolset>gcc,<target-os>windows:...
>
>
> That allows me to make a conditional <cxxflags> or <link> or whatnot, by
> appending it to the end.
>
> How do I apply this to control whether a bjam directive (like [ run ... ])
> is executed on a given platform?

You can use `<build>no` to disable something.

> I would also like to use this technique to prevent a short benchmark from
> building and running in the debug variant.

In this case, for instance, `<variant>debug:<build>no`.

(This is how `[ requires cxx11_constexpr ]` (for example) works; it returns
either `<build>no` or nothing.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost