This issue has been dealt with in far more than useful detail already, on https://github.com/PDLPorters/pdl/issues/438 which you opened in May.
pdlcore.c will not be getting reverted to the old structure. I will be happy to incorporate whatever fix short of that makes it work on your broken version of clang. I am fairly sure you can get the latest GCC, and most likely the latest clang as well, on your machine by using Homebrew, and you will probably benefit from also installing Homebrew perl as well. There isn’t yet a recipe for PDL, perhaps you’d like to make one? Best regards, Ed From: William Schmidt<mailto:t.william.schm...@gmail.com> Sent: 27 July 2023 17:17 To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: [Pdl-general] pdlcore.c segmentation fault starting in at least PDL 2.060 I teach an undergraduate college course in Applied Linear Algebra in which I have been using PDL 2.026, as well as R and Python, these three to encourage an awareness that TIMTOWTDI. My students may use Linux or macOS and I personally use High Sierra, 10.13.6. My Perl was 5.30.2 managed with perlbrew. At the end of the last term I decided to upgrade Perl in macOS to 5.36.1 in anticipation of fall classes, and of course, this meant I had to reinstall all my site_perl modules, including PDL. Unfortunately, pdlcore.c segmentation faults using both clang 9.2 and 10.1, the last clang for my version of macOS. Thus began an odyssey to find a way to get the latest PDL installed. I won't detail all the research I did but sufficient to say pdlcore.c underwent significant refactoring after 2.026, specifically a macro expansion of pdl_kludge_copy_* where * maps to a set of C data-object typedefs. Not willing to give up on PDL, and not knowing which version I could safely use in my macOS (without having to upgrade my Mac, a brutal process), I attempted working backward from 2.084 with cpanm PDL@2.0* until I could find one that would compile, to wit: ./.cpanm/work/1690007816.5251/PDL-2.084/Basic/Core/pdlcore.c ./.cpanm/work/1690012699.22291/PDL-2.083/Basic/Core/pdlcore.c ./.cpanm/work/1690013806.25715/PDL-2.082/Basic/Core/pdlcore.c ./.cpanm/work/1690400634.44615/PDL-2.082/Basic/Core/pdlcore.c ./.cpanm/work/1690400709.46037/PDL-2.080/Basic/Core/pdlcore.c ./.cpanm/work/1690400791.48025/PDL-2.076/Basic/Core/pdlcore.c ./.cpanm/work/1690400867.49448/PDL-2.060/Basic/Core/pdlcore.c ./.cpanm/work/1690400949.52220/PDL-2.026/Basic/Core/pdlcore.c I grew tired of this exercise after 2.060 failed, so I went back to my old standby 2.026 and voilà, I again have a usable, but ancient, PDL. It seems obvious that PDL lacks an older macOS platform in testers, otherwise, you would have seen this problem before now. Either that, or leaving older macOS platforms behind is a strategic decision (meaning no disrespect; it is what it is), one that Apple makes all the time to generate more sales. My question is, would it be possible to revert pdlcore.c back to the switch structure used in 2.026? I can think of a number of ways to implement this functionality without resorting to that massive macro expansion, but of course, the callers would also need to change. The alternative is never being able to upgrade PDL beyond 2.026 without the pain of upgrading the HW and the OS. That strikes me as a thumb in the eye to the principles of open-source. Obviously, my use of PDL is rudimentary to what the software is capable of, but what a joy it would be if the developers could find a way to do PDL magic while at the same time being backward compatible to older OSes. At the least, could you add to testers older macOS platforms to refine the build process? Thanks in advance and regards, T. William (perlboy) Schmidt
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
