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

Set PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig for the Crystal programming language #47515

Closed
4 tasks done
ndbroadbent opened this issue Dec 5, 2019 · 7 comments
Closed
4 tasks done
Labels
outdated PR was locked due to age

Comments

@ndbroadbent
Copy link

  • ran brew update and can still reproduce the problem?
  • ran brew doctor, fixed all issues and can still reproduce the problem?
  • ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link?
  • if brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

CC @bcardiff

What you were trying to do (and why)

I was trying to run the crystal binary for the Crystal programming language.

What happened (include command output)

Command output

ld: library not found for -lssl (this usually means you need to install the development package for libssl)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: execution of command failed with code: 1: cc "${@}" -o '/Users/ndbroadbent/.cache/crystal/crystal-run-eval.tmp' -rdynamic -lz command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libssl || printf %s '-lssl -lcrypto' command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libcrypto || printf %s '-lcrypto' -lpcre /usr/local/Cellar/crystal/0.31.1/embedded/lib/libgc.a -lpthread /usr/local/Cellar/crystal/0.31.1/src/ext/libcrystal.a -levent -liconv -ldl -L/usr/local/Cellar/crystal/0.31.1/embedded/lib -L/usr/lib -L/usr/local/lib

What you expected to happen

I expected to be able to use crystal without needing to manually set the PKG_CONFIG_PATH for OpenSSL.

Step-by-step reproduction instructions (by running brew install commands)

brew install crystal
crystal eval 'require "http/client"; puts HTTP::Client.get("https://www.google.com/").status_code'

Workaround

From crystal-lang/crystal#6875 (comment):

export PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig

Setting this PKG_CONFIG_PATH variable (e.g. in my ~/.bash_profile) will fix this issue:

export PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig
crystal eval 'require "http/client"; puts HTTP::Client.get("https://www.google.com/").status_code'
# 200

What is the best way to update the crystal brew package so that this manual step is no longer necessary?

References

@Bo98
Copy link
Member

Bo98 commented Dec 5, 2019

This seems expected. OpenSSL is deliberately keg-only as it might conflict with the system OpenSSL. This caveat is documented when you install OpenSSL:

==> Caveats
openssl@1.1 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have openssl@1.1 first in your PATH run:
  echo 'export PATH="/usr/local/opt/openssl@1.1/bin:$PATH"' >> ~/.bash_profile

For compilers to find openssl@1.1 you may need to set:
  export LDFLAGS="-L/usr/local/opt/openssl@1.1/lib"

For pkg-config to find openssl@1.1 you may need to set:
  export PKG_CONFIG_PATH="/usr/local/opt/openssl@1.1/lib/pkgconfig"

However given how Crystal is used in comparison to C etc., I can understand how this behaviour may surprise some in this particular case since you aren't explicitly compiling against OpenSSL directly - it's something internal Crystal does.

Note though that Homebrew doesn't really have any involvement on how it behaves at runtime so has no control of PKG_CONFIG_PATH post-installation. We don't ever modify the user's environment and will never start messing with their .bash_profile. Is there a build-time flag which can be used to bake in a search path into Crystal?

@bcardiff
Copy link
Contributor

bcardiff commented Dec 5, 2019

@Bo98 would it be acceptable to have a wrapper script that will by default set the PKG_CONFIG_PATH before running the compiler itself.

Although Crystal support adding in the compiler compile time a fixed path to look up libraries my understanding is that that will not play nice with customs location of homebrew since the bottle will have an invalid path in this use cases.

Are there any suggestions/preference regarding how a wrapper script may have useful defaults but the user will be able to override them?

  • If the wrapper script always append the openssl path, there is no way to remove it.
  • If the wrapper script only sets it if PKG_CONFIG_PATH is unset I bet it will become somehow useless because there are many use cases that push users to have already a PKG_CONFIG_PATH set.

Are you aware of similar stories in other formulas in order to not reinvent the wheel?

@Bo98
Copy link
Member

Bo98 commented Dec 5, 2019

For example wrapper env scripts, search up write_env_script in this repository. I'm not sure what the general feeling is among maintainers on this approach - it's never been used for PKG_CONFIG_PATH before.

@RX14
Copy link
Contributor

RX14 commented Dec 5, 2019

If macos has a system openssl, why is it not being found by cc -lssl? I wish I had a mac to test what's actually going on here since the root cause seems to have never been actually found.

@Bo98
Copy link
Member

Bo98 commented Dec 5, 2019

I don't know but it's incredibly outdated and you really don't want to use it. 0.9.8 or something.

It also doesn't have a pkg-config file or anything like that.

@RX14
Copy link
Contributor

RX14 commented Dec 5, 2019

Okay, agree this is the best fix then.

@SMillerDev
Copy link
Member

We can discuss this more in a pull request since it's unclear to me what you want to change (and homebrew policy doesn't allow for change requests in issues)

@lock lock bot added the outdated PR was locked due to age label Jan 5, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jan 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated PR was locked due to age
Projects
None yet
Development

No branches or pull requests

5 participants