|Re: [eigen] Eigen in a namespace?|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
It's a terrible hack, and you didn't hear it from me, but if you only use Eigen in a narrow scope, you can fake a namespace by compiling with: -DEigen=
EigenNotToBeLinkedAgainstOn Fri, Apr 6, 2018 at 8:26 AM Mark Borgerding <mark@xxxxxxxxxxxxxx> wrote:Not directly an answer to your question, but a possible resolution (on a
linux or unix-like system anyway) ...
Would it help to build your shared object binaries with
-fvisibility=hidden, so the contained library is not visible outside the
..so? Thus no name collisions.
This might fail if you need the public interface to use the eigen ABI.
On 04/06/2018 09:35 AM, Robert Lupton the Good wrote:
> We've been using eigen (at a lowish level) for quite a time in a large astronomical software project, the LSST, and now have the desire to include a semi-external package; both use eigen.
> For packaging reasons the semi-external package would like to include its own copy of the eigen headers (probably as a sub-module from git), so we potentially have two copies of eigen in the same dynamically-loaded package (both imported into python). We're worried about ABI/API issues as eigen evolves in interesting ways.
> One way to fix this would be to include eigen in different namespaces (maybe anonymous?) in the two packages, but I don't think that this is possible due to eigen's use of the STL. Is there any way to do this now? Or alternatively would it be crazy to restructure the eigen includes to allow us to include a header outside our namespace that pulls in the STL, and then the "real" eigen headers inside our namespace?
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|