Re: How to build compatible packages that use Eigen?
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 && ./main
You'll see that it crashes. We have lib.cc:
#include
__attribute__((visibility("default")))
Eigen::MatrixXd* make_array()
{
return new Eigen::MatrixXd(10,20);
}
This is an analogue of some library we would be packaging for Debian.
This would be built with no cpu-specific options, which is what the
Makefile in this demo does.
We also have a main.cc:
#include
Eigen::MatrixXd* make_array();
int main(void)
{
Eigen::MatrixXd* matrix = make_array();
delete matrix;
return 0;
}
This is an analogue of some user program that uses this library. This
isn't going into Debian, and the user wants to use their CPU fully, so
they build with -mavx. This causes Eigen to crash. Because the
allocation and deallocation paths don't work the same.
In this demo no Eigen symbols are exported from lib.so, so it's not a
case of the linker picking the wrong weak symbol, and this cannot be
fixed by symbol versioning or visibility settings or anything.
This isn't a contrived example. I hit this in the real-world with a
package I'm going to upload soon (g2o).
Can anybody see ways to make Eigen work reliably here without patching
away the different paths in aligned_malloc() and aligned_free() ?
https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/Memory.h/#L179
https://sources.debian.org/src/eigen3/3.4.0-4/Eigen/src/Core/util/Memory.h/#L200
I don't see any way to do it currently, and probably we should patch
these out.
There was also a second similar problem I saw earlier, that resulted in
crashes due to inconsistent alignment. I'm going to revisit that
shortly.
Thanks.
eigen-weak-linking-bug.tar.gz
Description: application/gzip
Re: Removing ATLAS?
Hi Steffen, Am Tue, Jul 11, 2023 at 10:02:53AM +0200 schrieb Steffen Möller: > EMMAX is (was) important > https://genome.sph.umich.edu/wiki/EMMAX > > but I admittedly cannot invest into maintaining this or atlas. Sure we can't maintain this. > My suggestion would be to talk back to upstream about transitioning to an > alternative. I have no idea about how difficult this would be to patch > ourselves. Do you have some contact to upstream? The version number is beta-07Mar2010 which is usually a sign that upstream has orphaned this code long ago. If you can reach upstream it would be great if you could ping them somehow. Kind regards Andreas. > Best, > Steffen > > > Gesendet: Montag, 10. Juli 2023 um 22:01 Uhr > > Von: "Andreas Tille" > > An: debian-science@lists.debian.org > > Betreff: Re: Removing ATLAS? > > > > Hi Sébastian, > > > > Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot: > > > > > > So, given all that, I’m inclined to (try to) remove atlas during the > > > trixie development cycle. > > > > Sounds reasonable. > > > > > Any thought on this? > > > > I've checked my responsibility for the dependencies and stumbled about > > emmax > > > > > > emmax.c:10:10: fatal error: clapack.h: No such file or directory > >10 | #include > > | ^~~ > > compilation terminated. > > > > > > and noticed > > > > $ apt-file search clapack.h > > libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h > > ... (other instances are not blas related) > > > > which was probably the reason why I've picked libatlas-base-dev > > originally. I would not say that emmax is important and its > > also a not maintained upstream any more. However, I vaguely > > remember that this > >#include > > in some code pieces of Debian Med was the reason to actually > > pick this blas implementation. Any hint how to deal with such > > cases? > > > > Kind regards > > Andreas. > > > > > Checking reverse dependencies... > > > # Broken Depends: > > > ceres-solver: libceres-dev > > > libceres3 > > > colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x] > > > dune-common: libdune-common-dev > > > emmax: emmax > > > ergo: ergo > > > iml: libiml0 > > > nipy: python3-nipy-lib [armel mipsel] > > > psfex: psfex > > > python-escript: python3-escript [armel mipsel] > > > python3-escript-mpi [armel mipsel] > > > qm-dsp: libqm-dsp0 > > > scamp: scamp [amd64 arm64 mips64el ppc64el s390x] > > > scikit-misc: python3-skmisc > > > sight: libsight [amd64] > > > source-extractor: source-extractor > > > xmds2: xmds2 > > > > > > # Broken Build-Depends: > > > ceres-solver: libatlas-base-dev > > > dune-common: libatlas-base-dev > > > emmax: libatlas-base-dev > > >libatlas3-base > > > ergo: libatlas-base-dev > > > ghmm: libatlas-base-dev > > > halide: libatlas-base-dev > > > hpcc: libatlas-base-dev > > > iml: libatlas-base-dev > > > ncl: libatlas3-base > > > odin: libatlas-base-dev > > > opm-material: libatlas-base-dev > > > phast: libatlas-base-dev > > > plink1.9: libatlas-base-dev > > > plink2: libatlas-base-dev > > > psfex: libatlas-base-dev > > > qm-dsp: libatlas-base-dev > > > scamp: libatlas-base-dev > > > scikit-misc: libatlas-base-dev > > > source-extractor: libatlas-base-dev > > > theli: libatlas-base-dev > > > xmds2: libatlas-base-dev > > > > > > Dependency problem found. > > > > > > > > > > > > > -- > > http://fam-tille.de > > > > > > -- http://fam-tille.de
Aw: Re: Removing ATLAS?
Hi all, EMMAX is (was) important https://genome.sph.umich.edu/wiki/EMMAX but I admittedly cannot invest into maintaining this or atlas. My suggestion would be to talk back to upstream about transitioning to an alternative. I have no idea about how difficult this would be to patch ourselves. Best, Steffen > Gesendet: Montag, 10. Juli 2023 um 22:01 Uhr > Von: "Andreas Tille" > An: debian-science@lists.debian.org > Betreff: Re: Removing ATLAS? > > Hi Sébastian, > > Am Sat, Jul 08, 2023 at 10:01:15AM +0200 schrieb Sébastien Villemot: > > > > So, given all that, I’m inclined to (try to) remove atlas during the > > trixie development cycle. > > Sounds reasonable. > > > Any thought on this? > > I've checked my responsibility for the dependencies and stumbled about > emmax > > > emmax.c:10:10: fatal error: clapack.h: No such file or directory >10 | #include > | ^~~ > compilation terminated. > > > and noticed > > $ apt-file search clapack.h > libatlas-base-dev: /usr/include/x86_64-linux-gnu/clapack.h > ... (other instances are not blas related) > > which was probably the reason why I've picked libatlas-base-dev > originally. I would not say that emmax is important and its > also a not maintained upstream any more. However, I vaguely > remember that this >#include > in some code pieces of Debian Med was the reason to actually > pick this blas implementation. Any hint how to deal with such > cases? > > Kind regards > Andreas. > > > Checking reverse dependencies... > > # Broken Depends: > > ceres-solver: libceres-dev > > libceres3 > > colmap: colmap [amd64 arm64 i386 mips64el mipsel ppc64el s390x] > > dune-common: libdune-common-dev > > emmax: emmax > > ergo: ergo > > iml: libiml0 > > nipy: python3-nipy-lib [armel mipsel] > > psfex: psfex > > python-escript: python3-escript [armel mipsel] > > python3-escript-mpi [armel mipsel] > > qm-dsp: libqm-dsp0 > > scamp: scamp [amd64 arm64 mips64el ppc64el s390x] > > scikit-misc: python3-skmisc > > sight: libsight [amd64] > > source-extractor: source-extractor > > xmds2: xmds2 > > > > # Broken Build-Depends: > > ceres-solver: libatlas-base-dev > > dune-common: libatlas-base-dev > > emmax: libatlas-base-dev > >libatlas3-base > > ergo: libatlas-base-dev > > ghmm: libatlas-base-dev > > halide: libatlas-base-dev > > hpcc: libatlas-base-dev > > iml: libatlas-base-dev > > ncl: libatlas3-base > > odin: libatlas-base-dev > > opm-material: libatlas-base-dev > > phast: libatlas-base-dev > > plink1.9: libatlas-base-dev > > plink2: libatlas-base-dev > > psfex: libatlas-base-dev > > qm-dsp: libatlas-base-dev > > scamp: libatlas-base-dev > > scikit-misc: libatlas-base-dev > > source-extractor: libatlas-base-dev > > theli: libatlas-base-dev > > xmds2: libatlas-base-dev > > > > Dependency problem found. > > > > > > > -- > http://fam-tille.de > >
