ukoethe / vigra

a generic C++ library for image analysis
http://ukoethe.github.io/vigra/
Other
406 stars 191 forks source link

fix osx ci :) #538

Closed k-dominik closed 1 year ago

k-dominik commented 1 year ago

okay - finally it seems to work. I'll summarize the changes here:

fixes #535, closes #523, closes #490

I would also suggest to close #469 - don't think nightly builds are needed now that vigra gets some love.

My comments further down were mostly recording thoughts during debugging, and don't need to be read now anymore :)

k-dominik commented 1 year ago

update:

When I left this, I saw some problems with openexr and vigra picking up different versions of imath, with the suspicion that openexr doesn't correctly specify the version of imath. Then I got sick. In the meantime I saw some activity... and with the latest openexr we are down to 4 test failures... Investigating...

Failing Tests ``` The following tests FAILED: 25 - test_impex (Failed) 30 - test_multiarray (Failed) 45 - test_registration (Failed) 58 - vigranumpytest (BAD_COMMAND) ```

update: funny enough the only overlap with test failures on my silicon mac is vigranumpy....

k-dominik commented 1 year ago

k, the osx tests run through now on my intel macbook air.

k-dominik commented 1 year ago

Hm.. okay that's strange. Locally the tests pass, but in CI, there seems to be an error related to libpng.

The failing tests issue

Application built with libpng-1.4.12 but running with 1.6.39

e.g. here

I tried finding how in the world it picks it up...

My local env is exactly the same, it also picks up the same lib, but on ci it claims version 1.4.12

Truncated cmake output ``` # before cmake otool -L /usr/local/miniconda/envs/vigra/lib/libpng.dylib /usr/local/miniconda/envs/vigra/lib/libpng.dylib: @rpath/libpng16.16.dylib (compatibility version 56.0.0, current version 56.0.0) @rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.13) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) # during cmake ... Found PNG: /usr/local/miniconda/envs/vigra/lib/libpng.dylib (found version "1.4.12") ... Using PNG libraries: /usr/local/miniconda/envs/vigra/lib/libpng.dylib;/usr/local/miniconda/envs/vigra/lib/libz.dylib ... ```
hmaarrfk commented 1 year ago

The OSX Stuff seems pretty Conda-forge specific. Maybe we should report to boost at conda-forge? or ask them for advice.

k-dominik commented 1 year ago

how about pinging @jakirkham first - in the end that's the originator of the change.

For reference, we're discussing the following code snippet:

    IF(APPLE)
        SET(VIGRANUMPY_LIBRARIES ${Boost_PYTHON_LIBRARY})
    ELSE()
        SET(VIGRANUMPY_LIBRARIES ${Python_LIBRARIES} ${Boost_PYTHON_LIBRARY})
    ENDIF()

linking agains both Python_LIBRARIES and Boost_PYTHON_LIBRARY results in a segfault. Is this a boost.Python bug, or something inherent to using conda to build?

if I have some time I'll try to construct a "clean" example, not using conda and see if that issue persists (before that it would be hard to open an issue with boost/conda-forge/cmake).

hmaarrfk commented 1 year ago

I think this is due to some static linking in Python at conda-forge. I remember having run into this somewhere else.

I'm sorry I "moved" that patch. it makes finding the original author hard. I think it was jakirkham.

k-dominik commented 1 year ago

k - looks good. Tests still pass :)