如果我们从不同的语言调用它的函数，语言会在编译的库上留下什么标记，我们需要语言绑定？
目标代码对我来说看起来"无语言"。
在Linux环境中学习OpenGL时，我有跨语言绑定。
绑定为应用程序提供了一种简单且一致的方式来呈现数据并与之交互。
来源：您问题下的标签
我猜你要么很年轻，要么已经十多年没有编程了。
目标代码应该看起来没有语言，但它不是由于历史。早在 1970 年代和 1980 年代，在英特尔 80x86 和摩托罗拉 680x0 CPU 上，函数调用参数就在堆栈上传递。在"Pascal"约定中，参数的数量是固定的，被调用的函数代码在返回之前将它们从堆栈中删除。在"C"约定中，参数的数量是可变的（例如 printf），因此调用代码必须在函数返回时删除它们。这需要每个函数调用额外花费 2 个字节，这在今天不算什么，但在当时 PC 只有 128K 左右的 RAM 时意义重大。因此，Microsoft选择在Windows API中使用Pascal调用约定，即使它是用C编写的。如果您的目标代码错误地调用了具有 C 约定的 Windows 函数，请 kaboom。这就是为什么头文件仍然充斥着WINAPI和_stdcall和_fastcall等等的原因。
从 1990 年代开始，操作系统作者意识到这是愚蠢的，并开始将标准调用约定强加给每个人。C 约定可以处理这两种情况，因此它在任何地方都被使用。随着迁移到MacOS X，64位Windows和ARM;我们终于得到了无语言的目标代码。
现在，OpenGL被设计为可以从C和Fortran使用。（在1990年代，这仍然是科学计算和可视化的重要语言。两种语言都有整数、浮点数和各种大小的整数/浮点数的数组。C 有结构体，但 Fortran 没有，我怀疑这是 OpenGL API 从不使用任何结构体的主要原因。C 和 Fortran 之间 2D 或更高维数组的内存布局也存在差异，再次注意 OpenGL API 从不指定 2D 数组，只指定 1D。
A C API 适用于大多数语言。这部分是因为C是"便携式汇编程序"，几乎可以在任何CPU和操作系统上运行。这也是因为大多数常用的其他编程语言要么是C的超集（C++，Objective-C），要么是用C本身实现的（Python，Perl，Ruby），所以可以相当容易地调用OpenGL C API。
Java和C#有更多的问题，因为它们定义了自己的目标代码，可以这么说，内存访问受到更严格的控制。C/OpenGL的"这里是指向内存块的指针，用它做你喜欢的事情"的概念打破了JVM/CLR的安全模型。所以你最终不得不使用Java NIOByteBuffer的东西，而不仅仅是传递数组。
其中很多也归结为语言绑定设计人员的技能。举个例子，Mike Fletcher的Python-OpenGL是一个非常好的绑定。所有函数和常量都有完全相同的名称，因此很多代码都可以从 C 复制并粘贴到 Python 中。Python 没有直接的 C 样式数组，但语言绑定会将您作为"数组"传递的任何 Python 序列/元组默默地转换为底层 C 格式。对于Python程序员来说，这感觉很自然，并且仍然暴露了OpenGL的全部功能。
举个不好的例子，JOGL 是屁股上的痛苦。没有从Java数组到C的自动转换，所以你必须自己使用NIOByteBuffers。它太烦人了，实际上使用glBegin更容易。格伦德块。并且额外的数组偏移量参数被添加到许多 OpenGL 函数中，因此您的代码看起来不再与 C/C++ 相同，并且您浪费大量时间在函数调用结束时粘贴 ，0。其中一些是由于前面提到的JVM，但其中很多只是（我怀疑）一个从未真正写过OpenGL的人的糟糕设计。
对一个模糊问题的冗长而漫无边际的回答。
好吧，你所要做的就是考虑 C 和 C++ 中的无数调用约定。为了防止发生严重事故，编译器会根据调用约定修改函数名称，以便您不会意外地使用fastcall约定调用stdcall函数。每种语言都有自己的一组多余的细节，就像这样，独立于语言的 API 永远不必负担自己。语言绑定充当适配器/桥梁，将特定于语言的内容与标准化 API 分开，在必要时填补空白。
OpenGL API通常以单一语言（C）实现，用其他语言编写的程序通过语言绑定与系统的实现接口。OpenGL 对 GLSL 使用以 null 结尾的 ASCII 字符串，并具有许多使用指针的函数，这些函数对于设计为用 C 实现的 API 非常有意义。在 Java 中，字符串不是以 null 结尾的，而是 UTF-16 编码的;你可以看到为什么需要一座桥。Java GL 绑定负责字符串转换并更改类似glVertexPointer (...)函数以适应 Java "指向"连续内存块的条件。