WIP: Fix loader path

[jakirkham]

Fixes #1

Not sure if this actually fixes the issue or not as I haven't tested it yet. However, this is a neat trick that may improve the situation.

Basically we delete the existing LC_RPATH. Then we change all the existing linked library paths to point to absolute paths with the full PREFIX. At this point, conda-build picks up on the absolute paths and fixes them. It also goes back and adds the correct LC_RPATH. The last step would not be possible if we hadn't already removed it.

This only has an effect on local builds of this recipe and not on conda-forge builds. To ensure we don't mess up a user's gcc package (as all the libraries we are mucking with are hard linked to the same file in the gcc package), we make fresh copies of all the libraries we mess with. As a result, we can be confident that we have mucked only with our copies of these libraries for build purposes.

In short, we trick conda-build into fixing these libraries for us.

Caveats: As the libgfortran package is just part of gcc on OS X, there is no guarantee that our "fixed" libgfortran will have its files installed or gcc will. It depends on who "wins" (is last) in the install. Similarly this situation may present itself with libgcc. Sadly there is nothing we can really do about this ATM. One will need to specify DYLD_FALLBACK_LIBRARY_PATH for these cases. Note that the latter will be tricky for people building on 10.11. See issue ( conda-forge/staged-recipes#913 ) for some discussion on this last point.

[conda-forge-linter]

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]

Seem to be running into an interesting issue ( conda/conda-build#1184 ) w.r.t. the prefix.

[pelson]

I'd be happy to give this a shot. Is there a way of testing (conveniently) that at least some of the changes continue to work so that we have confidence with future changes?

[jakirkham]

So I see 3 solutions that are immediately obvious to me. Though maybe there are others.

1. Build this and other things with this locally.
2. Come up with some sort of test branch that deploys to the test label.
3. More elegant form of 2 with staged deployments.

I think the right long term solution is 3 to have deployment stages as is being discussed in issue ( conda-forge/conda-forge.github.io#204 ). Though I don't know if getting all the way there will be the right way to test this. Still having staged deployments (so that we don't catastrophically break the system when making releases) feels like the right long term solution. It allows for rapid development which is highly desirable, but minimize damage to those using that stage. Only when we are really comfortable do we release something proper to main.

The less elegant but more easily realized solution is 2. A form of staged deployments that would use a test deployment branch on this feedstock like what is proposed for hdf5 in PR ( conda-forge/hdf5-feedstock#32 ). Maybe we can iron out how that one will work and try applying it here.

Edit: Needless to say 1 isn't exactly convenient. So maybe we should work on one of the other two.

[jakirkham]

Do you have any thoughts on this, @mingwandroid?

[mingwandroid]

The root of all these problems is that libgcc_ext.10.4.dylib and libgcc_ext.10.5.dylib are dylib stubs and install_name_tool refuses to process them (for no good reason that I know of). conda/conda-build#140

To fix this, since I was pushed for time, I simply added these files to gcc-4.8.5-8/info/has_prefix and repackaged them (rather than rebuilding from scratch .. I don't want to spend any more time on these GCC builds since I'd rather spend that time working on the new ones instead):

/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac binary lib/libgcc_ext.10.4.dylib
/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac binary lib/libgcc_ext.10.5.dylib

You need to rebuild any packages which have .dylib or .so files with LC_LOAD_DYLIB commands where the name begins with /Users/ray.

[msarahan]

@jakirkham can this be closed?