Closed tduzan-te closed 9 years ago
Hello, thanks for exploring this bug, I assumed -r was a POSIX option, but it is not, so not using it would have my preference.
Are you aware of a (even dirty) workaround? I was just about to try it like 3 days ago. :smile:
@casimir Yes, you can replace instances of 'ln' in the makefile with 'gln' and use Homebrew to install coreutils. That's the "quick and dirty" hack which gets it working.
@mawww We'll see if I have an opportunity to dig into this further at the office today. If I do, I'll try to create a patch that solves for the use case without relying on the -r flag. I'm assuming file pathing changes would be all that's necessary during the make install step.
@tduzan a system "sed", "-i", "", "-e", "s/ln/gln/g", "src/Makefile"
did the trick thanks. Although following Murphy's law it still doesn't build.
% brew install --HEAD kakoune
==> Installing kakoune from homebrew/homebrew-head-only
==> Cloning https://github.com/mawww/kakoune.git
Updating /Library/Caches/Homebrew/kakoune--git
==> Checking out branch master
==> sed -i -e s/ln/gln/g src/Makefile
==> make -C src install PREFIX=/usr/local/Cellar/kakoune/HEAD
Kakoune::NCursesUI::is_key_available() in .ncurses_ui.o
Kakoune::NCursesUI::get_key() in .ncurses_ui.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [kak] Error 1
That's strange, it'd indicate that you're missing a dependency but ncurses is provided by default on OS X, and Homebrew actually recommends relying on the system version rather than the Homebrew version. I install the Homebrew version myself for some specific things and pass in config-time flags when relevant to build using it, but I don't think that should be necessary here. Perhaps @mawww can weigh in on this better.
My impression is more like an object file doesn't link correctly. If you look at symbols they have nothing to do (except naming) with ncurses. Note that my C++ is a bit rusty though. I compile projects against ncurses often but never had problem.
I just verified it built correctly with my patch in the #297 pull request.
I just installed it with #297. @tduzan ty!
Reference gist-logs at https://gist.github.com/anonymous/2d65990363647cf6f476
The issue is caused because of a flag incompatibility between GNU ln and BSD ln. In the system default ln command, -r is not a valid flag. Here is what the GNU ln manpage has to say about the -r option:
‘-r’ ‘--relative’ Make symbolic links relative to the link location. Example:
This can be solved in a couple of ways, the pathspec can be rewritten to be explicit rather than relative and drop the use of -r altogether in the Makefile, or it can check if it's being run on OSX and specify 'gln' which would cause coreutils to be a build-dep for the Homebrew formula.
I'm happy to submit a patch to do either, but don't want to make an opinionated change in a project I haven't really touched prior.