2

My question is rather conceptual. I noticed that there are different packages for the same architecture, like x86-64, but for different OSes. For example, RPM offers different packages for Fedora and OpenSUSE for the same x86-64 architecture: http://www.rpmfind.net/linux/rpm2html/search.php?query=wget - not to mention different packages served up by YUM and APT (for Ubuntu), all for x86-64.

My understanding is that a package contains binary instructions suitable for a given CPU architecture, so that as long as CPU is of that architecture, it should be able to execute those instructions natively. So why do packages built for the same architecture differ for different OSes?

flow2k
  • 3,999
  • 40
  • 55
  • What do you mean? For each version of the OS, there needs to be a package for each supported architecture. [Possible duplicate](https://superuser.com/questions/238112/what-is-the-difference-between-i686-and-x86-64). – Hadi Brais Mar 22 '18 at 01:36
  • Right...my question is: why is a x86-64 package for Fedora, and there is another x86-64 package for OpenSUSE, and yet another x86-64 package for Ubuntu, etc. What's the difference between these packages? – flow2k Mar 22 '18 at 02:35

2 Answers2

3

Considering just different Linux distros:

Besides being compiled against different library versions (as Hadi described), the packaging itself and default config files can be different. Maybe one distro wants /etc/wget.conf, while maybe another wants /etc/default/wget.conf, or for those files to have different contents. (I forget if wget specifically has a global config file; some packages definitely do, and not just servers like Exim or Apache.)

Or different distros could enable / disable different sets of compile-time options. (Traditionally set with ./configure --enable-foo --disable-bar before make -j4 && make install).

For wget, choices may include which TLS library to compile against (OpenSSL vs. gnutls), not just which version.

So ABIs (library versions) are important, but there are other reasons why every distro has their own package of things.

Completely different OSes, like Linux vs. Windows vs. OS X, have different executable file formats. ELF vs. PE vs. Mach-O. All three of those formats contain x86-64 machine code, but the metadata is different. (And OS differences mean you'd want the machine code to do different things.

For example, opening a file on Linux or OS X (or any POSIX OS) can be done with an int open(const char *pathname, int flags, mode_t mode); system call. So the same source code works for both those platforms, although it can still compile to different machine code, or actually in this case very similar machine code to call a libc wrapper around the system call (OS X and Linux use the same function calling convention), but with a different symbol name. OS X would compile to a call to _open, but Linux doesn't prepend underscores to symbol names, so the dynamic linker symbol name would be open.

The mode constants for open might be different. e.g. maybe OS X defines O_RDWR as 4, but maybe Linux defines it as 2. This would be an ABI difference: same source compiles to different machine code, where the program and the library agree on what means what.

But Windows isn't a POSIX system. The WinAPI function for opening a file is HFILE WINAPI OpenFile(LPCSTR lpFileName, LPOFSTRUCT lpReOpenBuff, UINT uStyle);

If you want to do anything invented more recently than opening / closing files, especially drawing a GUI, things are even less similar between platforms and you will use different libraries. (Or a cross platform GUI library will use a different back-end on different platforms).

OS X and Linux both have Unix heritage (real or as a clone implementation), so the low-level file stuff is similar.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • 1
    Thanks Peter Cordes for this detailed answer! You say "ABIs (library versions)", but I suppose library location (where a dependent library is located/installed - maybe this is the same as your point about the `.conf` file location), and OS system calls (maybe one OS's system call is slightly different than another's) are also part of the ABI, and may also be reasons why the packages (for the same architecture) are different, right? – flow2k Mar 22 '18 at 07:17
  • @flow2k: Yes, more broadly some of that is part of the ABI, like Hadi mentioned with LSB and FHS projects trying to standardize things so 3rd-party software can be portable more easily (although 3rd-party stuff would install in `/opt` or `/usr/local`, not `/usr`). Where to install your own files is not really an ABI thing, it's a packaging standards thing, though. Distro packages don't need to look for libraries in custom locations, though, `/etc/ld.so.conf` already lists `/usr/lib` and anywhere else that distro packages put libraries which other packages could be built against. – Peter Cordes Mar 22 '18 at 09:26
  • And BTW, I was talking about the kind of ABI where machine code in the program and the library agree on the size of a `struct`, and which members it has, and values of compile-time constants. Adding a new member to a `struct` requires recompiling any code that copies it by value, or that has an array of that struct. Or any change to compile-time constants that a program and library have to agree on. Good library maintainers will bump the ABI version whenever they make such a change; this is why x264 is up to `libx264.so.155`; they keep improving it in ways that changes the ABI. – Peter Cordes Mar 22 '18 at 09:29
  • e.g. the bump from x264 ABI version 149 to 150 in `x264.h` came in [the commit that added AVX-512](http://git.videolan.org/?p=x264.git;a=commit;h=472ce3648aea3ddc16b7716eb114f4bcdb8fea8f) support, which [changed a `struct` type defined in `cpu.h` to have `const char *name` instead of `const char name[16];`](http://git.videolan.org/?p=x264.git;a=blobdiff;f=common/cpu.h;h=845034c40e74d00c46169095a22ad884fad9c3bf;hp=eec1be29ef973f7d11b49eb157f3eddfd8d54849;hb=472ce3648aea3ddc16b7716eb114f4bcdb8fea8f;hpb=d2b5f4873e2147452a723b61b14f030b2ee760a5) The build scripts use `X264_BUILD` for the so name – Peter Cordes Mar 22 '18 at 09:32
  • Thanks for all these details Peter Cordes! And thanks to Hadi Brais as well. – flow2k Mar 23 '18 at 07:45
2

These packages contain native binaries that require a particular Application Binary Interface (ABI) to run. The CPU architecture is only one part of the ABI. Different Linux distros have different ABIs and therefore the same binary may not be compatible across them. That's why there are different packages for the same architecture, but different OSes. The Linux Standard Base project aims at standardizing the ABIs of Linux distros so that it's easier to build portable packages.

Hadi Brais
  • 22,259
  • 3
  • 54
  • 95