On Mon, Apr 21, 2025 at 9:41 PM Marc Culler <marc.cul...@gmail.com> wrote:
> 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.
>
Not really. You should be able to get away with appropriate settings of
PATH, CFLAGS and LDFLAGS (to point at
appropriate locations of the executables, headers, and dylibs.
> 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?
>
$ cat build/pkgs/bzip2/spkg-configure.m4
SAGE_SPKG_CONFIGURE([bzip2], [
AC_CHECK_HEADER(bzlib.h, [
AC_SEARCH_LIBS([BZ2_bzCompress], [bz2], [
AC_PATH_PROG([bzip2_prog], [bzip2])
AS_IF([test x$bzip2_prog = x], [sage_spkg_install_bzip2=yes])
], [sage_spkg_install_bzip2=yes])
], [sage_spkg_install_bzip2=yes])
])
That is, for bzip2, all you need is that your compiler knows where bzlib.h
is, that your linker knows where to find libbz2
(which should have BZ2_bzCompress function)
and that bzip2 executable is in your PATH
$ cat build/pkgs/liblzma/spkg-configure.m4
SAGE_SPKG_CONFIGURE([liblzma], [
SAGE_SPKG_DEPCHECK([xz], [
dnl The library is actually installed by the xz spkg.
AC_CHECK_LIB([lzma], [lzma_raw_decoder], [lzma_cv_liblzma=yes],
[lzma_cv_liblzma=no])
AC_CHECK_HEADER([lzma.h], [lzma_cv_lzma_h=yes], [lzma_cv_lzma_h=no])
if test "$lzma_cv_liblzma" != "yes" -o "$lzma_cv_lzma_h" != "yes"; then
sage_spkg_install_liblzma=yes
fi
])
])
That is, for liblzma first it's checked that xz from the system is
available; then, it's checked that your compiler
finds lzma.h, and your linker finds liblzma (with lzma_raw_decoder
function).
speaking of xz, you need xz in your PATH. However,
please note the comments at the bottom of the following (that is, one
doesn't really need xz)
$ cat build/pkgs/xz/spkg-configure.m4
SAGE_SPKG_CONFIGURE([xz], [
AC_CACHE_CHECK([for xz >= 4.999.0], [ac_cv_path_XZ], [
AC_PATH_PROGS_FEATURE_CHECK([XZ], [xz], [
xz_version=`$ac_path_XZ --version 2>&1 | cut -d' ' -f4 | $SED
-n 1p`
AS_IF([test -n "$xz_version"], [
AX_COMPARE_VERSION([$xz_version], [ge], [4.999.0], [
ac_cv_path_XZ="$ac_path_XZ"
ac_path_XZ_found=:
])
])
])
AS_IF([test -z "$ac_cv_path_XZ"], [sage_spkg_install_xz=yes])
])
], [dnl REQUIRED-CHECK
dnl Issue #30948: All dependencies on "xz" are merely build-time
dependencies
dnl on the xz binary (for unpacking the tarball in
sage_bootstrap.uncompress.tar_file
dnl - when sage-bootstrap-python is so old that it cannot do that
by itself).
dnl Packages that depend on actual xz or liblzma should depend on
the liblzma spkg.
AS_IF(["$SAGE_BOOTSTRAP_PYTHON" -c "import lzma" 2>&
AS_MESSAGE_LOG_FD], [
sage_require_xz=no
])
])
HTH
Dima
> 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
> <https://groups.google.com/d/msgid/sage-devel/a88d22ca-b9a4-485a-9912-d140338d8f7cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAAWYfq28BmeKy56XZJrvp69qNuUPUqA_9NOotYQA-ns38RY%3Dmw%40mail.gmail.com.
