Re: How to build compatible packages that use Eigen?
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.
Description: https://www.mail-archive.com/debian-science@lists.debian.org/msg13666.html
This patch ensures that Eigen memory allocation/free are implemented the same
way REGARDLESS of build flags. This ensures that an application using Eigen
(possibly indirectly, through libraries) will not crash due to non-identical
build flags
Author: Dima Kogan
diff --git a/Eigen/src/Core/util/Memory.h b/Eigen/src/Core/util/Memory.h
index 875318c..38d55d1 100644
--- a/Eigen/src/Core/util/Memory.h
+++ b/Eigen/src/Core/util/Memory.h
@@ -17,50 +17,13 @@
*** Platform checks for aligned malloc functions ***
*/
#ifndef EIGEN_MEMORY_H
#define EIGEN_MEMORY_H
-#ifndef EIGEN_MALLOC_ALREADY_ALIGNED
-
-// Try to determine automatically if malloc is already aligned.
-
-// On 64-bit systems, glibc's malloc returns 16-byte-aligned pointers, see:
-// http://www.gnu.org/s/libc/manual/html_node/Aligned-Memory-Blocks.html
-// This is true at least since glibc 2.8.
-// This leaves the question how to detect 64-bit. According to this document,
-// http://gcc.fyxm.net/summit/2003/Porting%20to%2064%20bit.pdf
-// page 114, "[The] LP64 model [...] is used by all 64-bit UNIX ports" so it's indeed
-// quite safe, at least within the context of glibc, to equate 64-bit with LP64.
-#if defined(__GLIBC__) && ((__GLIBC__>=2 && __GLIBC_MINOR__ >= 8) || __GLIBC__>2) \
- && defined(__LP64__) && ! defined( __SANITIZE_ADDRESS__ ) && (EIGEN_DEFAULT_ALIGN_BYTES == 16)
- #define EIGEN_GLIBC_MALLOC_ALREADY_ALIGNED 1
-#else
- #define EIGEN_GLIBC_MALLOC_ALREADY_ALIGNED 0
-#endif
-
-// FreeBSD 6 seems to have 16-byte aligned malloc
-// See http://svn.freebsd.org/viewvc/base/stable/6/lib/libc/stdlib/malloc.c?view=markup
-// FreeBSD 7 seems to have 16-byte aligned malloc except on ARM and MIPS architectures
-// See http://svn.freebsd.org/viewvc/base/stable/7/lib/libc/stdlib/malloc.c?view=markup
-#if defined(__FreeBSD__) && !(EIGEN_ARCH_ARM || EIGEN_ARCH_MIPS) && (EIGEN_DEFAULT_ALIGN_BYTES == 16)
- #define EIGEN_FREEBSD_MALLOC_ALREADY_ALIGNED 1
-#else
- #define EIGEN_FREEBSD_MALLOC_ALREADY_ALIGNED 0
-#endif
-
-#if (EIGEN_OS_MAC && (EIGEN_DEFAULT_ALIGN_BYTES == 16)) \
- || (EIGEN_OS_WIN64 && (EIGEN_DEFAULT_ALIGN_BYTES == 16)) \
- || EIGEN_GLIBC_MALLOC_ALREADY_ALIGNED \
- || EIGEN_FREEBSD_MALLOC_ALREADY_ALIGNED
- #define EIGEN_MALLOC_ALREADY_ALIGNED 1
-#else
- #define EIGEN_MALLOC_ALREADY_ALIGNED 0
-#endif
-
-#endif
+#define EIGEN_MALLOC_ALREADY_ALIGNED 0
namespace Eigen {
namespace internal {
EIGEN_DEVICE_FUNC
Re: RFS: updated packages libticcutils, libfolia, uctodata, ucto, timbl, timblserver, mbt, mbtserver, frogdata, frog
Hi Maarten, Le 06/02/2024 à 23:30, Maarten van Gompel a écrit : Hi Pierre, Thanks for your reply. You're welcome! On Tue Feb 6, 2024 at 10:20 PM CET, Pierre Gruet wrote: I see ticcutils (at least) is affected by the ongoing 64-bit time_t transition, it has been NMU-ed to experimental. Yes, it seems this applies to most of the packages. I don't know exactly why (I don't think we expose time_t in our ABI), but I understand the transition applies broadly (better safe than sorry). I am afraid I am not skilled enough to answer :( Would you mind waiting for the end of this process (also acknowledging the related uploads and new binary package names in your packaging at that time) so that we don't interfere with the transition? That's okay, though I thought maybe releasing these new packages might make the transitional packages obsolete and reduce some complexity. There is at least one dependency of all these packages that is waiting in experimental for its own transition. When it has started, these packages can be uploaded to unstable in a somehow organized process. I trust it is better to wait in order to be sure we don't interfere with anything :) By the way, I noticed dimbl is a reverse dependency of ticcutils and timbl, and it has not been updated for ages. Could you also include it in your series of upcoming uploads please? Please do reach out again after the transition of the packages has finished and we will proceed :) Regards, Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Update for python-quantities
Hi, I have updated ‘python-quantities’ with new upstream version 0.15.0 and updated the patch accordingly for your review [0]. Autopkgtest shows PASS (superficial) locally. [0] https://salsa.debian.org/science-team/python-quantities Cheers!
Re: RFS: updated packages libticcutils, libfolia, uctodata, ucto, timbl, timblserver, mbt, mbtserver, frogdata, frog
Hi Pierre, Thanks for your reply. On Tue Feb 6, 2024 at 10:20 PM CET, Pierre Gruet wrote: > I see ticcutils (at least) is affected by the ongoing 64-bit time_t > transition, it has been NMU-ed to experimental. Yes, it seems this applies to most of the packages. I don't know exactly why (I don't think we expose time_t in our ABI), but I understand the transition applies broadly (better safe than sorry). > Would you mind waiting > for the end of this process (also acknowledging the related uploads and > new binary package names in your packaging at that time) so that we > don't interfere with the transition? That's okay, though I thought maybe releasing these new packages might make the transitional packages obsolete and reduce some complexity. Regards, -- Maarten van Gompel (proycon) web: https://proycon.anaproy.nl gpg: 0x39FE11201A31555C signature.asc Description: PGP signature
Re: RFS: updated packages libticcutils, libfolia, uctodata, ucto, timbl, timblserver, mbt, mbtserver, frogdata, frog
Hi Maarten, Le 02/02/2024 à 14:47, Maarten van Gompel a écrit : Hi, After a hiatus of too many years, I finally updated the debian packages for our software stack to their latest upstream releases: * https://salsa.debian.org/science-team/libticcutils * https://salsa.debian.org/science-team/libfolia * https://salsa.debian.org/science-team/uctodata * https://salsa.debian.org/science-team/ucto * https://salsa.debian.org/science-team/timbl * https://salsa.debian.org/science-team/timblserver * https://salsa.debian.org/science-team/mbt * https://salsa.debian.org/science-team/mbtserver * https://salsa.debian.org/science-team/frogdata * https://salsa.debian.org/science-team/frog The packages should be built in the above order because of intra-dependencies. As it's been a while, I hope I did everything right. Of course I verified the packages work, so things look promising. I did get some minor lintian warnings like: W: frog source: superfluous-file-pattern m4/pkg.m4 [debian/copyright:48] ... because of an earlier m4/* pattern. But judging by the documentation that should be allowed? One other relevant issue (for Frog) is the time64 transition ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061954) , which I hope I handled okay now. I'm hoping someone is willing to upload these packages? (and add the debian/vX.XX git tag) Kind Regards, Thanks for all this work! I see ticcutils (at least) is affected by the ongoing 64-bit time_t transition, it has been NMU-ed to experimental. Would you mind waiting for the end of this process (also acknowledging the related uploads and new binary package names in your packaging at that time) so that we don't interfere with the transition? Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063352: ITP: ngspetsc -- a PETSc interface for NGSolve
Package: wnpp Severity: wishlist Owner: Drew Parsons X-Debbugs-Cc: debian-de...@lists.debian.org, debian-science@lists.debian.org, francesco.balla...@unicatt.it * Package name: ngspetsc Version : git HEAD Upstream Contact: Umberto Zerbinati * URL : https://github.com/NGSolve/ngsPETSc * License : MIT Programming Lang: Python Description : a PETSc interface for NGSolve ngsPETSc is a PETSc interface for NGSolve. It extends the utility of meshes generated by netgen and interfaces with finite element solvers such as dolfinx (fenicsx) as well as NGSolve, Firedrake. To be maintained by the Debian Science team alongside netgen. Co-maintained with Francesco Ballarin.
