Thank you Michael, My first guess is that SAGE_SPKG_DEPCHECK([bzip2 liblzma libffi zlib], ...
I think that your guess is correct. IIRC you are building everything (except python, now) from SPKGs. If so and if you are sure that your newly-built python was linked against the sage copies of bzip2, zlib, etc., you can just ignore the DEPCHECK (edit it out). Except that it is impossible for the newly-built python to be linked against the sage copies of those libs, because the hewly-built python needs to be built *before* sage is built, and therefore before those libs have been built. I assume that what you really mean is that a newly-built python is not sufficient. That python must be accompanied by all of those other libraries and then sage must also use the same libraries. One way to do that might be to modify the sage build process so that it builds the spkgs for those libraries and then is forced to halt while a separate python compilation is done in such a way that the python modules which use those libraries can be linked against the versions which were built by the corresponding sage spkgs. The sage build process could perhaps then be restarted to build the rest of sage. Of course that kind of craziness is exactly what I am hoping to avoid and what I do not have to worry about with the current setup. All of that complicated sequencing is currently handled automatically because python3 is built by an spkg which specifies those libraries as dependencies. So the only practical way forward seems to be to install python in some context which also includes all of those other libraries. And somehow sage must be informed to search in that context for all of those libraries. (Running configure --help shows options for saying whether to use the "system versions" of those libraries, but there seems to be no way of providing a path to those options, and there is no hint about how sage will actually decide whether the "system version" of one of those libraries is usable.) I expect that decision process isn't something general, such as checking for the libraries in the same directory where the python3.13 directory is located, or in the lib directory adjacent to the bin directory containing the python3 executable, or a hardwired test which causes sage to use the versions of those libraries provided by Apple,. I would guess that instead there are some hardwired checks for whether homebrew or conda is being used, and maybe a check of /usr/local. If those checks fail I would guess that it just returns an error. Does anyone know how sage decides whether there is a usable "system version" of bzip2 or liblzma? Of course the other complication is that I need to be able to make the sage installation self-contained and relocatable. I have done a lot of experimentation with that over the last few days, which seems to indicate that it is not possible to make a standard "prefix" installation of python relocatable - one has to use a "framework" installation to do that. - Marc -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/a88d22ca-b9a4-485a-9912-d140338d8f7cn%40googlegroups.com.
