Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

patch for setting install_name during install #23

Merged
merged 11 commits into from
Sep 20, 2019

Conversation

minrk
Copy link
Member

@minrk minrk commented Mar 7, 2017

I've submitted this patch upstream. Not sure yet if it will be accepted.

closes #22

@conda-forge-linter
Copy link

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.

@basnijholt
Copy link
Contributor

basnijholt commented Mar 9, 2017

LGTM 👍

@jakirkham @grlee77 what do you think?

@grlee77
Copy link
Member

grlee77 commented Mar 10, 2017

I am not familiar enough with Makefile syntax to judge if this is correct, so I would defer to those with more expertise. Two quick questions:

1.) In short, this patch only modifies behavior on OS X and causes the dynamic libraries to use e.g. *.4.5.dylib rather than the more specific *.4.5.4.dylib to be used as the install_name?

2.) Do we know that SuiteSparse has ABI compatibility between patch versions?

@minrk
Copy link
Member Author

minrk commented Mar 10, 2017

In short, this patch only modifies behavior on OS X and causes the dynamic libraries to use e.g. *.4.5.dylib rather than the more specific *.4.5.4.dylib to be used as the install_name?

According to the variables in the Makefiles, it would be *.4.dylib (major only), but otherwise yes.

Do we know that SuiteSparse has ABI compatibility between patch versions?

We know that suitesparse is setting the compatibility version in its dylibs, so at least the libraries themselves claim compatibility at the major version level. I can't speak for the project in general, but a cursory test of a conda package compiled against 4.5.3 updated manually to load 4.5.4 does work.

@grlee77
Copy link
Member

grlee77 commented Nov 17, 2017

sorry this PR has gone neglected. I think now the build number should be bumped to 202 since the OpenBLAS update bumped it to 201.

@minrk: Is this otherwise good to go? if interested, please add yourself as a maintainer as well

@conda-forge-linter
Copy link

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

I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

@conda-forge-linter
Copy link

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.

@jakirkham
Copy link
Member

jakirkham commented Nov 22, 2017

According to the ABI report for SuiteSparse it appears that at least 4.5 has been stable across patch release. Before that it was static libraries that are fairly old, which makes it hard to say much about its compatibility during that period.

@jakirkham
Copy link
Member

Should we add a file test to ensure that the library name is as expected?

@minrk
Copy link
Member Author

minrk commented Apr 18, 2018

Good idea, I'll add a few calls to otool -L that verify the install name is right.

Aside: it would be cool if conda-build test environments could verify compatibility by running the test env with multiple versions of the built package.

In general, a useful pattern for verifying C libs that their linking config is set up correctly:

  1. conda-build the lib
  2. conda-build a test package that links the lib
  3. install and test the test package against the oldest and newest versions of the lib that its dependency matrix would allow

@minrk
Copy link
Member Author

minrk commented Jun 27, 2018

Sorry for taking so long with the tests. The tests are here now, so we can start getting a suitesparse with correct linking on mac.

isuruf
isuruf previously requested changes Jul 18, 2018
Copy link
Member

@isuruf isuruf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add compilers and remove openblas pinning?

recipe/meta.yaml Outdated
@@ -10,10 +10,13 @@ source:
fn: SuiteSparse-{{ version }}.tar.gz
url: http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-{{ version }}.tar.gz
sha256: de5fb496bdc029e55955e05d918a1862a177805fbbd5b957e8b5ce6632f6c77e
patches:
- install_name.patch

build:
skip: true # [win]
number: 200
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove this line?

recipe/meta.yaml Outdated

build:
skip: true # [win]
number: 200
number: 201
features:
- blas_{{ variant }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add

run_export:
  - {{ pin_subpackage("suitesparse") }}

here?

@conda-forge-linter
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

  • The build section contained an unexpected subsection name. run_export is not a valid subsection name.

@conda-forge-linter
Copy link

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.

@minrk
Copy link
Member Author

minrk commented Jul 19, 2018

This is now also a full conda-build 3 update per @isuruf's request.

@minrk
Copy link
Member Author

minrk commented Aug 16, 2018

Rebased again

@conda-forge-linter
Copy link

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.

I do have some suggestions for making it better though...

For recipe:

  • license_file entry is missing, but is expected.

@conda-forge-linter
Copy link

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.

@minrk minrk dismissed isuruf’s stale review August 28, 2019 09:10

all review addressed

@minrk
Copy link
Member Author

minrk commented Aug 28, 2019

I think this is good to go now (and has been for a year or so). Anything else blocking the merge?

@SylvainCorlay
Copy link
Member

👍

@minrk
Copy link
Member Author

minrk commented Sep 19, 2019

Conflicts resolved again, build number bumped again.

@minrk
Copy link
Member Author

minrk commented Sep 19, 2019

All builds have succeeded. This should be ready to go again. Not sure why osx shows as still queued, since it's succeeded a while ago.

@grlee77 grlee77 merged commit d7cd426 into conda-forge:master Sep 20, 2019
@minrk minrk deleted the install_name branch September 24, 2019 08:33
This was referenced Oct 3, 2019
minrk referenced this pull request in conda-forge/petsc-feedstock Apr 4, 2022
- move pinning to conda_build_config.yaml pin_run_as_build
- add host
- cb3 compiler spec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

investigate setting install name
7 participants