首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Visual Studio中静态链接OpenSceneGraph库的未解析外部变量

在Visual Studio中静态链接OpenSceneGraph库的未解析外部变量是指在使用OpenSceneGraph库时,编译器无法找到该库中定义的某些变量的实际定义。这通常是由于链接器无法找到库文件或库文件中缺少相应的定义所导致的。

为了解决这个问题,可以采取以下步骤:

  1. 确保已正确配置OpenSceneGraph库的路径:在Visual Studio中,打开项目的属性设置,进入“VC++目录”选项卡,将OpenSceneGraph库的路径添加到“包含目录”和“库目录”中。
  2. 确保已正确链接OpenSceneGraph库:在项目属性设置中的“链接器”选项卡下的“输入”子选项卡中,添加OpenSceneGraph库的名称,通常是以“lib”开头的库文件名,如“libOpenThreads.lib”、“libosg.lib”等。
  3. 检查OpenSceneGraph库的版本兼容性:确保使用的OpenSceneGraph库版本与项目所使用的编译器和操作系统兼容。不同版本的库可能具有不同的函数和变量定义,导致链接错误。
  4. 检查代码中的变量引用:确保代码中对OpenSceneGraph库中变量的引用正确无误,变量名拼写正确,并且在正确的作用域内使用。
  5. 检查库文件是否完整:确保OpenSceneGraph库文件完整且没有损坏。如果库文件损坏或不完整,可以尝试重新下载或从可靠的来源获取。
  6. 检查编译选项:在项目属性设置中的“C/C++”选项卡下的“代码生成”子选项卡中,确保编译选项与OpenSceneGraph库的要求相匹配。例如,检查是否启用了正确的编译器选项、是否使用了正确的运行时库等。

总结起来,解决Visual Studio中静态链接OpenSceneGraph库的未解析外部变量问题需要确保正确配置库的路径、正确链接库、检查版本兼容性、检查代码中的变量引用、检查库文件完整性以及检查编译选项。通过这些步骤,可以解决该问题并成功静态链接OpenSceneGraph库。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • boost编译

    经历了将近半年多的时间boost终于发布了1.35.0版本(前版本1.34.1发布于2007/7), 其编译方法和原来的编译方法基本上是一致的,主要改变包括1.34.0以来bjam的toolset所 提供的参数名称的改变(具体参见《boost1.34.0编译日志》)外,还包括bjam的编译默认 选项的变化,在1.35.0之前的版本默认编译时会自动编译各种版本的库,包括静态库、 动态库、debug库和release库等全部的版本,但是到了1.35.0时默认的选择仅仅编译release 版本的库,这样一来在开发的时候就不能进行必要的调试了,为了能够使其编译全部的版本 需要在bjam的命令行参数中添加一个–build-type=complete类型的参数来指明需要编译全 部的版本,所需要编译同时为了使得regex库能够通过ICU库支持Unicode,在编译上需要有 一些特殊的选择。我在Visual Studio 2005 Pro + SP1环境下编译了该库,为了避免走弯路 所以将其编译的方法进行说明,以方便大家编译。 由于boost是采用其自己的bjam工具通过命令行进行编译的,所以必须在Windows下开启console窗口,同时必须将Visual Studio中C++目录下的环境vcvarsall.bat配置脚本运行一遍,以设置好VC的编译器环境变量。 1. 编译不带ICU支持的boost库 此种情况下的boost库编译起来比较的简单,在准备好的console窗口中输入:

    03

    boost编译汇总

    rem 编译64位boost rem 一直以来都是在Win32环境下Build和使用boost,但现在基本上每天都在64位Win7下工作, rem 所以很有必要把这几天的经验总结下来。和32位环境不同, rem x64环境下编译得先从开始菜单启动Visual Studio的Visual Studio 2008 x64 Win64 Command Prompt进入命令提示符, rem 而不是随便打开任意一个命令行窗口就行。然后转到boost根文件夹,运行bootstrap.bat生成x64版的bjam.exe。然后运行命令: rem bjam --build-type=complete toolset=msvc-9.0 threading=multi link=shared address-model=64 rem 即可生成DLL版平台库,如果要编译静态库版就把shared改为static。 rem 只生成一个库的话加上例如–with-python得编译选项,避免生成东西太多、时间太长。 rem 要有address-model=64属性,如果没有这个属性的话,会默认生成32位的平台库,加入这个选项才能生成64位的DLL。 rem 如果要生成Boost.Python库,需要先下载安装x64版的Python安装包,我用的版本是3.2.3。 rem 在使用这个库编写Python扩展DLL时,默认是使用动态库版的Boost.Python,要使用静态版的必须 rem 在C++项目中定义BOOST_PYTHON_STATIC_LIB宏,这样就不用在使用或发布扩展时带着boost_python-vc90-mt-1_50.dll一起了, rem 当然扩展DLL的尺寸会大些,如果做实验没必要这样,编译又慢生成的文件也大。 rem vs工具链版本:vs2003 : msvc-7.1,vs2005 : msvc-8.0,vs2008 : msvc-9.0,vs2010 : msvc-10.0

    04

    【CSAPP】深入理解计算机系统 第九章 虚拟内存 动态链接 printf 17/26

    这里有一个小问题,就是从上面的图中可以看到静态运行库里面的一个目标文件只包含一个函数,如libc.a里面的printf.o只有printf()函数,strlen.o里面只有strlen()函数。 我们知道,链接器在链接静态链接库的时候是以目标文件为单位的。比如我们引用了静态库中的printf()函数,那么链接器就会把库中包含printf()函数的那个目标文件链接进来,如果很多函数都放在一个目标文件中,很可能很多没用的函数都被一起链接进了输出结果中。由于运行库有成百上千个函数,数量非常庞大,每个函数独立地放在一个目标文件中可以尽量减少空间的浪费,那些没有被用到的目标文件就不要链接到最终的输出文件中。

    02

    openssl怎么编译成动态库

    Windows下编译OpenSSL动态库的方法: 1、安装ActivePerl 初始化的时候,需要使用perl 2、使用VS下的Visual Studio 20xx Command Prompt进入控制台模式 3、解压缩openssl的包,通过cd命令切换到openssl的目录 4、执行:perl configure VC-WIN32 5、执行:ms/do_ms 6、选择不同的编译结果 1) 执行:nmake -f ms/ntdll.mak 该命令生成动态库,默认使用的是MD 2) 执行:nmake -f ms/nt.mak 该命令生成静态库,默认使用的是MT 3) 想生成使用静态链接运行时库的动态库则采用下面方法 复制一个ntdll.mak并命名为ntdll_mt.mak,修改里面的 “CFLAG= /MD /Ox ..............” 为/MT ,然后重新编译,执行 nmake -f ms/ntdll_mt.mak 4) 想生成使用动态链接运行时库的静态库则采用下面方法 复制一个nt.mak并命名为nt_md.mak,修改里面的 “CFLAG= /MT /Ox ..............” 为/MD ,然后重新编译 ,执行 nmake -f ms/nt_md.mak 7.其它命令: nmake -f ms/ntdll.mak clean // 清除编译的中间文件 nmake -f ms/ntdll.mak install // 安装 ,主要是linux下面会自动放到程序目录中 。

    03

    延迟绑定

    动态链接的确有很多优势,比静态链接要灵活得多,但它是以牺牲一部分性能为代价的。据统计ELF程序在静态链接下要比动态库稍微快点,大约为1%~5%,当然这取决于程序本身的特性及运行环境等。我们知道动态链接比静态链接慢的主要原因是动态链接下对于全局和静态的数据访问都要进行复杂的GOT定位,然后间接寻址;对于模块间的调用也要先定位GOT,然后再进行间接跳转,如此一来,程序的运行速度必定会减慢。另外一个减慢运行速度的原因是动态链接的链接工作在运行时完成,即程序开始执行时,动态链接器都要进行一次链接工作,正如我们上面提到的,动态链接器会寻找并装载所需要的共享对象,然后进行符号査找地址重定位等工作,这些工作势必减慢程序的启动速度。这是影响动态链接性能的两个主要问题,我们将在这一节介绍优化动态链接性能的一些方法。

    02
    领券