more system package checks #26286
Comments
This comment has been minimized.
This comment has been minimized.
|
Commit: |
|
Branch: u/dimpase/build/t26286 |
This comment has been minimized.
This comment has been minimized.
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
|
Dependencies: #24919 |
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
|
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
|
This comment has been minimized.
This comment has been minimized.
|
comment:10
to be fixed: --- a/m4/ax_check_liblzma.m4
+++ b/m4/ax_check_liblzma.m4
@@ -111,7 +111,7 @@ then
CPPFLAGS="$CPPFLAGS -I${LZMA_HOME}/include"
fi
AC_LANG_PUSH([C])
- AC_CHECK_LIB([lzma], [inflateEnd], [lzma_cv_liblzma=yes], [lzma_cv_liblzma=no])
+ 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])
AC_LANG_POP([C])
if test "$lzma_cv_liblzma" = "yes" && test "$lzma_cv_lzma_h" = "yes"also, if xz test breaks at lzma linking test (but finds its headers), ./configure stops, but it should not... |
|
comment:11
pyzmq's spkg-install needs removal of the line in fact, whenever a package gets spkg-configure.m4, one has to inspect all packages that have it in dependencies for this kind of hardcoded SAGE_LOCAL-only bits in spkg-install etc. |
|
comment:13
Thank you for working on these. I'm excited to try it on Cygwin Regarding your comments about zmq that's an interesting point I hadn't thought about. For something like pyzmq I generally assumed that if a system libzmq were used then likely there would be a system pyzmq as well. But it's true that that doesn't have to be the case. So the question is what to do if some package has as a dependency another package (like libzmq) that was detected at For other packages we might not be so lucky. So we may have to have the |
|
comment:14
Relatedly, I've thought of adding a |
|
comment:15
Replying to @embray:
I'm trying this on Cygwin atm myself - I've managed to get Cygwin running on a Google's cloud Windows 2016 Server. Not sure how close this is to real down to your living room Windows, but still...
This would be OK, sort of, once we can use system's Python, but not now...
As we are at that, what's your take on presence of pkg-config on the system? That's of course brings up the question of OSX, where is there no native pkg-config, but with OSX it seems to me that we really must switch over to using Homebrew there, and stop doing the monolithic mega-thing, which is increasingly difficult, cf. e.g. #26713. |
|
comment:16
Obviously what I'm describing is something like a limited pkg-config. I don't know what the issues are with relying on pkg-config on macos, but I don't think it should be a requirement. There are certainly Python packages that use pkg-config where available to check for dependencies, but there usually end up being fallbacks for mac and windows when pkg-config isn't available. Whether dependency checks are written in Python, or balled up in a |
|
comment:17
Perhaps some of our spkg_configure.m4 scripts could even output their own |
|
comment:18
Replying to @embray:
seems that it's been already something people designed: https://www.gnu.org/software/autoconf-archive/ax_create_pkgconfig_info.html#ax_create_pkgconfig_info |
|
comment:19
There appears to be a bug in build/pkgs/xz/spkg-configure.m4. On my Linux machine I'm getting: It appears that my Then, it looks like there might be some improper nesting or something, or not fully handling every possible failure case, because I shouldn't get that error. |
|
comment:30
The libpng requirement for ZLIB_1.2.9 does appear to be quite strict. I haven't checked, but I'm betting that might be way a zlib package was added to Sage in the first place (or possibly the converse if an older zlib was added to Sage first, and later had bad interactions with the system's libpng). The attached fix works for me but it would be good to get some osx verification. New commits:
|
|
comment:31
Replying to @embray:
this does work on OSX, at least on 10.13 (which does supply zlib 1.2.11) |
|
comment:32
What about bzip2 as another candidate? I don't have time to work on it myself, but it might be easy to add. |
|
comment:33
yes, this should do doable. But, as well, the more I think about it the more it looks to me that we should seriously consider using Homebrew on OSX, with this sort of approach we won't be having library clashes one sometimes sees with Homebrew... |
|
comment:34
Replying to @jhpalmieri:
It's definitely on the list. For the sake of keeping this ticket tractable I don't think I want to add too many additional package checks on this one ticket, but we should definitely have a followup for bz2, and many other packages (ncurses is high on my list because it takes forever to compile on Cygwin for some reason). |
|
comment:35
I'm now trying this branch on OSX/Homebrew, with everything for which we have spkg-configure.m4 coming from either the Xcode or Homebrew; looks promising. |
|
comment:36
OK, here are OSX results of and a very similar one in Looks good enough for a positive OSX review to me. |
|
comment:37
This looks like it's still a problem. The reason you're not seeing it at the prompt is that it has something to do with forked processes, which is what you have (by default) in the doctest runner, but not at the command line. So one of these system libraries (perhaps, I'm just guessing) has broken post-fork() behavior. But I can't see clearly through all that CoreFoundation stuff to know what's going on. There's even something in that stacktrace mentioning |
|
comment:38
Replying to @embray:
this looks like We have seen this stuff already, I just already forgot (as one does with nightmares :-))
|
|
comment:39
Replying to @dimpase:
I thought maybe it had something to do with that too, but I wasn't sure if you re-ran those tests before/after this patch. |
|
Reviewer: Erik Bray, Dima Pasechnik |
|
Author: Erik Bray, Dima Pasechnik |
|
comment:40
OK, indeed, |
|
comment:42
I won't be surprised if the buildbots discover new problems with this but that's what they're there for. Good for me until and unless we hear otherwise. |
|
comment:43
Those OS X failures involving |
|
Changed branch from public/build/t26286 to |
|
comment:45
This broke the build on an OS X Mojave machine. With Mojave, it is possible to have no directory I've opened #26899 for this. |
|
Changed commit from |
|
comment:47
opened #28906 to deal with potentially missing |
This is a follow-up to #24919
Some leftovers from there:
spkg-configure.m4Already on the branch:
Depends on #24919
Depends on #26660
CC: @embray
Component: build
Author: Erik Bray, Dima Pasechnik
Branch:
1d7b12eReviewer: Erik Bray, Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/26286
The text was updated successfully, but these errors were encountered: