Hello Drew,
On 11/13/23 14:52, Drew Parsons wrote:
Package: netgen
Followup-For: Bug #1016430
I've prepared netgen 6.2.2305 in experimental. I guess we might as
well close this bug when it gets uploaded to unstable.
Still, I'd also be interested to hear what the motivation was for the
+really6.2.1905 version.
Thank you very much for working on Netgen. (Sorry Tobias for never
getting around to replying to this!)
For convenience, let me quote for explanation my Nov 2020 Patreon post
on this issue, but first TLDR, this was because upstream's use of
architecture-specific assembly causing all builds except amd64 to fail,
and patching that version was too difficult:
The problem, for those who aren't familiar, was that Netgen upstream
made several changes which are specific to the x86_64 (amd64)
architecture in the 6.2.2006 release I had originally uploaded.
Debian builds were only succeeding on amd64 but failing on all the
other architectures: i386, armel, armhf, arm64, mipsel, mips64el,
ppc64el, and s390x.
I was able to fix some of the problems by switching to an older
version (thus the version 6.2.2006+really6.2.1905) but that only
fixed builds on i386 (aka 32-bit x86.)
Problems still remained with the platform-specific usage of
_mm_pause() and __rdtsc(). For __rdtsc(), I was able to resolve it
with a patch to use C++11's std::chrono::steady_clock. For
_mm_pause(), after some research I came up with a patch that uses
architecture-specific assembly that corresponds to x86's _mm_pause()
behavior.
So, since you've gotten it working, there is indeed no reason to hold
off on closing this bug and moving forward.
Thanks,
Kurt
