Re: How to build compatible packages that use Eigen?

[Dima Kogan]

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 bigger patch is maybe a bit safer against future changes: I can
imagine upstream changing/adding some logic to that big block that would
re-define EIGEN_MALLOC_ALREADY_ALIGNED further down, making the one-line
patch ineffective. In that situation the bigger patch would create a
merge conflict, requiring human review, and the human would hopefully
catch that.

But again, I don't care a whole lot one way or the other

Re: How to build compatible packages that use Eigen?

[Ryo IGARASHI]

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'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 assumptions about the alignment of malloc(), and we
> ALWAYS use eigen's manual allocator to force alignment. This is maybe a
> bit less efficient than the other path, but dynamic allocation shouldn't
> be in any hot code path anyway.
>
> We could also use aligned_alloc() or memalign() instead here, also
> unconditionally. The "unconditional" is the important part: it must be
> consistent with any build flags, otherwise stuff can crash.
>
> Is this reasonable?
>
> Thanks.
>

Best regards,
-- 
Ryo IGARASHI, Ph.D.
rigar...@gmail.com