Missing LibLUV dependency for most recent neovim versions #64400
Comments
|
Update of |
|
They didn't include a You can specify it manually, but our version of nixpkgs/pkgs/development/lua-modules/overrides.nix Lines 243 to 256 in 274715c |
|
There is a lot going on between libluv's buildsystem and neovim's. It's urgent to wait as some say. |
|
@teto |
|
@teto I don't think that's relevant to us in any case. That discussion is about how to build the "bundled" |
|
@gloaming I think we will want to wait until luvit/luv#344 and neovim/neovim#10292 both play out, and a new luv luarock has been published. If necessary, we can then just add a |
|
Waiting for luvit/luv#344 is not really necessary, is it? Also, from what I can tell LuaRocks 3 has several issues (at least within Neovim's bundled build system, for both Linux/Windows)). |
|
@blueyed nixpkgs internally uses Luarocks 3.1.3 currently, so if post-1.3.0 luv changes have caused issues building with Luarocks 3.1.3 in general (rather than just in neovim's bundled build system), then yes, we'd want to wait for you/someone else to figure that out :P. More broadly though, I am interested in knowing what issues you've run into with Luarocks 3, at least on the Linux side. EDIT: Feel free to poke me on Freenode (same nick) if you want to discuss. |
|
@Shados For Linux it's only that we have to switch to "make install" instead of "make bootstrap". luarocks/luarocks#1043 should fix this. The (main) issue on Windows is fixed via luvit/luv@9d28d38 (released already). |
|
Seems like there was a new release luvit/luv@b9b096d , might be worth trying again. |
|
The issue persists on rvolosatovs@19e8bf7 (see diff here: master...rvolosatovs:19e8bf796eeacfaa3d44818fa4cc2ccf029c0d20): Build log |
|
@rvolosatovs could you kindly wrap long logs in ? :)
Well, nothing relevant changed upstream, so it's not surprising it doesn't work. |
|
@gloaming updated |
|
I have it working here: gloaming@9302546 To do it more nicely, we would need Preferably, we should also get the Neovim build to accept a dynamic library. |
Are you referring to Neovim itself, or your build of it? I have this for example (in CMakeCache.txt): |
|
Ah. The problem is that our library is named So it implicitly requires that the file is called |
Why? Neovim's CMake looks for "luv" as the library name, so this translates to "libluv.so" then. You could use |
|
@gloaming your patch works thanks ! I think nixpkgs' luv.so should be named libluv.so as it's the convention. Why isn't it the case already? Is that an issue with luv's installer ? NB: I merged the libluv 1.30 bump thanks |
|
I checked several other Lua libraries and they are all named the same way. It appears to be the convention: https://github.com/brimworks/lua-zip/blob/e01fac77e7ebf1feceed8f95a5de96aa2758e06f/CMakeLists.txt#L34-L37 |
|
Yes, that's so. Also, I've never seen trying to link a lua library the normal C way – they're always open dynamically by |
|
Sure According to https://cmake.org/cmake/help/latest/command/find_library.html CMake should find it though:
Code ref in Neovim: https://github.com/neovim/neovim/blob/6e01ed6a4c859ff915b42422622f1ba3cc80efd5/cmake/FindLibLUV.cmake#L23-L26 |
|
It does find it: The problem is the linker options passed to
|
|
Ah, I see.
I assume we could set the policy to new maybe? Having a SONAME might be a better workaround though? |
This is meant to help with linking against "luv.so", which does not work with "-lluv", if "luv.so" should be used. Ref: NixOS/nixpkgs#64400 (comment)
|
Can you try the branch from neovim/neovim#10661? |
|
No change; it looks like CMake is determined that it knows better in the case where a library has no On the other hand, I don't know whether there's any particular reason that our Lua libraries don't have a SONAME in the first place. Presumably this is standard Lua behaviour and nobody needed it since they weren't linking in the first place. |
|
According to https://cmake.org/cmake/help/latest/policy/CMP0060.html#policy:CMP0060 it should use the new behavior always then. I assume you have CMake >= 3.3? |
This is meant to help with linking against "luv.so", which does not work with "-lluv", if "luv.so" should be used. Ref: NixOS/nixpkgs#64400 (comment)
|
Yes, we're on CMake 3.14.5. I don't think it says CMP0060 will cause it to always happen, see here: https://cmake.org/cmake/help/latest/command/target_link_libraries.html#command:target_link_libraries
I forced the build by manually passing linker flags, and I noticed that the resulting binary in our case has the expected reference: (Although it doesn't acquire the In any case, it looks like this is not a NixOS-specific issue - it will arise on any distribution that doesn't rename the lua shared object. I think you guys need to take this up with CMake and the Lua build system to figure out the right way forward. |
|
Have you tried the latest branch? (from yesterday) luv explicitly requests to have no prefix here with This is what the Arch User Repo package is using: Maybe you could combine it / build it twice to have both variants? As far as I can see
How exactly? For reference, this is the CMake code:
Well, it depends on the usage of This is from luv's README: ~/Code/luv> BUILD_MODULE=OFF BUILD_SHARED_LIBS=ON make |
|
Oh, now I get it. Other distros are providing a I tried blueyed/neovim@8172f6ffb, it still gives the same error (cannot link
gloaming/neovim@4f06dd4 |
|
On what platform is there still an actual distinction between |
|
IIRC on darwin they differ in the extension (.so and .dylib). |
|
This works:
I.e. set our/nvim's |
Use "luv" as imported library to work around "-lluv" being used due to missing SONAME. Fixes neovim#10407. Ref: https://gitlab.kitware.com/cmake/cmake/issues/19578 Ref: NixOS/nixpkgs#64400 (comment)
|
I think I've found a workaround: neovim/neovim#10661 (comment) - please try the branch there again. |
Use "luv" as imported library to work around "-lluv" being used due to missing SONAME. Fixes neovim#10407. Ref: https://gitlab.kitware.com/cmake/cmake/issues/19578 Ref: NixOS/nixpkgs#64400 (comment)
|
Gentle ping to provide feedback on neovim/neovim#10661. |
Use "luv" as imported library to work around "-lluv" being used due to missing SONAME. Fixes #10407. Ref: https://gitlab.kitware.com/cmake/cmake/issues/19578 Ref: NixOS/nixpkgs#64400 (comment)
|
Yeah, it works 👍 Note that Nix needs the second build configuration to get the headers anyway, so I think it's best for us to go that route. (Which means the changes on your end would be for other users' benefit, not us.) Unfortunately the Someone should look into that. |
|
FTR, latest nightly(neovim/neovim@d7aea13) |
|
This works for me too. |
|
works for me as well (commit). |
|
2 or 3 days ago, libvterm deps got updated so neovim 0.4 will need that libvterm https://github.com/teto/home/blob/4f4a3bc8a2bdd69bcbd2e3f78bcd72e8addd771d/config/nixpkgs/overlays/neovim.nix#L155 as well |
|
New release version (0.4.2) will now fail building because of missing
|
|
Hey guys, I'm trying to build a specific branch of Neovim in a git checkout in order to check a certain Neovim PR. I used This error appears although Cmake runs fine. I use I tried to test that branch's build by directly editing with import <nixpkgs> {};
pkgs.mkShell rec {
neovimLuaEnv = lua.withPackages(ps:
(with ps; [
lpeg
luabitop
mpack
nvim-client
luv
coxpcall
busted
luafilesystem
penlight
inspect
luaffi
])
);
cmakeFlags = [
"-DGPERF_PRG=${gperf}/bin/gperf"
"-DLUA_PRG=${neovimLuaEnv.interpreter}"
"-DPREFER_LUA=ON"
"-DBUSTED_PRG=${neovimLuaEnv}/bin/busted"
"-DLIBLUV_LIBRARY=${lua.pkgs.luv}/lib/lua/${lua.luaversion}/luv.so"
# This isn't part of neovim-unwrapped's default.nix but it's my attempt to
# fix the missing header file as that's where I've found that luv.h
"-DLIBLUV_INCLUDE_DIR=${neovimLuaEnv}/include"
];
buildInputs = [
gettext
gperf
libtermkey
libuv
libvterm
luaPackages.luv
msgpack
ncurses
neovimLuaEnv
unibilium
jemalloc
libiconv
procps
glibcLocales
cmake
pkgconfig
];
}BTW, I expected this issue to be closed now, since the 0.4.2 upgrade was merged. Are there any other luv related issues besides mine people are having? |
|
@doronbehar You've got |
|
Thanks @gloaming, you've eventually helped me to find the problem - my channels were'nt updated enough and that's why I've also workaround any other issues with a much simpler with import <nixpkgs> {};
pkgs.mkShell rec {
cmakeFlags = neovim-unwrapped.cmakeFlags;
buildInputs = neovim-unwrapped.buildInputs ++ neovim-unwrapped.nativeBuildInputs;
}Anyway, to conclude, I don't experience any other issues related to luv so as I said before, I think this issue can be closed. |
|
Similar error in macOS Catalina when trying to run And when trying to run "make ." |
|
@vegerot is this the error you get when running |
|
I'm getting the following error when trying to run |
|
|
Except for darwin there's now a different (yet similar) error after solving that one; see https://hydra.nixos.org/job/nixpkgs/trunk/neovim-unwrapped.x86_64-darwin |
Issue description
Since neovim/neovim#10123
neovimrequireslibluvfor builds.See https://github.com/neovim/neovim/wiki/Following-HEAD#20190610
There's no released version yet containing this change, but it's nice to prepare for this already in order to simplify the update later.
The build on rvolosatovs@2b7a3bb fails for me with:
I have no experience with either CMake or Lua, so it's quite hard for me to reason about this and debug, but as far as I understand the issue is that build requires
luv.h(https://github.com/luvit/luv/blob/1.30.0-0/src/luv.h ???) to be present at build time andluaPackages.luvdoes not contain it:Refs neovim/neovim#10181 neovim/neovim#10359 (comment)
cc @manveru
The text was updated successfully, but these errors were encountered: