fix osx ci :)

[k-dominik]

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

• test segfaulted on OSX when linking the vigranumpy stuff against python (see here
• failing tests because cmake picked up some framework version of libpng (despite stating otherwise, this seems to be a cmake bug) - resolved by changing the order of package discovery via CMAKE_FIND_FRAMEWORK (and CMAKE_FIND_APPBUNDLE).
• also the ctest wouldn't properly run the shellscripts on osx (added shebang to test scripts)

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]

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]

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

[k-dominik]

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]

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

[k-dominik]

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]

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]

k - looks good. Tests still pass :)