C编译器之间的链接兼容性? [英] Link compatibility among C compilers?

查看:80
本文介绍了C编译器之间的链接兼容性?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我所知,C编译器中存在大量链接兼容性

。例如,我可以使用GCC使用GCC编译main.c

和func.c,并使用链接器链接对象

(GNU或Sun)。


我很好奇的是为什么这种兼容性存在于标准C ABI的缺席中?


是什么鼓励C编译器厂商同意实现

问题,如对齐,打包等,这样他们的对象

文件兼容?

我听说它说编译器供应商不想重新实现整个标准C库必须使用该平台

ABI符合平台标准库,但在大多数编译器供应商提供他们的b
自己的标准库的印象下,我总是



我很高兴可以分享他们的见解,为什么这个

显然高度的对象兼容性存在于C

编译器中。


另外,有没有明确定义的区域C编译器可能不兼容?


谢谢。

As I understand it there is a good amount of link compatibility
among C compilers. For example, I can compile main.c with GCC
and func.c with Sun One and link the objects using either linker
(GNU or Sun).

What I''m curious about is why this compatibility exists in the
absence of a standard C ABI?

What encourages C compiler vendors to agree on implementation
issues such as alignment, packing, etc., such that their object
files are compatible?

I''ve heard it said that compiler vendors who don''t want to re-
implement the whole standard C library have to use the platform
ABI to conform to the platform standard library, but I was always
under the impression that most compiler vendors provided their
own standard library.

I''d appreciate could share their insights as to why this
apparently high degree of object compatibility exists among C
compilers.

Also, are there any well defined areas where C compilers are
likely to be incompatible?

Thank you.

推荐答案

Derek< us ** @ nospam.org>写道:
Derek <us**@nospam.org> writes:
据我所知,C编译器之间有很多链接兼容性。例如,我可以使用GCC编译main.c
和使用Sun One编译func.c并使用链接器链接对象
(GNU或Sun)。

我是什么我很好奇为什么在没有标准C ABI时存在这种兼容性?
As I understand it there is a good amount of link compatibility
among C compilers. For example, I can compile main.c with GCC
and func.c with Sun One and link the objects using either linker
(GNU or Sun).

What I''m curious about is why this compatibility exists in the
absence of a standard C ABI?



大多数平台都有明确定义的ABI。例如,Linux on

i386往往符合i386的System V Release 4 ABI,

,你可以通过网络搜索轻松找到它。

-

我在我的DeathStation 9000上运行它,恶魔飞出了我的鼻子。 --Kaz



Most platforms have a well-defined ABI. For example, Linux on
i386 tends to conform to the System V Release 4 ABI for i386,
which you can find pretty easily with a web search.
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz


Derek写道:
据我所知,C编译器之间有很多链接兼容性。例如,我可以使用GCC编译main.c
和使用Sun One编译func.c并使用链接器链接对象
(GNU或Sun)。

我是什么我很好奇为什么在没有标准C ABI的情况下存在这种兼容性?

什么鼓励C编译器厂商同意实施
问题,如对齐,打包,等等,这样他们的对象文件是兼容的吗?
As I understand it there is a good amount of link compatibility
among C compilers. For example, I can compile main.c with GCC
and func.c with Sun One and link the objects using either linker
(GNU or Sun).

What I''m curious about is why this compatibility exists in the
absence of a standard C ABI?

What encourages C compiler vendors to agree on implementation
issues such as alignment, packing, etc., such that their object
files are compatible?




对于初学者来说,底层平台提供了一个ABI,并且

C库和C编译器生成的代码

几乎都要尊重它。作为用户,您希望您的C

代码能够调用平台的服务并从结果中获得
感觉,因此所有实现都以

a一定程度的共性。


然后就是非标准库的问题。想象一下

开始为

a平台制作一个新的,超级的C实现,这个平台已经有一个旧的,粗暴的(我是

引用您的营销文献)。您认为要求您的潜在客户在经济上可行吗

重新编译*所有*以便将其与生成的代码链接

你的实施?意识到一切很可能

包括你的客户没有的第三方库

有源。


-
Er*********@sun.com



For starters, the underlying platform provides an ABI, and
both the C library and the code generated by the C compiler
pretty much have to respect it. As a user, you want your C
code to be able to invoke the platform''s services and make
sense out of the results, so all implementations begin with
a certain amount of commonality.

Then there''s the issue of non-Standard libraries. Imagine
setting out to produce a new, super-duper C implementation for
a platform that already has an old, rowsty-frowsty one (I''m
quoting from your marketing literature). Do you think it would
be economically viable to require your potential customers to
recompile *everything* in order to link it with code generated
by your implementation? Realize that "everything" may well
include third-party libraries to which your customers do not
have source.

--
Er*********@sun.com


在文章< 2q ************ @ uni-berlin.de>,Derek< us ** @ nospam.org>写道:
In article <2q************@uni-berlin.de>, Derek <us**@nospam.org> wrote:
据我所知,C编译器之间有很多链接兼容性。例如,我可以使用GCC编译main.c
和使用Sun One编译func.c,并使用链接器
(GNU或Sun)链接对象。
[...]但我总是认为大多数编译器供应商都提供了自己的标准库。
As I understand it there is a good amount of link compatibility
among C compilers. For example, I can compile main.c with GCC
and func.c with Sun One and link the objects using either linker
(GNU or Sun). [...]but I was always
under the impression that most compiler vendors provided their
own standard library.




当你在Sun上使用gcc时,你是不是在使用Sun的库(除了

可能是libgcc中的一些函数)?


如果您必须安装多个版本的

(非标准)库,那么这将是一个真正的痛苦,每个编译器一个你使用的



如果我正在考虑安装一个新的编译器,必须更换

系统上的所有库几乎肯定会回答

我没有这样做。


- Richard



When you use gcc on a Sun, aren''t you using Sun''s libraries (except
maybe for a few functions in libgcc)?

And it would be a real pain if you had to have multiple versions of
(non-standard) libraries that you installed, one for each compiler you
used.

If I were considering installing a new compiler, having to replace
all the libraries on the system would almost certainly ansure that
I didn''t do it.

-- Richard


这篇关于C编译器之间的链接兼容性?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆