Package: mlpack Version: 3.4.1-1 I'm forwarding this to the Debian bug tracking system, it will be allocated a number which we should CC on further correspondence about the issue. For posterity etc.
---------- Forwarded message --------- From: Ryan Curtin <r...@ratml.org> Date: Mon, 12 Oct 2020 at 16:19 Subject: Re: [conrads...@gmail.com: mlpack stuck in debian unstable] To: Barak A. Pearlmutter <ba...@pearlmutter.net> Cc: <conrads...@gmail.com> On Mon, Oct 12, 2020 at 04:01:21PM +0100, Barak A. Pearlmutter wrote: > The big issue is compilation issues on various architectures, rather > than the Julia bindings. > Have a look, > > - https://tracker.debian.org/pkg/mlpack > - https://buildd.debian.org/status/package.php?p=mlpack > > Help welcome, absolutely! Awesome, thanks for the links. I can try 'debugging-from-afar' for some of these. Please do feel free to open bugs in the mlpack repository for this, just like the ensmallen repository. I actually had no idea there were problems here. Anyway, quick hits: - armel: maybe add `-latomic` to CMAKE_EXE_LINKER_FLAGS? e.g. add this to the CMake configuration command: "-DCMAKE_EXE_LINKER_FLAGS='-latomic'" - mips64el: related to this bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965247 You could also disable LTO by adding -fno-lto to CMAKE_CXX_FLAGS or CMAKE_LINKER_FLAGS. I'm not sure if that will fix it. - mipsel: "LLVM ERROR: out of memory"; is there anything we can do here? `make -j1`, maybe remove '-pipe' from CMAKE_CXX_FLAGS (if it's set) and set --param ggc-min-heapsize=32768 --param ggc-min-expand=1? That's what I do for underpowered arm7hl builders on Fedora. - alpha: ".got subsegment exceeds 64K". I have no idea what could be wrong here. Can we just disable alpha? There's very little information I can find on this one, other than a suggestion somewhere that the linker table sizes need to be increased, plus what look like a bunch of debian packages where they disabled alpha because of this exact issue. - m68k: is the version of Doxygen here different? A workaround could be to regex `WARN_AS_ERROR[ ]*= YES` to `WARN_AS_ERROR = NO` in `Doxyfile` before the build starts. I'm not sure about the dependency installability problems, but in the worst case, those are all related to Python, so you could for those architectures just disable the Python bindings. > Meantime I'll turn off the Julia bindings. My experience with Debian-packaged Julia actually hasn't been great, but perhaps it's improved over time. I think once Julia is available in stable, perhaps the situation will be better? -- Ryan Curtin | "Get off my lawn!" r...@ratml.org | - Kowalski
