Running Ubuntu bins on openSUSE

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Running Ubuntu bins on openSUSE

Roger Oberholtzer-2
(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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

L A Walsh
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Roger Oberholtzer-2
On Mon, Dec 18, 2017 at 4:20 AM, Linda Walsh <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Stakanov Schufter
In reply to this post by L A Walsh
In data lunedì 18 dicembre 2017 04:20:54 CET, Linda Walsh ha scritto:

> 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
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Roger Oberholtzer-2
On Mon, Dec 18, 2017 at 9:31 AM, stakanov <[hidden email]> wrote:

> In data lunedì 18 dicembre 2017 04:20:54 CET, Linda Walsh ha scritto:
>> 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
> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Carl Hartung-2
In reply to this post by Roger Oberholtzer-2
On Mon, 18 Dec 2017 08:39:22 +0100
Roger Oberholtzer wrote:

> On Mon, Dec 18, 2017 at 4:20 AM, Linda Walsh <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Roger Oberholtzer-2
On Mon, Dec 18, 2017 at 2:17 PM, Carl Hartung <[hidden email]> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running foreign distros on openSuse (was Re: Running Ubuntu bins on openSUSE)

Stakanov Schufter
In reply to this post by Roger Oberholtzer-2
In data lunedì 18 dicembre 2017 14:04:20 CET, Roger Oberholtzer ha scritto:

> On Mon, Dec 18, 2017 at 10:46 AM, stakanov <[hidden email]> wrote:
> > The bigger question for me is, give the build service and its possibility
> > to AFAIK easily build packages that are available to a multitude of
> > common distributions, why does the industry still persist in only offer a
> > .deb.....
> I guess it also means that they have to set up a number of systems and
> test all of them. I wonder if companies do that for the various
> releases of Windows? Or if all testing is on one release. Obviously no
> one answer. But I bet they are willing to go the extra testing
> distance on Windows. It is surely the testing and not the build that
> is the issue.
>
> I also suspect that most companies do not know about the Build
> Service. Can they use a local instance of the Build Service if they
> insist on making proprietary packages (i.e., no source released)? I
> mean the Build Service itself. Obviously they have all the library
> issues to stay legal with...
>
> A prime example of a company that might benefit from the Build Service
> is NVIDIA.

Well, even if they know they do not akt.
Example? Devolo, I did write them several times an email about their
"cocktpit" controll software and told them about build service (since they do
only have ubuntu .deb.
No answer and no change of attitude. :-(



_________________________________________________________________
________________________________________________________
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: [hidden email]
To contact the owner, e-mail: [hidden email]