Re: Boost-users Digest, Vol 5456, Issue 1

From: philippe DALET (philippe.dalet_at_[hidden])
Date: 2021-02-23 22:44:30

Hi,

I have built some binaries for boost and python
https://sourceforge.net/projects/pcpu/files/Boost/
boost 1.71 python3.7&numpy3.7 for ubuntu 20.04 64 bits
boost 1.75 python3.789&numpy3.789 for visual studio 2019 mscv14.2 - win10
Ph.DALET

Le mar. 23 févr. 2021 à 11:03, <boost-users-request_at_[hidden]> a
écrit :

> Send Boost-users mailing list submissions to
>         boost-users_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.boost.org/mailman/listinfo.cgi/boost-users
> or, via email, send a message with subject or body 'help' to
>         boost-users-request_at_[hidden]
>
> You can reach the person managing the list at
>         boost-users-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Boost-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Boost cannot find numpy37 on Dockerized Ubuntu 20.04
>       (Roy de Bokx)
>    2. Re: flyweights, nested flyweights and shared libraries
>       (Andreas Buykx)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Feb 2021 15:49:11 +0100
> From: Roy de Bokx <rdebokx1990_at_[hidden]>
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] Boost cannot find numpy37 on Dockerized
>         Ubuntu 20.04
> Message-ID:
>         <
> CAFLoxwXy8_an1jZh_PQMkjppbOWyixvR5Exw1DCeaUyV9xDfBA_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> Op vr 19 feb. 2021 om 22:05 schreef Nathan Ernst via Boost-users <
> boost-users_at_[hidden]>:
>
> > The missing symbols you quoted come from python itself. It looks like
> > you're missing a "-lpython" linker flag.
> >
> Thanks! That definitely put me on the right track. Eventually I got it
> working using the "-lpython3.6m" flag, since I found that the Python3.6 .so
> file was situated at /usr/lib/x86_64-linux-gnu/libpython3.6m.so
>  Many thanks, this is much appreciated! I've pasted the full Dockerfile in
> https://github.com/boostorg/boost/issues/462, in case anyone is
> interested.
>
> >
> > Regards,
> > Nathan
> >
> > On Fri, Feb 19, 2021, 4:47 AM Roy de Bokx via Boost-users <
> > boost-users_at_[hidden]> wrote:
> >
> >>
> >>
> >> Op wo 17 feb. 2021 om 20:30 schreef Anonymous Maarten <
> >> anonymous.maarten_at_[hidden]>:
> >>
> >>> Thanks for your answer Maarten!
> >>>> Please bare with me as I'm a little new to this. Is there some way I
> >>>> can change the interpreter that is used for installing boost? Or do
> you
> >>>> think that adapting the --prefix flag may also work?
> >>>>
> >>>
> >>> When using the pre-built boost packages of a linux distribution
> >>> (ubuntu), you're generally stuck with the versions/options that its
> >>> packagers have chosen.
> >>> A distribution freezes versions to make a more robust experience.
> >>>
> >>> Adding a `--prefix` will not help because, first of all, it's not a
> >>> valid gcc option, and second, ubuntu 18.04 does not provide a
> >>> libboost-python-py37 shared/static library.
> >>> Do you really need python 3.7? Doesn't 3.6 suffice?
> >>>
> >>
> >> Thanks! This helped me understanding the issue a bit further. I think
> 3.6
> >> should suffice indeed, so I tried using 3.6 by removing the 3.7
> >> installation from the Dockerfile and using the -lboost_numpy3 flag
> instead.
> >> It seems I ran into some linking issue after this. It was able to find
> >> the right numpy3.so and libboost_python3-py36.so, but I'm getting a lot
> of
> >> errors like these:
> >>
> >> //usr/lib/x86_64-linux-gnu/libboost_numpy3.so: undefined reference to
> >> `PyExc_ValueError'
> >>
> >> //usr/lib/x86_64-linux-gnu/libboost_python3-py36.so.1.65.1: undefined
> >> reference to `PyLong_AsLong'
> >>
> >> //usr/lib/x86_64-linux-gnu/libboost_python3-py36.so.1.65.1: undefined
> >> reference to `PyNumber_InPlaceFloorDivide'
> >>
> >> //usr/lib/x86_64-linux-gnu/libboost_python3-py36.so.1.65.1: undefined
> >> reference to `PyBool_Type'
> >> etc...
> >>
> >> I've pasted the full docker file and logs in
> >> https://github.com/boostorg/boost/issues/462
> >> Thanks again for any help.
> >>
> >>>
> >>> If you really want to use Boost.Python + python 3.7, you can do 2
> things:
> >>> - stay on ubuntu bionic and build boost yourself (or use an alternative
> >>> c/c++ package manager, e.g. [conan](https://conan.io/) has a [boost
> >>> package](https://conan.io/center/boost))
> >>> - more to a more recent ubuntu release. e.g. ubuntu 20.10 has python
> >>> 3.8:
> >>>
> https://packages.ubuntu.com/groovy/amd64/libboost-python1.71-dev/filelist
> >>>
> >> I've also given 20.10 a try, however I ran into the same linking issues
> >> as mentioned above.
> >>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >> Boost-users mailing list
> >> Boost-users_at_[hidden]
> >> https://lists.boost.org/mailman/listinfo.cgi/boost-users
> >>
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> > https://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Feb 2021 09:59:50 +0000
> From: Andreas Buykx <A.Buykx_at_[hidden]>
> To: "boost-users_at_[hidden]" <boost-users_at_[hidden]>
> Subject: Re: [Boost-users] flyweights, nested flyweights and shared
>         libraries
> Message-ID:
>         <
> HE1PR0602MB3500C8392ECD1A2F7E8C4A2586809_at_HE1PR0602MB3500.eurprd06.prod.outlo
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello Joaqu?n,
>
> Thanks for your help. This morning it dawned on me what you meant with the
> remark about the destruction: I implemented all constructors as explicit
> default in the cpp-file but I had forgotten to do that for the destructor.
> Now everything runs like a breeze, except for one situation where I get an
> assertion:
>
> boost::flyweights::detail::recursive_lightweight_mutex::scoped_lock::scoped_lock(boost::flyweights::detail::recursive_lightweight_mutex
> &): Assertion `pthread_mutex_lock(&m_)==0' failed.
>
> This exception is raised while destroying the nested flyweight wrapper
> from the nesting flyweight wrapper, but only in one of my many test cases
> where these flyweight wrappers are used. Do you have any suggestions on why
> this might happen?
>
>
> Regarding the use of intermodule_holder I mistook a link error for a
> compile error:
>
> /opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/ld:
> Test/appz/ppf/unittests/model/results/CMakeFiles/unittest_PpfModelResultUnitTest.dir/PpfResultCaseUnitTest.cpp.o:
> undefined reference to symbol 'shm_unlink@@GLIBC_2.2.5'
> //lib64/librt.so.1: error adding symbols: DSO missing from command line
>
> All that aside: you mention that getting intermodule_holder is the
> preferred option, but given that it's "... intermodule_holder is
> considerably more onerous than static_holder in terms of compilation times
> and introduces a non-negligible overhead at program start-up ...", isn't
> wrapping the flyweight in an accessor class (especially your templated
> construct) at least as good an option that maybe deserves a mention in the
> documentation?
>
> Thanks again for your help,
> Andreas
>
> From: Boost-users <boost-users-bounces_at_[hidden]> On Behalf Of
> Joaquin M L?pez Mu?oz via Boost-users
> Sent: zaterdag 20 februari 2021 16:22
> To: boost-users_at_[hidden]
> Cc: Joaquin M L?pez Mu?oz <joaquinlopezmunoz_at_[hidden]>
> Subject: Re: [Boost-users] flyweights, nested flyweights and shared
> libraries
>
> El 19/02/2021 a las 16:54, Andreas Buykx via Boost-users escribi?:
> I want to use boost::flyweight to capture some structures containing const
> data.
>
> The documentation states that if flyweights are exported across shared
> library boundaries
> that the intermodule holder should be used.
> Since my flyweights are all created in the same shared library I would
> prefer to use the
> static holder but I keep getting crashes.
>
> It is not only necessary that all flyweights are created in the same DLL:
> they must also
> be destroyed within that DLL. I guess that's the problem you're
> experiencing.
> I tried the intermodule holder but I'm having trouble compiling my sources
> with that.
> Can you provide more info on the kind of problems you're running into?
> intermodule_holder tests successfully in Linux, Mac and Windows platforms.
> I presume it is Windows you use.
>
>  So my thinking was to wrap all flyweight types in accessor classes which
> are exposed instead, and the
> accessor classes create the flyweights within the same shared library to
> store the data.
> Would that be a valid approach?
>
> I think your first option should be to make intermodule_holder work. That
> said, the
> approach you outline below in your mail looks OK, as the lifetime of
> flyweight objects
> is handled entirely within DLL-specific exported functions. A simpler
> approach would be
> to define a wrapper around boost::flyweight:
>
> // template class to be instantiated *only*
> // within your exporting DLL
> template<typename T>
> struct DLLEXPORT dll_flyweight:boost::flyweight<T>
> {
>   using boost::flyweight<T>::flyweight;
> };
>
> Also, is it possible to have nested flyweights (when they are wrapped by
> accessor classes)?
> And would that cause any additional problems in the above scenario?
>
> I don't see any problem with that.
>
> Best,
>
> Joaqu?n M L?pez Mu?oz
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> ------------------------------
>
> End of Boost-users Digest, Vol 5456, Issue 1
> ********************************************
>