Could getting libs from CentOS be of any help with relation to Linux compatibility?

fscorrea

fscorrea

First of all, I'm well aware that Linux compatibility is not intended to replace the actual system, that is known of being limited and we get it as it is. No problem with that. The purpose of my asking is that of learning at this point. I tried to install the Linux Discord client in /compat/linux, without success. Tried the DiscordCanary at first and, when the official release came out, tried it as well, again to no avail. Aside from Discord desktop client I've found a BSD version of pretty much everything I wanted, so there is no actual need for running a Linux app. Also, it could be that Discord client has a problem of its own. That's beyond the scope of interest I guess. I'm merely using it as an example for an actually broader, gerenal question.

Though not mentioned anywhere that the libs should come specifically from CentOS, it seems to me an implicit requirement for /compat/linux, right?

The handbook only mentions ldd. Suppose I follow the handbook procedure, but in Arch or Debian. Whatever shared objects thereby listed in the output for a given application would still depend on:
  • Its own version;
  • The version of other libs listed;
  • Whatever they were compiled against.
Thus, is it safe to presume libfoo.X.Y was compiled against the same version of whatever it was compiled against? Isn't that relevant for /compat/linux to work properly? What about differences between compilers? Though coming from the same distribution would be hardly enough to avoid such issues, ain't the possibilities potentially uglier if we start mixing Debian libs with Arch libs and so on? Maybe I'm overthinking this?

I carefully replicated not once, but twice, each and every lib on my Linux system for a Discord client (let me know if naming the app is against any rule). Recreated every symlink, noted them down on paper then reconstructed at /compat/linux as shown by the handbook. Twice, I mean, as it was one for Arch, then again with Ubuntu. What I did not try was taking them from CentOS, since I couldn't install Discord there.

If what I said makes any sense, we'd need the app itself to come from CentOS as well. Running ldd on the Discord app on Arch produces an output different if compared to the one produced by running ldd on the same Discord app in Ubuntu. And that to the same version of the same app (Discord had only one version anyway when I did this).

Makes sense to me, since, despite being the same compiled application, they're depending on libraries installed in distinct environments. The same shared object could be. for example, inside /lib in distro A, inside a /lib64 folder in distro B, and somewhere pointed to by a /lib64 soft link, let's say someplace inside /lib, that in distro C. In other words, it would make little sense running ldd in a binary from Debian if the output can be so loosely related to how things will be actually tried on /compat/linux "CentOS".

In the end, my question is: would getting the libs from CentOS rather than other distros be of any help since that's what /compat/linux is based on? Or it makes no difference at all and doesn't matter from where I get my libs as long as they're properly set so the loader finds what it wants to, in the path where it looks at?

OBS: Let's assume that every version number matches exactly the output of ldd, so we can focus on the main question of whether its origin is of relevance and how much.

I'm well aware of having lots, lots of threads about Linux compatibility. None I've read so far managed to answer my question. The closest I've found had a reply mentioning the problem of libs that could had been compiled against different libs or versions of a given library. That, however, was pretty much the whole point in that answer - which is valid, but lacked more context, or conditions. It was presented as an explaining to "how things could not end well", but as if could happen regardless of anything but chance. Or so I failed to grasp anything beyond this point. I'm asking here if there's some degree of "narrowing down", be it as broad as just coming from "CentOS" or tighter, like coming from "CentOS 7", "CentOS 7.Y", "CentOS 7.Y.Z", of if the only way of being sure is checking each and every library individually - what would be rather extreme and make me wonder how CentOS could work itself in such conditions, but as long as I lack the proper understanding, I won't overlook any possibility by sounding "absurd" or "far-fetched"

Thanks in advance.
 
But at the time I had installed every linux-c6-* package listed by pkg search and still had shared libs missing. I had problems with the loader too (that should be working now though, since the Handbook mentions 64-bit support). Later on, it upgraded to CentOS 7 but there were no packages for c7 at the time I looked, so I've built from the ports like you said.

Again, shlibs were missing. I looked carefully, fixed some symlinks (especially those regarding paths where the libs were supposed to be) and, in the end, there were some still missing.

SirDice according to the FreeBSD Handbook, chapter 10.2.1:
If a Linux® application complains about missing shared libraries after configuring Linux® binary compatibility, determine which shared libraries the Linux® binary needs and install them manually.

From a Linux® system, ldd can be used to determine which shared libraries the application needs. For example, to check which shared libraries linuxdoom needs, run this command from a Linux® system that has Doom installed:
Code: 
[b]% ldd linuxdoom[/b]
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
Then, copy all the files in the last column of the output from the Linux® system into /compat/linux on the FreeBSD system. Once copied, create symbolic links to the names in the first column. This example will result in the following files on the FreeBSD system:
Code: 
/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Click to expand...
Thus, I assumed emulators/linux_base-c7 and emulators/linux-c7 provided only part of the libs, and I'd have to get the rest from Linux itself, as highlighted above.

On a side note, it stopped complaining about shlibs when I did this way, with the loader and the missing libs copied from Ubuntu, but the question about if would've been "better" having them from CentOS7 remained unclear.

Still, something went wrong and execution failed anyway, but I don't think the problem to be related to this question (perhaps another thread, in the future).

Should I follow the Handbook and get it "from Linux system" or just rely on emulators/linux-c7? And despite the book speaking of "Linux" in a broader sense, is there anything to be gained getting them from CentOS7 as I asked?
 
fscorrea said:
and the missing libs copied from Ubuntu, but the question about if would've been "better" having them from CentOS7 remained unclear.
Click to expand...
You can probably answer your own question. How well do Ubuntu libraries work on CentOS7? So, given that the Linux emulation is based around CentOS7, how good do you think Ubuntu libraries are going to work when everything else is CentOS7?

Stick to one, don't mix and match. Either use everything from Ubuntu or everything from CentOS, not a mixture of both. And keep in mind the emulation is based on a CentOS7 kernel, so newer Ubuntu versions are likely to choke on the kernel version or run into things that haven't been emulated.
 
You must log in or register to reply here.
Back
Top