Ryo IGARASHI writes:
> Looking at your patch, why do you delete all the #ifndef block in the
> first place? Adding just "#define EIGEN_MALLOC_ALREADY_ALIGNED 0" line
> on top of the #ifndef block should do the job.
That would work, but I don't think it makes a huge difference either
way. The
Hi, Dima,
Looking at your patch, why do you delete all the #ifndef block in the
first place?
Adding just "#define EIGEN_MALLOC_ALREADY_ALIGNED 0" line on top of
the #ifndef block
should do the job.
2024年2月7日(水) 16:56 Dima Kogan :
>
> I hit this problem again at work yesterday, so let's fix it.
>
I hit this problem again at work yesterday, so let's fix it.
I'm attaching a patch that can be added to the quilt patch stack in our
libeigen3-dev package. This disables the conditional preprocessor logic
that selects the allocator/deallocator behavior. With this patch we
always make no
Hi Anton. Thanks for replying.
Anton Gladky writes:
> I have been maintaining the Eigen library in Debian for over 12 years,
> and I cannot recall the specific bug ticket related to this topic.
I believe it. I suspect the reason is that you get mystery crashes that
require
Hi Dima,
I have been maintaining the Eigen library in Debian for over 12 years,
and I cannot recall the specific bug ticket related to this topic. However,
it seems that the question you have raised is indeed valid. If patching
Eigen in those two places would help resolve the issue, please
Hi.
Apologies for taking so long to look at this again; I've been busy.
I just looked into it, and my conclusion is that there's no way to
ensure that Eigen won't crash without us patching our package. So we
should patch our package.
I'm attaching a tiny demo program. Extract it and
make &&
Thank you very much for the notes.
The Eigen code I see does everything with the preprocessor. Which is
fine, and doesn't mean that it must crash. For the specific package I'm
building (libg2o) Eigen is the only option, but this sounds like a
generic problem that affects all sorts of packages,
I did something similar. Here is my example:
The linker script is here:
https://salsa.debian.org/science-team/blis/-/blob/master/debian/version_script.lds
This script is used like this:
https://salsa.debian.org/science-team/blis/-/blob/master/debian/patches/libblas-provider.patch
This patch
Don't know how to address this issue but have some relevant comments.
Eigen library does not support run time dispatch for CPU ISAs.
When a package is built upon the amd64 baseline ISA but ran on a modern
CPU, the performance can be very poor.
This is why I build the tensorflow and pytorch
Dima Kogan writes:
> Thanks for replying
No problem.
> Sorry, I'm not familiar-enough with linker scripts. I would pass this to
> the linker when building libg2o.so? Or the end-user would need to use
> this when build-time linking their application? The run-time dynamic
> linker doesn't need
Thanks for replying
u...@debian.org (Aaron M. Ucko) writes:
> It might help to make Eigen's symbols local to your shared library; to
> that end, I think it would work to feed the linker a version script
> reading something along the lines of
>
> {
> local:
> extern "C++" {
>
Dima Kogan writes:
> Now let's say you have a user. They're writing a program that uses both
> libg2o and Eigen. They're writing their own application, not intended to
> go into Debian. So they build with -msse -mavx and all the other fun
> stuff. THEIR weak copies of "aligned_malloc" and
Hi. I'm packaging something that uses Eigen, and I'm running into a
persistent compatibility issue I don't currently know how to solve. Help
appreciated.
Here's the problem. Eigen is a C++ header-only library that's heavy into
templating. So all the functions inside Eigen produce weak symbols,
13 matches
Mail list logo
