Wrongly reports i386 architecture

[probonopd]

me@host:~$ /home/me/Downloads/AppImage_Info-x86_64.AppImage /home/me/Downloads/AppImage_Info-x86_64.AppImage 
Not .appdata.xml file found.

{
  "abstract": {
    "default": "\"Extracts metadata form AppImage files.\""
  },
  "categories": [
    "Utility"
  ],
  "file": {
    "architecture": "i386",
    "sha512checksum": "6d43af8fcfec8ffc96b1dfa68d387628179a21957c3d150f2a245cab7ba1ffa5990916c7b6e5f4795c62c0ec22883623c50196b834da1f87d85db64ba4c67dd5",
    "size": 0,
    "type": 2
  },
  "format": 1,
  "icon": "",
  "id": "appimage-info-10033262ccb8.desktop",
  "name": {
    "default": "AppImage Info"
  }
}

[azubieta]

libbfd is being used to get this info. Let's check if its a bad use or a bug on the lib.

[probonopd]

Can you reproduce the issue?

[azubieta]

@probonopd yes. It happens that x86_64 is an extension of i386. Therefore the output was not totally wrong but incomplete. The whole name of the architecture will be "i386:x86_64". Where the 'i386' stands for the architecture family name and the 'x86_64' stands for the machine name (also known as 'Target Platform'). So in order to deliver to our users something that they could understand we are going to output only the Machine name. But be aware that this is somehow incomplete.

[probonopd]

Do you know what the machine name (also known as 'Target Platform') is for ARM 32-bit and ARM 64-bit?

[azubieta]

I have been digging a bit more on the topic. It happens that libbfd has an exhaustive list of architectures but those must be enabled at build time. The default build usually only include the current system arch and those that are compatible with it.

The libbfd build that supports all the system architectures is 56mb by itself! Which in my opinion is too much for being statically linked into libappimage-info.

So our options so far would be:

• Implement our own architecture identification mechanism.
• Provide two versions of the lib
• Provide a version with only the architectures we select.

Any thoughts are welcome @TheAssassin

[probonopd]

The libbfd build that supports all the system architectures is 56mb by itself!

What the heck. How many architectures are there, after all? Maybe we should just parse the ELF ourselves.

Did you try readelf -h?

[TheAssassin]

@azubieta I still have plans to extract the ELF code from libappimage, linuxdeploy and AppImageUpdate into a unified libelf. We just need a small subset of what libraries like libbfd can provide. That way, we decide what goes into the library. And the ELF standard happens to be documented quite well.

I expected libbfd to be problematic when you first mentioned it. It's just trying to solve too many problems IMO. We need something ELF specific only.

Perhaps we can even re-use code from tools like readelf or patchelf (unless they use libbfd internally).

[azubieta]

@probonopd that was my reaction too. It seems that Ubuntu also ships a Multiarch version of this lib that can be used. @TheAssassin about making our own implementation. I guess that reading the "e_machine" from the elf header will be enought.

[azubieta]

By the way, could you provide links to AppImages in diferent architectures for further tests.

[azubieta]

LibBfd multiarch is now being used, it should support a wider range of architectures. Also #9 was opened for future situations like this.

[TheAssassin]

@azubieta yep, that's quite simple code, one just has to map the values from there to e.g., strings, or custom enums, which is just a few LOC. I think writing our own library is really the most viable way. But since you fixed the bug for now, the priority can safely be lowered.

Thanks for looking into this, and fixing the bug.