首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

在Windows10中Visual Studio2017中使用boost1.69.0

Boost是一个功能强大、构造精巧、跨平台、开源而且完全免费的C++程序库,有着“C++ '准’标准库”的美誉。 Boost是由C++标准委员会部分成员所设立的Boost社区开发并维护,使用了许多现代C++编程技术,内容涵盖字符串处理、正则表达式、容器与数据结构、并发编程、函数式编程等。目前已经更新到了1.72.0版本,官网下载地址为:https://www.boost.org/users/history/version_1_72_0.html,由于我之前在自己Windows10系统上安装的是Boost 1.69.0,其源代码下载地址为:https://sourceforge.net/projects/boost/files/boost/1.69.0/,所以本文直接演示在VS2017下使用boost1.69.0版本,使用32位的debug模式进行测试,其他的64位和VS编译器同理。

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

深入iOS系统底层之静态库介绍

程序员编写的是源代码,而计算机运行的则是CPU能识别的机器指令,因此必须要有一系列工具或程序来将源代码转化为机器指令,这个转化的过程需要经历编译和链接两个主要阶段。所谓编译就是将源代码文件转化为中间的目标文件(Object file)。目标文件的后缀一般为.o。iOS系统的目标文件也是一种mach-o格式的文件,mach-o文件的头部结构体:struct mach_header中的filetype成员字段用来描述当前文件的类型,目标文件所对应的类型是MH_OBJECT。目标文件中的布局结构和内容和可执行文件中的布局结构和内容非常相似,编译后形成的目标文件中的代码段(__TEXT Segment)中的节(__text Section) 中的内容存放的是已经被编译为机器指令的二进制代码了。下面就是一个目标文件的布局结构:

05

C/C++常见gcc编译链接错误解决方法

用“-Wl,-Bstatic”指定链接静态库,使用“-Wl,-Bdynamic”指定链接共享库,使用示例: -Wl,-Bstatic -lmysqlclient_r -lssl -lcrypto -Wl,-Bdynamic -lrt -Wl,-Bdynamic -pthread -Wl,-Bstatic -lgtest ("-Wl"表示是传递给链接器ld的参数,而不是编译器gcc/g++的参数。) 1) 下面是因为没有指定链接参数-lz(/usr/lib/libz.so,/usr/lib/libz.a ) /usr/local/mysql/lib/mysql/libmysqlclient.a(my_compress.c.o): In function `my_uncompress': /home/software/mysql-5.5.24/mysys/my_compress.c:122: undefined reference to `uncompress' /usr/local/mysql/lib/mysql/libmysqlclient.a(my_compress.c.o): In function `my_compress_alloc': /home/software/mysql-5.5.24/mysys/my_compress.c:71: undefined reference to `compress' 2) 下面是因为没有指定编译链接参数-pthread(注意不仅仅是-lpthraed) /usr/local/mysql/lib/mysql/libmysqlclient.a(charset.c.o): In function `get_charset_name': /home/zhangsan/mysql-5.5.24/mysys/charset.c:533: undefined reference to `pthread_once' 3) 下面这个是因为没有指定链接参数-lrt /usr/local/thirdparty/curl/lib/libcurl.a(libcurl_la-timeval.o): In function `curlx_tvnow': timeval.c:(.text+0xe9): undefined reference to `clock_gettime' 4) 下面这个是因为没有指定链接参数-ldl /usr/local/thirdparty/openssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x4c): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x62): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x6c): undefined reference to `dlclose' 5) 下面这个是因为指定了链接参数-static,它的存在,要求链接的必须是静态库,而不能是共享库 ld: attempted static link of dynamic object 如果是以-L加-l方式指定,则目录下必须有.a文件存在,否则会报-l的库文件找不到:ld: cannot find -lACE 6) GCC编译遇到如下的错误,可能是因为在编译时没有指定-fPIC,记住:-fPIC即是编译参数,也是链接参数 relocation R_x86_64_32S against `vtable for CMyClass` can not be used when making a shared object 7) 下面的错误表示gcc编译时需要定义宏__STDC_FORMAT_MACROS,并且必须包含头文件inttypes.h test.cpp:35: error: expected `)' before 'PRIu64' 8) 下面是因为在x86机器(32位)上编译没有指定编译参数-march=pentium4 ../../src/common/libmooon.a(logger.o): In function `atomic_dec_and_test': ../../include/mooon/sys/atomic_gcc.h:103: undefined reference to `__sync_sub_and_fetch_4' 9) 下列错误可能是因为多了个“}” error: expected d

03

Windows下使用VS2019和CMake 3.18.3编译使用yaml-cpp库

通常在程序设计中采用xml、ini、yaml、json等配置文件比较多。在Java的SpringBoot项目中通常采用yaml或者yml文件作为应用的配置项。由于本人在实际项目中采用C++编写控制台程序的过程中使用yaml文件比较多,目前使用比较的多的就是yaml-cpp这个C++ yaml解析库了。之前写过两篇关于在CentOS7下编译yaml-cpp库和Windows10下使用VS2017编译和使用yaml-cpp库的文章。 最近实际项目中换成了最新版的Visual Studio 2019,我使用的Windows系统是Win7和Windows10,所以需要重新编译基于VS2019下的yaml-cpp的Debug和Release版本的Win32的静态lib库,大体步骤和Windows10下使用VS2017编译和使用yaml-cpp库这篇博客描述的一致。

02

OpenCV 图像拼接 优化

前面一篇文件 https://blog.csdn.net/zhanggqianglovec/article/details/103344658 讲述了如果将多个影像拼接为一个大的影像,本文将讲述 一些上面工具在使用过程中的问题及其优化 1. 问题出现: 首先直接说一下工具上的缺陷: 1.1 该工具依赖的是 x86库,包括opencv 2.4.3 ,cholmod 1.6.0 都是32位的,32和64都会影响工具在处理影像时的性能,比如在处理索尼相机的照片时,分辨率是 6000*4000,20多张照片,在处理到一半时会爆出 申请内存失败的情况。(本地环境为 i5处理器四核,16G内存),处理索尼相机时每张照片都会申请 6000*4000 字节内存块,直接内存爆出内存申请失败。 1.2 该工具迁移到其他机子上会出现不兼容的问题,应为opencv 底层设计到 GPU,CPU等指令,所以在其他机子上 运行,稍微大一点的图片 都会爆出 内存申请失败的问题。 2. 问题定位: 接下来说一下问题的定位 刚开始一直以为是内存的问题,因为在处理小一点的图片时,是没有问题的。在处理所以相机时才会出现;但是当迁移到其他机子上的时候,当地环境是 200G的内存,任然会报出 内存问题,这个就不是内存问题了。然后网上查询,大部分的解决思路 都是 32与64的不兼容。知其然不知其所以然,最后通过仔细的查看爆出来的原因,才豁然大悟,opencv底层调用到了cpu、gpu的指令,然后opencv对底层32/64的支持并不是很好,也就是说 在64环境下调用32 的指令,会出现不兼容的问题,从而导致频繁的爆出内存问题,到此为止,已经定位的差不多了,爆出内存问题只是表象,底层是msvcp.dll/msvcr.dll的执行。 3. 解决之道: 既然问题已经定位到,那么解决之道又是什么,毫无疑问:从底层实现对64的支持,不依赖32位的相关东西。说白了就一句话:重新编译mosaic的所有依赖库,全部换为 64版本 应该就能解决问题。 4. OpenCV 2.4.9 64位的编译 4.1 OpenCV下载: Opencv库的编译相对来说简单,通过Cmake直接可编译,问题是Opencv的源码获取比较麻烦,通过github获取,在git下载过程中时常会出现git下载失败,原因是github连接到了外网,会有网路断开等情况,所以通过github上查找 opencv来下载 还是比较麻烦的,需要多试几次。好在opencv2.4.9 有可执行程序,直接安装 opencv2.4.9 即可安装 他的源码,这个比较好,一下子全部搞定。 4.2 OpenCV工程生成: 在选择 Visual Studio 编译版本的时候需要注意下,Opencv 有区分 X86,X64 和 IA及RAM的编译,这个需要根据自己的情况进行选择,64位环境下一定选择 X64,因为我用的时候 Visual Studio 2010,所以我选择的是 Visual Studio 2010 X64版本,然后点集 Configure,Generate,OpenProject 即可在 Visual Studio 2010中 打开 Opencv 的工程。 4.3 OpenCV 工程编译: OpenCV 工程打开后,找到 ALL_BUILD工程,选择Debug/Release版本,右键build,这个工程只会生成对应的lib库和dll库,并不会生成头文件。 INSTALL工程,该工程首先会执行ALL_BUILD工程,然后复制相关库(lib/dll)到install下的 lib目录和bin目录,复制指定头文件到 include目录,这个工程满足要求,右键 build ,工程执行完毕后会在install目录下生成include目录,bin目录和lib目录。 4.4 Opencv编译完成 5. Cholmod 3.1.0 64位的编译 5.1 Cholmod的获取 网上关于Cholmod的讲解很少,在网上找了很久,找到了SuiteSparse这个产品,SuiteSparse是一个产品套件,里面包含了很多图像相关的处理库,Cholmod只是其中的一部分,而且SuiteSparse目前代码都是针对Linux下的开发,没有针对Windows做 相关的操作,源码目录下不存在cmaketext.txt 文件,不能在windows下直接编译。难道要全部

01
领券