search

conda-forge / graphblas-feedstock

A conda-smithy repository for graphblas.
BSD 3-Clause "New" or "Revised" License
2 stars 6 forks source link

Update to 7.3.3 #57

Closed eriknw closed 1 year ago

eriknw commented 1 year ago

Checklist

conda-forge-linter commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

eriknw commented 1 year ago

@conda-forge-admin, please rerender

eriknw commented 1 year ago

@DrTimothyAldenDavis, osx-arm64 build is failing for v7.3.3.beta1 during cmake config. TEST_FOR_STDATOMIC and TEST_FOR_STDATOMIC_WITH_LIBATOMIC are both unhappy:

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=624637&view=logs&j=ced5d8de-8227-5f3f-33a1-45cf1592c45a&t=f7bcb349-6dca-53ba-d88d-1d9963e119ba&l=202

I have no idea how osx-arm64 deals with atomics and whether -latomic needs linked or not.

DrTimothyAldenDavis commented 1 year ago

That's odd. I just got a MacBook M1, and it compiles just fine with clang. It doesn't find OpenMP yet (it does when I use gcc-12 from homebrew). But both clang and gcc-12 pass the stdatomic test. See my log below:

$ make
( cd build && cmake  .. && /Library/Developer/CommandLineTools/usr/bin/make --jobs=8 )
-- Building SuiteSparse:GraphBLAS version: v7.3.3, date: Dec 9, 2022
-- GraphBLAS C API: v2.0, date: Nov 15, 2021
-- Source:        /Users/davis/v733/GraphBLAS 
-- Build:         /Users/davis/v733/GraphBLAS/build 
-- The C compiler identification is AppleClang 14.0.0.14000029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Install rpath:  
-- Build   rpath: /Users/davis/v733/GraphBLAS/build 
-- Build type:    Release 
-- Looking for a Fortran compiler
-- Looking for a Fortran compiler - /opt/homebrew/bin/gfortran
-- The Fortran compiler identification is GNU 12.2.0
-- Checking whether Fortran compiler has -isysroot
-- Checking whether Fortran compiler has -isysroot - yes
-- Checking whether Fortran compiler supports OSX deployment target flag
-- Checking whether Fortran compiler supports OSX deployment target flag - yes
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /opt/homebrew/bin/gfortran - skipped
-- Fortran: GNU
-- CUDA: not enabled
-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
-- Found OpenMP_Fortran: -fopenmp (found version "4.5") 
-- Could NOT find OpenMP (missing: OpenMP_C_FOUND) (found version "4.5")
-- cpu_features (by google.com): enabled 
-- Building dynamic GraphBLAS library
-- Looking for dlfcn.h
-- Looking for dlfcn.h - found
-- cpu_feautures has dlfcn.h
-- Looking for getauxval
-- Looking for getauxval - not found
-- cpu_feautures doesn't have getauxval from sys/auxv.h
-- Performing Test TEST_FOR_STDATOMIC
-- Performing Test TEST_FOR_STDATOMIC - Success
-- ANSI C11 atomics: OK. -latomic not needed
CMake Warning at CMakeLists.txt:385 (message):
  WARNING: OpenMP was not found (or was disabled with NOPENMP).  See the
  GrapBLAS user guide on the consequences of compiling GraphBLAS without
  OpenMP.  GraphBLAS will work but may not be thread-safe, since it relies on
  '#pragma omp flush' to ensure the work performed by one user thread is
  available to another, in GrB_wait.  If OpenMP is not in use, the
  thread-safety of GrB_wait becomes the responsibilty of the user application
  (perhaps through a pthreads construct).  Compiling GraphBLAS without OpenMP
  is not recommended for installation in a package manager (Linux,
  conda-forge, spack, brew, vcpkg, etc).

-- CMAKE C flags:  -O3 -DNDEBUG
-- Skipping the demos in GraphBLAS/Demo
-- Installation will be system-wide (requires 'sudo make install')
-- ------------------------------------------------------------------------
-- SuiteSparse CMAKE report for: graphblas
-- ------------------------------------------------------------------------
-- install in /usr/local: true
-- install in SuiteSparse/lib and SuiteSparse/include: false
-- build type:           Release
-- NSTATIC:              true (do not build static library)
-- use OpenMP:           no 
-- C compiler:           AppleClang 
-- C flags:               -O3 -DNDEBUG
-- C++ compiler:         
-- C++ flags:            
-- C Flags release:      -O3 -DNDEBUG 
-- C++ Flags release:     
-- compile definitions:  
-- ------------------------------------------------------------------------
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/davis/v733/GraphBLAS/build
[  0%] Building C object CMakeFiles/graphblas.dir/Source/GB_AxB_dot3_slice.c.o
...

I'm running on a 2020 MacBook M1 Air, with Ventura 13.0.1. 

$ cc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 $ cmake --version
cmake version 3.25.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).

With this compiler, GraphBLAS v7.3.3 builds just fine, and the demos are OK too.

DrTimothyAldenDavis commented 1 year ago

Unsure if a minor change in my SuiteSparsePolicy.cmake would affect this issue, but I just tagged it as v7.3.3.beta2.

eriknw commented 1 year ago

Unsure if a minor change in my SuiteSparsePolicy.cmake would affect this issue, but I just tagged it as v7.3.3.beta2.

Thanks, trying now.

eriknw commented 1 year ago

Still failing. You can now see the cmake log files here: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=624935&view=logs&jobId=ced5d8de-8227-5f3f-33a1-45cf1592c45a&j=ced5d8de-8227-5f3f-33a1-45cf1592c45a&t=f7bcb349-6dca-53ba-d88d-1d9963e119ba

The build script for Linux and OS X is here: https://github.com/conda-forge/graphblas-feedstock/blob/edaff5a3110b80dc8a6647535ba7e69e436727aa/recipe/build.sh

DrTimothyAldenDavis commented 1 year ago

OK, I didn't expect that to be the problem but it was worth a try. Very odd that I have MacOSX on an Arm64 (M1 Air) and it works fine. The atomic test is here: https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/stable/cmake_modules/SuiteSparseAtomic.cmake

and it compiles and runs a short program:

    #include <stdatomic.h>
    #include <stdint.h>
    int main (void)
    {
        _Atomic uint8_t t8 = 0 ;
        uint8_t e8 = 0, d8 = 0 ;
        atomic_compare_exchange_weak (&t8, &e8, d8) ;
        _Atomic uint16_t t16 = 0 ;
        uint16_t e16 = 0, d16 = 0 ;
        atomic_compare_exchange_weak (&t16, &e16, d16) ;
        _Atomic uint32_t t32 = 0 ;
        uint32_t e32 = 0, d32 = 0 ;
        atomic_compare_exchange_weak (&t32, &e32, d32) ;
        _Atomic uint64_t t64 = 0 ;
        uint64_t e64 = 0, d64 = 0 ;
        atomic_compare_exchange_weak (&t64, &e64, d64) ;
        return (0) ;
    }

which is pure ANSI C11. It just might need -latomic on some platforms. Do you have direct access to that platform?

The logs have a strange error:

Bad CPU type in executable
Return value: FAILED_TO_RUN
Source file was:

Why is it a bad CPU type? It was compiled on the same platform it was run on. That's very strange. It looks like there is some x86 code being included when it shouldn't be. See for examle https://www.technewstoday.com/bad-cpu-type-in-executable/

DrTimothyAldenDavis commented 1 year ago

The log says that an x86 compiler is being used:

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=624935&view=logs&j=ced5d8de-8227-5f3f-33a1-45cf1592c45a&t=f7bcb349-6dca-53ba-d88d-1d9963e119ba&l=1035

That seems suspicious. Also says:

The system is: Darwin - 20.6.0 - x86_64

DrTimothyAldenDavis commented 1 year ago

I see what's happening. It's doing a cross-compilation on an x86 but for an arm64 architecture. The cmake script, SuiteSparseAtomic.cmake, is testing to see if that code compiles and runs without -latomic, and then with -latomic. But the code can't run on the host x86. It has to be run only on the arm64.

The solution would be to just use the "check if compiles" cmake command instead of "check if runs".

DrTimothyAldenDavis commented 1 year ago

Try v7.3.3.beta3: https://github.com/DrTimothyAldenDavis/GraphBLAS/releases/tag/v7.3.3.beta3

eriknw commented 1 year ago

Thanks @DrTimothyAldenDavis! That makes sense. Nice work getting to the bottom of this; it probably would have taken me much, much longer.

I also appreciate having beta releases. I'll try to test them promptly as in this PR.

Trying 7.3.3.beta3 now. It got past cmake checks, so it's probably good 🤞

DrTimothyAldenDavis commented 1 year ago

A few minor updates in v7.3.3.beta4, for 32-bit builds in the SuiteSparse CI: https://github.com/DrTimothyAldenDavis/GraphBLAS/releases/tag/v7.3.3.beta4 .

I think this beta4 will become the stable v7.3.3, and will also appear in v6.0.2.beta1 of SuiteSparse, shortly.

eriknw commented 1 year ago

@conda-forge-admin, please rerender

github-actions[bot] commented 1 year ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/graphblas-feedstock/actions/runs/3726672224.