针对各种处理器体系结构的本机库位置的最佳做法命名策略

Question

在我的许多java项目中，有时我需要添加本机依赖项。每次我都想知道如何以一种经得起未来考验/可扩展的方式命名安装/提取位置。我看着其他人是怎么做的，但我看到到处都有不同的命名策略。

我知道这是一个主观的问题，但我仍然非常感谢你的投入。只要选择你想评论的任何方面。

我目前的清单（打算是一份正在进行的工作）：

lib/native/linux-x86/libtest.so
lib/native/linux-x64/libtest.so

lib/native/linux-armel/libtest.so

lib/native/linux-armhl-32bit/libtest.so
lib/native/linux-armhl-64bit/libtest.so (or will armhl libs be like mac dylibs and contain/cover both architectures?)

lib/native/macosx/libtest.dylib (looks like dylibs often contain both x86 and x64 architectures in one file)

lib/native/windows-x86/test.dll
lib/native/windows-x64/test.dll

我发现这些事情很难决定：

操作系统名称：win/windows， lin/linux， mac/macosx/osx？ 处理器架构：IA-32/x86/i386/i586/i686， x86-64/x86_64/x64/amd64？
• 32位vs 64位：我知道这些信息在处理器架构旁边是多余的，但是为了清楚起见，也许应该包含这些信息？
• armel/armhl：这个页面似乎表明64位ARM处理器与32位组件兼容？所以也许真的没有必要区分armhl的32位和64位？
• mips、mipsel、power pc、ppc、solaris、spac、itania/ia64/IA-64等在什么地方适合这个方案？
• 我需要担心英特尔和AMD处理器之间的差异吗？
• 为什么很多人对mac os（如macosx）使用特定的名称，而对linux/windows标识符却不使用？
• 手机和平板电脑处理器呢？它们已经被这个列表覆盖了吗？

我对处理器架构的大部分“知识”都是从这个答案中获得的：https://unix.stackexchange.com/a/125314/109380

编辑：- 2015-04-08：删除了32/64位标识符，因为它们似乎是冗余的，将mac 32/64位变体折叠成一行，因为它们可以包含两种架构。

Answer 1

JNA对命名约定进行了两次修订。

第一个简单地根据Java为OS生成的内容生成OS系列/CPU架构对。名称和操作系统。arch，它松散地基于许多GNU软件使用的主机/目标三元组。实际上，这些三胞胎只在操作系统和arch组件中包含信息。

JVM产生的值实际上非常不一致，这导致了版本二。

操作系统系列linux、solaris、freebsd、netbsd、darwin（OSX）、android

CPU Arch x86、x86_64、ppc、ppc64等。

CPU拱门通常足以识别32位与64位。

至于ARM变体，我对这方面没有太多经验，但您确实需要在本机库中区分硬浮动选项和软浮动选项，并明确这一点。我认为把它嵌入“拱门”部分不会有什么坏处。

如果你不期望在任何合理的时间框架内使用它们，我不会太担心其他变体（mips/mipsel）。

Powerpc=ppc（ppc64区分64位）sunos=solaris（spac64是太阳硬件的拱门）itania/ia64=你可能只找到一种味道，ia64足够拱门英特尔=amd（从Java，你不太可能发现差异）

移动设备/平板电脑将主要采用Android系统或windows Mobile，通常采用ARM处理器。

“Darwin”是OSX的通用名称，多个体系结构可以捆绑在一个库中，因此通常不需要区分arch。