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

Installation instructions for different versions of Mac #90

Open
mockdeep opened this Issue Aug 7, 2014 · 8 comments

Comments

Projects
None yet
4 participants
@mockdeep

mockdeep commented Aug 7, 2014

I spent 2 hours last night trying to help someone get ImageMagick and RMagick installed and running on his Mac (OSX 10.9.4), and still failed. We spent a lot of time playing around with the solutions here and eventually gave up. It would help to have clear instructions in the README for setting up the latest compatible version of ImageMagick on different versions of Mac, since every time I try to help someone get set up I inevitably spend hours googling around and trying one random solution after another, and every version of MacOS seems to introduce its own issues.

@ioquatix

This comment has been minimized.

Show comment
Hide comment
@ioquatix

ioquatix Aug 7, 2014

It should be super easy to do this - i.e. it should just work. The fact that it isn't is a bug.

Are you using MacPorts or Homebrew?

ioquatix commented Aug 7, 2014

It should be super easy to do this - i.e. it should just work. The fact that it isn't is a bug.

Are you using MacPorts or Homebrew?

@mockdeep

This comment has been minimized.

Show comment
Hide comment
@mockdeep

mockdeep Aug 7, 2014

We were using homebrew. As far as I can tell, it doesn't have any support for specific versions of applications, so much as for a limited set of versions. In this case the only other version of ImageMagick seems to be too old.

mockdeep commented Aug 7, 2014

We were using homebrew. As far as I can tell, it doesn't have any support for specific versions of applications, so much as for a limited set of versions. In this case the only other version of ImageMagick seems to be too old.

@ioquatix

This comment has been minimized.

Show comment
Hide comment
@ioquatix

ioquatix Aug 7, 2014

I would recommend using MacPorts, I've found it to be much more stable and tested in general than Homebrew. If it works with MacPorts, we can recommend that to start with and then contact the Homebrew team to let them know something is wrong with their version of ImageMagick.

ioquatix commented Aug 7, 2014

I would recommend using MacPorts, I've found it to be much more stable and tested in general than Homebrew. If it works with MacPorts, we can recommend that to start with and then contact the Homebrew team to let them know something is wrong with their version of ImageMagick.

@mockdeep

This comment has been minimized.

Show comment
Hide comment
@mockdeep

mockdeep Aug 7, 2014

Oh, I was under the impression that Homebrew was the standard for installing packages on Macs these days. Unfortunately, I'm not in touch with the fellow I was helping out. But some readme instructions might be helpful for the future. Does MacPorts have support for older versions?

mockdeep commented Aug 7, 2014

Oh, I was under the impression that Homebrew was the standard for installing packages on Macs these days. Unfortunately, I'm not in touch with the fellow I was helping out. But some readme instructions might be helpful for the future. Does MacPorts have support for older versions?

@ioquatix

This comment has been minimized.

Show comment
Hide comment
@ioquatix

ioquatix Aug 7, 2014

Homebrew is great in certain situations, because users can submit updates, whereas the MacPorts process is a lot slower to accept changes, but usually this means that things are tested a bit better and a bit more stable (IMHO).

However, I think your right, Homebrew is getting a lot of traction, but I think simply by design it will never be as stable as MacPorts. I've personally used both, and previously to that, fink. I'm very happy with MacPorts and I haven't had any major issues with it.

N.B. stable isn't always a good design criteria - it depends on the requirements.

ioquatix commented Aug 7, 2014

Homebrew is great in certain situations, because users can submit updates, whereas the MacPorts process is a lot slower to accept changes, but usually this means that things are tested a bit better and a bit more stable (IMHO).

However, I think your right, Homebrew is getting a lot of traction, but I think simply by design it will never be as stable as MacPorts. I've personally used both, and previously to that, fink. I'm very happy with MacPorts and I haven't had any major issues with it.

N.B. stable isn't always a good design criteria - it depends on the requirements.

@bf4

This comment has been minimized.

Show comment
Hide comment
@bf4

bf4 Aug 25, 2014

Member

@ioquatix I don't know anyone that uses macports less recommends it.

In any case, @mockdeep if you can contribute what you've learned in a PR, that would be great. (If you already have, my apologies, I haven't reviewed all the issues in a bit).

Member

bf4 commented Aug 25, 2014

@ioquatix I don't know anyone that uses macports less recommends it.

In any case, @mockdeep if you can contribute what you've learned in a PR, that would be great. (If you already have, my apologies, I haven't reviewed all the issues in a bit).

@mockdeep

This comment has been minimized.

Show comment
Hide comment
@mockdeep

mockdeep Aug 25, 2014

@bf4 Unfortunately, all we really learned is that none of the existing solutions seem to work.

mockdeep commented Aug 25, 2014

@bf4 Unfortunately, all we really learned is that none of the existing solutions seem to work.

@ioquatix ioquatix added this to the documentation milestone Sep 7, 2014

@fjfish

This comment has been minimized.

Show comment
Hide comment
@fjfish

fjfish Sep 18, 2014

Hi guys

AFAIK (or can tell) XCode now complains when you pass it command line args it doesn't understand. So the fail I've got to is:

/usr/bin/clang -o conftest -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0/x86_64-darwin11.4.2 -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0/ruby/backward -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0 -I.  -I/usr/local/include/ImageMagick  -I/usr/local/include/ImageMagick  conftest.c  -L. -L/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/libksba/lib -L/usr/local/opt/openssl/lib  -L/usr/local/lib -L/usr/local/lib -L/usr/X11/lib -R/usr/X11/lib    -L/usr/local/lib -lMagickCore -llcms -ltiff -lfreetype -ljpeg -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lm -lpthread -lltdl  -lruby.2.0.0  -lpthread -ldl -lobjc "
clang: error: unknown argument: '-R/usr/X11/lib' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

The temporary fix is to tell clang that you don't mind by setting ARCHFLAGS thusly:

ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future

However, when you prepend this to the gem install as recommended on Stack Overflow it's ignored, looks like clang is ingoring the env variable. I've proved that prepending it to the clang command does work.

There are two ways forward

  1. Work out how to pass the ARCHFLAGS var into the build (but as it says this is temporary until Apple decide to get mean)
  2. Stop passing -R/usr/X11/lib when building on Darwin and any other flags I may not yet have been bitten by.

I looked at doing the second one but the indirection employed in creating the list of libraries is too well hidden for me to get my head around.

Hope this helps.

fjfish commented Sep 18, 2014

Hi guys

AFAIK (or can tell) XCode now complains when you pass it command line args it doesn't understand. So the fail I've got to is:

/usr/bin/clang -o conftest -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0/x86_64-darwin11.4.2 -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0/ruby/backward -I/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/include/ruby-2.0.0 -I.  -I/usr/local/include/ImageMagick  -I/usr/local/include/ImageMagick  conftest.c  -L. -L/Users/francisfish/.rvm/rubies/ruby-2.0.0-p247/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/libksba/lib -L/usr/local/opt/openssl/lib  -L/usr/local/lib -L/usr/local/lib -L/usr/X11/lib -R/usr/X11/lib    -L/usr/local/lib -lMagickCore -llcms -ltiff -lfreetype -ljpeg -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lm -lpthread -lltdl  -lruby.2.0.0  -lpthread -ldl -lobjc "
clang: error: unknown argument: '-R/usr/X11/lib' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

The temporary fix is to tell clang that you don't mind by setting ARCHFLAGS thusly:

ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future

However, when you prepend this to the gem install as recommended on Stack Overflow it's ignored, looks like clang is ingoring the env variable. I've proved that prepending it to the clang command does work.

There are two ways forward

  1. Work out how to pass the ARCHFLAGS var into the build (but as it says this is temporary until Apple decide to get mean)
  2. Stop passing -R/usr/X11/lib when building on Darwin and any other flags I may not yet have been bitten by.

I looked at doing the second one but the indirection employed in creating the list of libraries is too well hidden for me to get my head around.

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment