Libuv: For Unix OSes do not supply an exact path

[borgdylan]

The only supplied binaries for libuv are for WIndows and Mac. The Linux library would be libuv.so . I suggest to force Linux users to install a build of libuv themselves into one of the standard UNIX library paths and let the OS do the library finding when dlopen is called. This is because Linux runs on a multitude of different architectures most of which are supported by mono. Therefore it is not feasible for kestrel to try and supply a build for each CPU possible.

[lodejard]

Do you think it should try to load "libuv", "libuv.so", or "libuv.so.11"? Asking if 11 should be in the file name because loading "libuv" and getting 0.10 will break, but I don't know if you can assume the numbered name is present.

Though I guess I could fire up the Ubuntu vm and try building it. :)

[borgdylan]

For UNIX p/invokes mono does a good job when you let it. So load libuv in your p/invokes so you use the convention that is used to avoid shared object (UNIX DLL) hell. This translates to libuv.so on Linux and libuv.dylib on Mac OS/X. On Linux libuv.so will be symbolic linked to the actual version on the machine so for e.g libuv.so will link to lubuv.so.10 and once you install version 11 it links to libuv.so.11 without breaking your p/invokes. Also, just loading libuv means the operating system syscalls will search in the library path which is usually /usr/local/lib, /usr/lib etc. The syscalls also know about cross-platform targeting libraries (managing x86 and x64 versions on the same machine etc)

PS: If you are using p/invokes only ie. no LoadLibrary onWin32/Win64 then you can cross-platformize the whole solution by loading "uv" if the library on windows is uv.dll.
See the mono article here for conventions (read till the end): http://www.mono-project.com/Interop_with_Native_Libraries#Library_Handling

[borgdylan]

I am also ready to try out kestrel once this blows over and will give feedback. My test scenario is on ARM so it should test the cross-platform story better. My suggestions however apply to any cpu given that the user compiled and installed libuv on their machine.

[akoeplinger]

@lodejard the filename is a convention used for versioning (libFoo.so.MAJOR.MINOR): http://unix.stackexchange.com/a/481
Since you seem to require version 0.11 it'd be good to explicitly load that one, i.e. libuv.so.0.11 as the libuv API apparently isn't yet stable anyway.
Note: many distros only ship libuv 0.10 in their repositories, so users will have to compile libuv themselves.

@borgdylan the libuv.so file/symlink is only present if you install the development packages, so you can't rely on that being there.

[borgdylan]

If one installs from source, the development package is part of the bundle. To use a specific version kestrel would need to settle on a particular libuv version.

[Dave-Daniel]

Would it be possible to include the library and set to use it with an environment variable similar to http://www.linuxquestions.org/questions/linux-software-2/how-to-set-ld_library_path-684799/ I am a little worried that if you use a global version then if someone updates libuv when there has been a breaking change they will not realize that they took down a website they knew nothing about. Part of the big thing with vnext is moving away from centralized libraries like the gac and a single .net/(mono can already be deployed multiple times)

[santiagoaguiar]

The code is now pointing to libuv.so.1, which AFAIK is not the right path (there's no 1.x version of libuv).

The right one would be libuv.so.0.11, though for some reason libuv installs it as libuv.so.11 when compiled from source, so it might be a good idea to check for that one too.

Also, failing hard and explicitly on KestrelEngine constructor if the file cannot be found might be a good idea, is hard now to figure out why is failing.

BTW, I had the same issue with older versions of 0.11 (e.g. 0.11.9), though 0.11.29 worked OK.

[akoeplinger]

@santiagoaguiar libuv 1.x is currently at RC2: https://github.com/joyent/libuv/releases/tag/v1.0.0-rc2 so it'll be ready soon.

[ru-sh]

Same bag on Ubuntu 10.10.

[davidfowl]

This bug was fixed

[lodejard]

If you're looking for a way to quickly build rc1 on an Ubuntu-like disro, here's what I've used https://gist.githubusercontent.com/lodejard/c4260f246b1b0182466c/raw/f4e92b5a94131e33298c494ceda61109a5f6ef08/go.sh

[ru-sh]

Louis DeJardin, Thank You!

[steviefordi]

@lodejard you are the man! I could not work out how to build libuv and your little script worked like a charm - Thank you.