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.

Sign up for GitHub

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

Jump to bottom

/usr/local/lib missing from include paths #556

Closed
rasky opened this issue Jul 19, 2016 · 1 comment
Closed

/usr/local/lib missing from include paths #556

rasky opened this issue Jul 19, 2016 · 1 comment

Comments

@rasky
Copy link
Contributor

rasky commented Jul 19, 2016

We distribute traildb through homebrew. Since traildb is a C library, the formula links the .dylib file into /usr/local/lib, as normal.

Even if the library was released just one month ago, we already got two bug reports of users that couldn't link against it, because /usr/local/lib wasn't in their library search paths. In both cases, running code-select --install fixed it:
traildb/traildb#87 (comment)
traildb/traildb#67 (comment)

I was wondering if brew doctor should report this. I can submit a PR but I wanted to discuss first if this was within the scope of brew doctor or not.
@UniqMartin
Copy link
Contributor

I'm afraid this is outside of the scope of Homebrew. Our build process isn't affected by this because we properly set up library search paths for all declared dependencies, no matter if Homebrew is installed in /usr/local or somewhere else and no matter if the user has only the Command Line Tools (that get installed by xcode-select --install) or Xcode or both.

The reason your users (that presumably only have Xcode installed) are running into that /usr/local/lib is indeed always in the library search path, but if they are building with an Xcode-provided compiler, all search paths are prefixed with the path to the macOS SDK they are building with, e.g. /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk (as a first approximation; there are of course flags and environment variables that influence this). Since your library isn't installed to that directory tree, it isn't found.

The reason why xcode-select --install fixes it for them is that it installs a toolchain independent of Xcode and switches the compiler etc. wrappers in /usr/bin to use that instead. This effectively changes the SDK root to / and thus libraries in /usr/local/lib are automatically picked up.

I'd suggest to modify the instructions for your users to ask them to explicitly include -I and -L flags for your library's include/library paths, making your instructions work independently of the user's exact setup and where Homebrew happens to be installed.

@cbrnr cbrnr mentioned this issue May 3, 2017
Closed
judah added a commit to judah/tensorflow-haskell that referenced this issue May 16, 2017
@judah
Add extra-lib-dirs back into .cabal for Mac builds.
5280a0e 
Also bump the version to 0.1.0.2.

Originally we had `extra-lib-dirs: /usr/local/lib` in `stack.yaml`.
I removed it because it wasn't necessary on my Mac.  However,
it turns out that it is necessary for machines with the default installation
of XCode, which *doesn't* search that path by default.

(On my machine, it wasn't necessary because I had run `xcode-select --install`
which adds that path permanently to your search path.  For more context, see
Homebrew/brew#556.)

I'm adding the setting back to `tensorflow.cabal` as well as `stack.yaml` so
that the Hackage release also contains this fix.  Changing `stack.yaml` is
still necessary in order to fix linkage in the `snappy` package (which
`tensorflow-records` depends on).  Hopefully that will go away once we remove
the dependency (tensorflow#118).
@judah judah mentioned this issue May 16, 2017
Merged
judah added a commit to tensorflow/haskell that referenced this issue May 16, 2017
@judah
Add extra-lib-dirs back into .cabal for Mac builds. (#122)
d98e5d6 
Also bump the version to 0.1.0.2.

Originally we had `extra-lib-dirs: /usr/local/lib` in `stack.yaml`.
I removed it because it wasn't necessary on my Mac.  However,
it turns out that it is necessary for machines with the default installation
of XCode, which *doesn't* search that path by default.

(On my machine, it wasn't necessary because I had run `xcode-select --install`
which adds that path permanently to your search path.  For more context, see
Homebrew/brew#556.)

I'm adding the setting back to `tensorflow.cabal` as well as `stack.yaml` so
that the Hackage release also contains this fix.  Changing `stack.yaml` is
still necessary in order to fix linkage in the `snappy` package (which
`tensorflow-records` depends on).  Hopefully that will go away once we remove
the dependency (#118).
judah added a commit to tensorflow/haskell that referenced this issue May 16, 2017
@judah
Add extra-lib-dirs back into .cabal for Mac builds. (#122)
8bb0d2c 
Also bump the version to 0.1.0.2.

Originally we had `extra-lib-dirs: /usr/local/lib` in `stack.yaml`.
I removed it because it wasn't necessary on my Mac.  However,
it turns out that it is necessary for machines with the default installation
of XCode, which *doesn't* search that path by default.

(On my machine, it wasn't necessary because I had run `xcode-select --install`
which adds that path permanently to your search path.  For more context, see
Homebrew/brew#556.)

I'm adding the setting back to `tensorflow.cabal` as well as `stack.yaml` so
that the Hackage release also contains this fix.  Changing `stack.yaml` is
still necessary in order to fix linkage in the `snappy` package (which
`tensorflow-records` depends on).  Hopefully that will go away once we remove
the dependency (#118).
@EdSchouten EdSchouten mentioned this issue Mar 4, 2018
Closed
@Homebrew Homebrew locked and limited conversation to collaborators May 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rasky @UniqMartin