Re: [homebrew] Making upgrades work properly
- From:
- Pierre Riteau
- Date:
- 2010-09-14 @ 11:55
On Mon, Sep 13, 2010 at 1:13 PM, Max Howell <max@methylblue.com> wrote:
> If you:
>
> 1) Install foo which depends on library bar
> 2) Upgrade bar
> 3) `brew cleanup`
>
> foo breaks. This is because it linked to the original bar, because on
> OS X link paths are hardcoded into every binary. Unlike on Linux.
>
> A solution is to manage upgrades and uninstalls more by checkin for
> deps and running install name tool over everything.
>
> I don't like this because Homebrew is meant to be something you can
> manage yourself with command line tools.
>
> So I propose instead we install_name_tool everything on install to
> have paths that point to the symlinks. So instead of output like:
>
> $ otool -L libqjson.dylib
> libqjson.dylib:
> libqjson.0.dylib (compatibility version 0.0.0, current version 0.7.1)
> /usr/local/Cellar/qt/4.6.2/lib/QtCore.framework/Versions/4/QtCore
>
> We get:
>
> $ otool -L libqjson.dylib
> libqjson.dylib:
> libqjson.0.dylib (compatibility version 0.0.0, current version 0.7.1)
> @loader_path/QtCore.framework/Versions/4/QtCore
>
> Using loader_path so that the Homebrew is relocatable (or at least
> more likely to be).
>
> Consequences:
>
> If you `brew unlink` a library, anything that depends on it will
> break. However surely this is what should happen anyway?
>
> Keg-only issues remain. See next mail for a discussion of that.
>
> I've implemented this in a local branch already and push to master
> quite easily. So should I? Did I miss something stupid.
>
> Max
>
I wanted to report this problem for a long time after my gnuplot
binary stopped working when I upgraded libpng. Thank you for looking
at it.
I'm afraid this will not solve all problems: when the library has a
major version bump, it means the software depending on the library
should be recompiled (methods signature can change).
However, your method should be enough for minor bumps.
Re: [homebrew] Making upgrades work properly
- From:
- Max Howell
- Date:
- 2010-09-14 @ 11:59
> I'm afraid this will not solve all problems: when the library has a
> major version bump, it means the software depending on the library
> should be recompiled (methods signature can change).
> However, your method should be enough for minor bumps.
This rarely happens. And all good software should link against the
major version dylib (eg. libfoo.1.dylib and NOT libfoo.2.dylib) so in
theory we don't have to do anything to handle this.
This is why I was saying we should just install all versions of
libraries in common use with the package. They are meant to be able to
be installed in parallel.
Re: [homebrew] Making upgrades work properly
- From:
- Adam Vandenberg
- Date:
- 2010-09-13 @ 16:21
Does running otool like this suggest that we need to cram in that
"LIBTOOL_MAX_NAME" (or whatever it is called) parameter during GCC
linking, to reserve enough space in the header for renaming?
On Mon, Sep 13, 2010 at 4:13 AM, Max Howell <max@methylblue.com> wrote:
> If you:
>
> 1) Install foo which depends on library bar
> 2) Upgrade bar
> 3) `brew cleanup`
>
> foo breaks. This is because it linked to the original bar, because on
> OS X link paths are hardcoded into every binary. Unlike on Linux.
>
> A solution is to manage upgrades and uninstalls more by checkin for
> deps and running install name tool over everything.
>
> I don't like this because Homebrew is meant to be something you can
> manage yourself with command line tools.
>
> So I propose instead we install_name_tool everything on install to
> have paths that point to the symlinks. So instead of output like:
>
> $ otool -L libqjson.dylib
> libqjson.dylib:
> libqjson.0.dylib (compatibility version 0.0.0, current version 0.7.1)
> /usr/local/Cellar/qt/4.6.2/lib/QtCore.framework/Versions/4/QtCore
>
> We get:
>
> $ otool -L libqjson.dylib
> libqjson.dylib:
> libqjson.0.dylib (compatibility version 0.0.0, current version 0.7.1)
> @loader_path/QtCore.framework/Versions/4/QtCore
>
> Using loader_path so that the Homebrew is relocatable (or at least
> more likely to be).
>
> Consequences:
>
> If you `brew unlink` a library, anything that depends on it will
> break. However surely this is what should happen anyway?
>
> Keg-only issues remain. See next mail for a discussion of that.
>
> I've implemented this in a local branch already and push to master
> quite easily. So should I? Did I miss something stupid.
>
> Max
>
Re: [homebrew] Making upgrades work properly
- From:
- Max Howell
- Date:
- 2010-09-13 @ 17:01
I've never had problems with install_name_tool needing more space. But
I'm not using this thing every day or anything.
> Does running otool like this suggest that we need to cram in that
> "LIBTOOL_MAX_NAME" (or whatever it is called) parameter during GCC
> linking, to reserve enough space in the header for renaming?
Re: [homebrew] Making upgrades work properly
- From:
- Mike McQuaid
- Date:
- 2010-09-13 @ 17:28
On 13 Sep 2010, at 18:01, Max Howell wrote:
> I've never had problems with install_name_tool needing more space. But
> I'm not using this thing every day or anything.
I've only really used it in production with Qt and a few other libraries
and I've never needed to supply any arguments manually (unless QMake and
CMake both add them).
--
Cheers,
Mike McQuaid
http://mikemcquaid.com