有没有办法知道哪个编译器生成了静态库? [英] Is there a way to know which compiler generated a static library?

查看:347
本文介绍了有没有办法知道哪个编译器生成了静态库?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

第三方为我提供了一个静态lib(.a)以便与solaris站点链接。
我尝试用sunpro进行编译,但在链接步骤失败。

A third party provided me a static lib (.a) to link with on solaris station. I tried to compile with sunpro, and failed at link step.

我想问题出在我使用的编译器(代替gcc?)或简单地它的版本(因为编译器提供的std lib可能会与库AFAIK期望的版本不同,因此可能导致链接步骤出错)。

I suppose the issue is coming from the compiler I use (gcc instead?) or simply its version (as the std lib provided by the compiler could change from the version expected by the library AFAIK it could leads to errors at link step).

我怎么知道哪个编译器用于生成此库?有一些工具可以做到这一点吗?在sunpro / gcc中有其他选择吗?

How could I know which compiler was used to generate this lib? Is there some tools doing that? Some option in sunpro/gcc or whatever?

提示:我前一段时间读过,编译器使用不同的处理方式生成目标文件时的约定(是?)。尽管如此, nm --demangle 命令行仍然可以从该静态库中的调试符号中很好地打印出所有函数名称。它是如何工作的 ?如果我的假设还可以,那么 nm 确实可以解决静态库中正在使用的约定,不是吗?还是仅仅是因为lib是由GNU gcc生成的,因为nm是GNU binutils的一部分?

As an hint: I've read some time ago that compilers use different mangling conventions when generating object files (true?). Still, "nm --demangle" command line prints me well all function names from debug symbols in this static lib. How does it work ? If my assumption is ok, nm does have a way to resolve which convention is in use in a static library, isn't it? Or is it simply meaning that lib was generated by GNU gcc, as nm is a part of GNU binutils?

我不靠近我的工作站,所以我无法复制和粘贴链接器的错误输出(暂时不可用,但是我可以在以后的编辑中复制它们)

I am not close to my workstation so I can't copy & paste error output from the linker (not for the moment but I could copy them in a further edit)

推荐答案

我倾向于使用 strings 程序(带有' -a '选项,或者是我自己的变体,其中' -a '的行为是标准行为),然后寻找告示牌。例如,在我自己的一个库中,我发现:

I tend to use the strings program (with the '-a' option, or my own variant where the '-a' behaviour is standard) and look for the tell-tale signs. For example, in one of my own libraries, I find:

/work1/gcc/v4.2.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.3/include
/work1/gcc/v4.3.0/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/include
/work1/gcc/v4.3.1/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.1/include
/work1/gcc/v4.3.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.3/include

这表明该库中的代码已经使用了多种版本的GCC进行了编译(实际上,我在单个库中找到这么多版本感到非常惊讶)。

That suggests that the code in the library has been compiled with a variety of versions of GCC over a period of years (actually, I'm quite startled to find so many versions in a single library).

另一个库包含:

cg: Sun Compiler Common 11 Patch 120760-06 2006/05/26
acomp: Sun C 5.8 Patch 121015-02 2006/03/29
iropt: Sun Compiler Common 11 Patch 120760-06 2006/05/26
/compilers/v11/SUNWspro/prod/bin/cc -O -v -Xa -xarch=v9 ...

所以通常是目标文件中的指纹指示使用ch编译器。但是您必须知道如何查找它们。

So, there are usually fingerprints in the object files indicating which compiler was used. But you have to know how to look for them.

这篇关于有没有办法知道哪个编译器生成了静态库?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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