What are some alternatives to pickFirst in gradle?...
# community-support
c
What are some alternatives to pickFirst in gradle? My situation is that I have two separate modules which both have their own version of a jniLib (libusb.so). So when both modules are in my project, I can't build my project unless I do
pickFirst
. But that makes my project non-deterministic. Is there some alternative to pickFirst that can make it more deterministic? Better yet... can I have each module have it's own libusb without them clobbering each other?
e
bundled dependencies bad. if libusb were a dependency of both of those, then you wouldn't have this issue
c
unfortunately outside of my control. super weird 3rd party we're working with delivers sdk(s) over an ftp client in zip format. 😭
v
You could use an artifact transform to throw out the native lib from one of the dependencies and thereby control from which it is used. If you are sure both can work then, that is.
e
or since it's you manually downloading the artifacts and adding them to your project in the first place, you could fix them at that point
c
Maybe I'm missing something here (sorry) but how would i "fix" them?
e
unbundle libusb and add a dependency
c
So you would recommend unbundling from the two libraries/sdks. And then just adding a single dependency?
if so. then I think that makes sense, but ideally I'd be able to have each library keep their own version of libusb
v
I doubt this is possible. At least if I understood correctly that
libusb
is a native library. In Java you can only load a given native library once and from one class loader. If you for example have an application server where you deploy two web applications that try to load the same native library, it will fail for the second one with something like
java.lang.UnsatisfiedLinkError: Native Library ... already loaded in another classloader
, even if it is the same native library file, let alone different versions.
c
Oh. very interesting. so maybe i just need to try to recompile the libusb.so somehow of one of the libraries. then i can have both living peacefully
kinda weird restriction that you can only have one so with a given name. seems like a lot of libraries would have conflicts because of this.
v
Not really, because most libraries should not use native code, but keep in the Java world 😄 I have no idea whether that is a restriction of Java or even more underlying. Maybe you can also not do this in native projects. 🤷‍♂️
e
yes. on native, it is not possible to load multiple vesions of the same library. it's not the SONAME that matters, but the fact that the linker symbols will collide
til 1
also the limitation is really per-process, it's fine to have different versions of libraries used by different processes (apps)
v
Yeah, that would indeed be extremely strange, if it did not work in separate processes
e
(before SxS there could only be version of a COM library system-wide without some extra shenanigans but that's Windows for you)
😱 1
c
interesting. okay. so my thought of bundling these as separate libraries or something wouldn't work. last ditch effort. I'd be fine with using
pickFirst
but I don't know what version of libusb each library uses. Is there a way for me to see what version of libusb each one uses if I have access to the .so files?
v
That's not so much a Gradle question, but let me Google that for you: https://unix.stackexchange.com/questions/58846/viewing-linux-library-executable-version-info
c
got it. apologies! im way in over my head on this project. and my manager keeps switching my team. im back on this team after like 2 months of another team and im just trying to get things to work again lol. thank you for all of the tips
👌 1
e
libusb has a
libusb_get_version
function https://libusb.sourceforge.io/api-1.0/group__libusb__misc.html#ga61d07b01404fdea080cd16c1ed8be93d so you could load each library (in separately local test processes) to see info of each
party gradlephant 1