说明：可能这个问题让行家看上去就会莞尔一笑，但是很多时候在开发中经常被这种莫名其妙的想法给迷住，实际上是对其中涉及到的一些基本概念和原理不太清楚所致，本文将对这个问题进行详细的分析。

我们有时说C/C++语言是源码级别的跨平台，主要是指的是在不同的操作系统平台上，编译器所支持的语法是相同的，对应的函数接口是相同的，但是对应到下面的库文件、可执行文件则是平台相关的。这也就是为何安装配置opepcv的时候，利用cmake生成相应的平台下的工程文件或者makefile，然后进行编译运行，生成对应平台相关的库文件。而库文件实际上参与到链接的阶段，基本上算是等同于经过了编译、汇编后生成的目标文件（.o或.obj），而经过汇编之后生成的就是对应的机器码了，所以说库文件是平台相关的。

明白了上面的道理，我们来看这个问题，实际上就直接不是问题了，因为VS2010生成的是windows下的机器码，而CCS3.3或CCS5.4生成的是DSP目标处理器上的机器码。这两个平台根本不一样。 
举个例子，运行时库，对应的DSP的不同平台，其运行时库都不一样，更别提windows了。运行时库中就包含着对应C语言规范中定义的各种库函数等等。

所以，想直接利用VS2010生成的库，那可能没那么简单。不妨可以试一试，利用VS2010生成一个简单的函数库，实现加法，然后将生成的库拷贝到DSP开发环境CCS工程下，包含引用，并参与编译链接，看看能否编译通过，并且成功下载到DSP运行。

这里还要说明一点，我现在并不太清楚对DSP是不是有动态链接库的概念，可能也有，但感觉好像得是静态链接库才行？这一点存疑，具体编译原理还没有弄太懂，回头再补上。

最好的方法，还是将对应的源文件，拷贝到CCS中，创建生成库的工程，修改代码重新编译链接后生成相应的库，然后才能安心的使用。

感觉：有点没太理解这个内容，现在发现越来越迷糊，这文章估计不对说的。不，很难讲！ 
在windows下配置了gcc，然后可以生成可执行文件.exe，这个exe文件到底是啥？真的是所谓的机器码，二进制码吗？怎么感觉不像呢？exe真的是运行在硬件之上吗？哭了！

-----------------------------------------------------------------------------

经过初步测试，使用CCS编译生成的静态链接库，使用MinGW基于windows下的gcc进行链接，使用命令ar t xx.lib可以解析出对应的obj文件，也可以通过ar -v -x xx.lib将目标文件解析出来。但是再进行解读obj文件时会发生错误，说是没有组织。而且在调用这个库中的文件时，也会出现问题没有发现对应函数的问题。

这说明了一个问题，就是不同的编译器在同一个操作系统之上采用的归档格式可能是一样的，因此可以解析出lib文件中所包含的obj文件，但是obj文件却是与目标处理器相关的。CCS生成的obj文件中包含的是对应DSP64xx的机器码，而MinGW的gcc则包含的是intel的处理器的机器码。所以库文件是编译器、处理器、操作系统相关的，并不能通用，而只能实现对应相同的函数接口，在不同的平台上（指的是编译器、处理器、操作系统）上要有相对应的库文件才能使用。

另外，还想再说一点，对于库，要注意以下几点： 

1. 静态还是动态？ 

2. 导出函数与导出全局变量的声明和定义方式； 

3. 动态链接库的入口函数定义；