![](https://seccdn.libravatar.org/avatar/aea1d8248292e6482742234c5cb514de.jpg?s=120&d=mm&r=g)
Roger Oberholtzer wrote:
(I think this is a libusb question).
I am trying to run some Ubuntu 16.04 binaries on openSUSE Leap 42.3. I have added whatever Ubuntu libraries are different (based on names) to a directory on openSUSE. I can actually run quite a bit. The software is an SDK for high-speed USB3 cameras from Flir (formerly Point Grey). I can run a QT GUI as well as simple command line programs to try to access images from the cameras. The applications talk to the camera. Everything works except getting an image. In strace I see that it is in a futex waiting and waiting.
...
Anyone have any experience running Ubuntu binaries on openSUSE? It seems it is so close to working. But close is not good enough.
I've often run foreign binaries on OS -- sometimes it's a matter of installing the side-by-side, though if they are the same version it often works. The biggest hassle would be the pathnames used in each distro -- they may have the same binary interface, but with the split from the LSB, there is a lot of variability in pathname choices. I'm not sure how or where futex's are setup or if pathnames come into play, but if pathnames are used to place and access futex's, either symlinks or mount-w-bind might provide a workaround. It is ASTOUNDING to me how badly opensuse is even with interoperability with *itself* in different versions. MS solved this quite well nearly a decade ago when they implemented their WinSxS (side-by-side) directories -- allowing each version of libraries to exist and be loaded as needed. Even Unix had this solved to a great extent in that applications could link with specific versions of libraries, like say: /lib64/libreadline.so.6 -> libreadline.so.6.2 /lib64/libreadline.so.6.2* /lib64/libreadline.so.7 -> libreadline.so.7.0 /lib64/libreadline.so.7.0* However, current practice is to remove previous lib versions and thus break any application that might rely on the older version, which seems myopic, at best. As a side effect, the lib libraries in windows often grow in size over time -- as different versions are almost never deleted. At least in linux, it seems easier to run system-wide scans to see what versions are needed to allow pruning, but that would assume that the libraries aren't deleted upon upgrade. WORKAROUND: unpack the rpm's using something like rpm2cpio and place the libs manually to allow side-by-side operation. I've often allowed apps w/different requirements for lib-versions to exist via that method. A related solution -- let apps have a "personality" related to their distro & distro-version -- then they could with filesystem namespaces be set to automatically bind with the libraries they need, but this would require distros to allow for personalities and coordination of namespaces. Just getting such coordination within a specific distro seems like a great deal of work. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org