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-requ...@lists.boost.org> a écrit : > Send Boost-users mailing list submissions to > boost-users@lists.boost.org > > 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-requ...@lists.boost.org > > You can reach the person managing the list at > boost-users-ow...@lists.boost.org > > 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 <rdebokx1...@gmail.com> > To: boost-users@lists.boost.org > Subject: Re: [Boost-users] Boost cannot find numpy37 on Dockerized > Ubuntu 20.04 > Message-ID: > < > cafloxwxy8_an1jzh_pqmkjppbowyixvr5exw1dceauyv9xd...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Op vr 19 feb. 2021 om 22:05 schreef Nathan Ernst via Boost-users < > boost-users@lists.boost.org>: > > > 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@lists.boost.org> wrote: > > > >> > >> > >> Op wo 17 feb. 2021 om 20:30 schreef Anonymous Maarten < > >> anonymous.maar...@gmail.com>: > >> > >>> 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@lists.boost.org > >> https://lists.boost.org/mailman/listinfo.cgi/boost-users > >> > > _______________________________________________ > > Boost-users mailing list > > Boost-users@lists.boost.org > > 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.bu...@dianafea.com> > To: "boost-users@lists.boost.org" <boost-users@lists.boost.org> > Subject: Re: [Boost-users] flyweights, nested flyweights and shared > libraries > Message-ID: > < > he1pr0602mb3500c8392ecd1a2f7e8c4a2586...@he1pr0602mb3500.eurprd06.prod.outlook.com > > > > 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-boun...@lists.boost.org> On Behalf Of > Joaquin M L?pez Mu?oz via Boost-users > Sent: zaterdag 20 februari 2021 16:22 > To: boost-users@lists.boost.org > Cc: Joaquin M L?pez Mu?oz <joaquinlopezmu...@gmail.com> > 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@lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users > > > ------------------------------ > > End of Boost-users Digest, Vol 5456, Issue 1 > ******************************************** >
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
