[opensuse] Running Ubuntu bins on openSUSE
(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. I have obviously been in contact with Flir support. But we are none the wiser. Saying that you are not running Ubuntu is pretty much the same as saying that you are not running Windows... I do not know that the issue is in libusb. I do not have the source (or it would not be a Ubuntu app...). I can only guess that it is since that must be how the SDK gets images. I have tried the standard openSUSE libusb as well as the one for Ubuntu. It makes no difference. Anyone have any experience running Ubuntu binaries on openSUSE? It seems it is so close to working. But close is not good enough. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On Mon, Dec 18, 2017 at 4:20 AM, Linda Walsh <suse@tlinx.org> wrote:
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.
I remember that HP-UX had a context-dependent file system. Depending on the properties of the process (e.g., a binary's target processor), the file seen varied. It was a simple solution to a complex problem. I wish it existed in Linux. I have had no trouble getting the Ubuntu libs into place. I use 'dpkg -x' to get the .deb file contents into place. Then I use LD_LIBRARY_PATH to get these loaded first. I have tried to stay away from replacing same named libs (Ubuntu and openSUSE have the same name). I started with only adding the missing ones. But I have the problem stated in my original post. So I guess I will add more libs until I see which one tips the balance. As to the lib naming things, I think someone decided that the SOVERSION in the lib should be based on the ABI and not just a point release within the same ABI. I also think this was a shortsighted decision. It does not allow for variations in how a single ABI lib might be compiled - which I agree is messy - but is also a fact of life in the real world. Of course, one is free to change the SOVERSION on their own compile of any difficult library and link with that. The current method generally works for me as I compile from source whenever possible. There are just the occasional hardware suppliers who think that having the source to their libraries gives away the secret of their hardware. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 18 Dec 2017 08:39:22 +0100 Roger Oberholtzer wrote:
On Mon, Dec 18, 2017 at 4:20 AM, Linda Walsh <suse@tlinx.org> wrote:
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.
I remember that HP-UX had a context-dependent file system. Depending on the properties of the process (e.g., a binary's target processor), the file seen varied. It was a simple solution to a complex problem. I wish it existed in Linux.
I have had no trouble getting the Ubuntu libs into place. I use 'dpkg -x' to get the .deb file contents into place. Then I use LD_LIBRARY_PATH to get these loaded first. I have tried to stay away from replacing same named libs (Ubuntu and openSUSE have the same name). I started with only adding the missing ones. But I have the problem stated in my original post. So I guess I will add more libs until I see which one tips the balance.
As to the lib naming things, I think someone decided that the SOVERSION in the lib should be based on the ABI and not just a point release within the same ABI. I also think this was a shortsighted decision. It does not allow for variations in how a single ABI lib might be compiled - which I agree is messy - but is also a fact of life in the real world. Of course, one is free to change the SOVERSION on their own compile of any difficult library and link with that. The current method generally works for me as I compile from source whenever possible. There are just the occasional hardware suppliers who think that having the source to their libraries gives away the secret of their hardware.
Hi Roger, Have you looked at Docker? (https://www.docker.com/) Containers allow you to run applications in what they perceive to be their native environments - effectively /are/ their native environments - without the complexity or overhead of running VMs. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 18, 2017 at 2:17 PM, Carl Hartung <opensuse@cehartung.com> wrote:
Have you looked at Docker? (https://www.docker.com/) Containers allow you to run applications in what they perceive to be their native environments - effectively /are/ their native environments - without the complexity or overhead of running VMs.
I cannot run this in Docker. I am adding this camera to a high-speed measurement system that has many transducers. All of those have openSUSE libraries. I would then need to get all the working openSUSE stuff working for Ubuntu. Easier to select a different USB3Vision camera supplier. I do use Docker for some build related activities. But it is not beneficial for our production use. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. Sorry for my ignorance, but isn't this motivated with security and maintenance needs? E.g. if a library has a security flaw, and is not maintained good enough, the
In data lunedì 18 dicembre 2017 04:20:54 CET, Linda Walsh ha scritto: persistence would be a problem. AFAIR this was one of the major fears and critizisms to container based installs of not distribution based software (as the argument went, this would make usure if libraries used for these installs would be maintained / maintainable.). However I did not follow this up and so forgive me if this is complete BS :-) Any educational effort will be appreciated though. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 18, 2017 at 9:31 AM, stakanov <stakanov@eclipso.eu> wrote:
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. Sorry for my ignorance, but isn't this motivated with security and maintenance needs? E.g. if a library has a security flaw, and is not maintained good enough, the
In data lunedì 18 dicembre 2017 04:20:54 CET, Linda Walsh ha scritto: persistence would be a problem.
I would think that it could be a maintenance issue as using a fine grained SOVERSION number may require packages that link with the library to be updated each time the library is updated. By limiting the SOVERSION to a less specific number, the program will get the new library without it needing to be relinked. But, as always, these things come at a cost. I am okay with the version openSUSE uses. But I see that Ubuntu use a more specific SOVERSION in many libraries. I guess when they change one of these libraries, many other programs get updated as well. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Carl Hartung -
Linda Walsh -
Roger Oberholtzer -
stakanov