Skip to content
This repository has been archived by the owner on Nov 27, 2017. It is now read-only.

keg_only dependencies and rpath #494

Closed
schmurfy opened this issue Jul 22, 2015 · 9 comments
Closed

keg_only dependencies and rpath #494

schmurfy opened this issue Jul 22, 2015 · 9 comments
Assignees
Labels

Comments

@schmurfy
Copy link
Contributor

I have an issue for a package with keg_only dependencies, after compilation the executable does not uses the correct library (checked with ldd), after fiddling around it looks like setting the RPATH with patchelf would solve my issue and indeed it does but is it supposed to work out of the box ?

I created a package libcurl but since there is one on the system already I made it keg_only, when compiling the environment seems correct and everything goes well, the issue is only on the final result (on a .so file in this case).

calling patchelf --set-rpath #{(Formula['libcurl'].prefix / "lib")} ... manually in the install method worked.

@schmurfy
Copy link
Contributor Author

I am lost :o
I don't understand what linuxbrew is trying to do but it is playing against me, with my hack above the result is correctly using the keg only libcurl but if I bottle it, uninstall it and reinstall it from the bottle (on the same machine) the library used is now the system curl and and ldd shows that my custom change is gone :(

PS: I am using the libc which came with ubuntu (14.04), not glibc.

@sjackman sjackman self-assigned this Jul 22, 2015
@sjackman
Copy link
Member

Hi, Julien.

brew install curl. It includes libcurl.so.

Linuxbrew does not really support keg_only libraries particularly well. It would need special RPATH support, which it doesn't currently do.

After installing a bottle, Linuxbrew uses patchelf to set the RPATH to $HOMEBREW_PREFIX/lib, which is overwriting you change. This same change is also made after brew bottle. You can use readelf -d to check the value of RPATH in the executable.

Cheers,
Shaun

@schmurfy
Copy link
Contributor Author

thanks this is what I thought.

@schmurfy
Copy link
Contributor Author

What I did is add the linuxbrew lib path to my system library paths so there is no need to specifically point to it and then set the rpath to the locations of keg only libraries. For me it does the job pretty well.

@sjackman
Copy link
Member

Yes, modifying ld.so.conf is a good alternative to RPATH that I haven't yet tried out. It's particularly appealing when using Linuxbrew's glibc.

@schmurfy
Copy link
Contributor Author

even with the existing code why not set the rpath to include the linuxbrew lib folder and all the keg_only library paths ?
I have a working code that does that, if that's something you are interested to merge I can try to make a pull request out of it.

@sjackman
Copy link
Member

So far I've found no use for keg_only formula in Linuxbrew. What are you using them for? I have thought of adding to the RPATH of the executables of a formula the lib folder of all its direct dependencies.

@schmurfy
Copy link
Contributor Author

I am using them in a similar way to homebrew itself, I take a base ubuntu server os and then our applications on it but I always disliked dependending on what comes with ubuntu since I have little to no control on which versions are available. Until now we simply used what came with the os to build upon, this means things like libcurl which are used by many base packages, but now with linuxbrew I should be able to take full control on what we actually use.

Since I have the linuxbrew lib folder in the system path I would end up using any library installed there even with system applications which would probably a lot of things.
I suppose not having the linuxbrew lib path in the system path shield you from that, I have to think why I wanted to add it in the system path I suppose xD

@sjackman
Copy link
Member

If you brew install glibc you can modify the ld.so.conf of Linuxbrew separately from the host system.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants