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-request@lists.boost.org
You can reach the person managing the list at
boost-users-owner@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 <rdebokx1990@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_PQMkjppbOWyixvR5Exw1DCeaUyV9xDfBA@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.maarten@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.Buykx@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:
<HE1PR0602MB3500C8392ECD1A2F7E8C4A2586809@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-bounces@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 <joaquinlopezmunoz@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
********************************************