gcc boost版本冲突解决日记

问题背景

项目在Ubuntu10 64位

boost 1.55,boost采用的是项目内包含相对目录的形式部署

项目采用了 -Wall -Wextra -Werror -Wconversion 最高的告警选项

单独测试是可以的

由于项目中包含的内容很多,头文件超多,因此只能选取1个简单的分支进行测试,可以再现问题,通过各种猜测和测试,最终定位到:

有GCC push_option对boost/thread进行处理后,stl容器使用完全异常[如 map<int,string>空内容时begin()!=end(),插入记录崩溃或死循环,2个机器上运行有细微差别,死循环时gdb attach可以看到map操作无法结束];而不用push_option时一切正常

解决方法

gcc -E 查看代码的预处理结果看到内容太多,没有再细致分析

既然gcc的这个选项和boost的thread有冲突,查看gcc的push_option说明,可见这个针对的时gcc 4.4,而ubuntu默认的gcc是version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ,猜测是否这个实现有些问题

既然此路不同,我们是否可以把第三方库当成系统库用,最简单的方法时拷贝到/usr/include这类目录,但这个方法不实用

查gcc的手册,还真有这个选项-isystem https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Preprocessor-Options.html#Preprocessor-Options

-isystem ${ProjDirPath}/../../others

最终项目配置成这个选项进行编译即可

例子

单独新建工程如下,反而是正常的

g++ -L/opt/work/lib/static -L/opt/work/lib/ -o "zdemo"  ./src/demo.o   -lboost_system -lrt -lpthread -lboost_thread

#include <iostream>

#include <vector>

#include <map>

#pragma GCC push_options

#pragma GCC diagnostic ignored "-Wconversion"

#include <boost/thread.hpp>

#pragma GCC pop_options

#include <boost/make_shared.hpp>

#include <boost/bind.hpp>

using namespace std;

class Demo {

public:

Demo(const string & json){

this->rules[GET].push_back("hello");

this->rules[GET].push_back(json);

}

enum HttpMethod { ANY, GET, POST, PUT, DEL, OTHERS };

typedef vector<string> tRuleContainer;

map<HttpMethod, tRuleContainer> rules;

};

void demoThread(){

Demo u("world");

cout << u.rules.size() << endl;

}

int main() {

boost::shared_ptr<boost::thread> thrMon;

thrMon = boost::make_shared<boost::thread>(boost::bind(&demoThread));

Demo u("world");

cout << u.rules.size() << endl;

thrMon->join();

return 0;

}

gcc boost版本冲突解决日记

时间: 2024-10-03 00:40:08

gcc boost版本冲突解决日记的相关文章

[转]SVN版本冲突解决详解

原文地址:http://blog.csdn.net/windone0109/article/details/4857044 版本冲突原因: 假设A.B两个用户都在版本号为100的时候,更新了kingtuns.txt这个文件,A用户在修改完成之后提交kingtuns.txt到服务器,这个时候提交成功,这个时候kingtuns.txt文件的版本号已经变成101了.同时B用户在版本号为100的kingtuns.txt文件上作修改,修改完成之后提交到服务器时,由于不是在当前最新的101版本上作的修改,所

svn冲突问题详解 SVN版本冲突解决详解

(摘自西西软件园,原文链接http://www.cr173.com/html/46224_1.html) 解决版本冲突的命令.在冲突解决之后,需要使用svnresolved来告诉subversion冲突解决,这样才能提交更新.冲突发生时,subversion会在WorkCopy中保存所有的目标文件版本(上次更新版本.当前获取的版本,即别人提交的版本.自己更新的版本.目标文件. 开发人员都知道代码管理工具是开发中一个必不可少的工具,这里也不废话详细介绍了.不管你个人喜欢git还是svn还是其他,但

SVN版本冲突解决详解 - snwrking的专栏 - 博客频道 - CSDN.NET

版本冲突原因: 假设A.B两个用户都在版本号为100的时候,更新了kingtuns.txt这个文件,A用户在修改完成之后提交kingtuns.txt到服务器,这个时候提交成功,这个时候kingtuns.txt文件的版本号已经变成101了.同时B用户在版本号为100的kingtuns.txt文件上作修改,修改完成之后提交到服务器时,由于不是在当前最新的101版本上作的修改,所以导致提交失败. 版本冲突现象: 冲突发生时,subversion会在当前工作目录中保存所有的目标文件版本[上次更新版本.当

SVN版本冲突解决详解

版本冲突原因: 假设A.B两个用户都在版本号为100的时候,更新了kingtuns.txt这个文件,A用户在修改完成之后提交kingtuns.txt到服务器,这个时候提交成功,这个时候kingtuns.txt文件的版本号已经变成101了.同时B用户在版本号为100的kingtuns.txt文件上作修改,修改完成之后提交到服务器时,由于不是在当前最新的101版本上作的修改,所以导致提交失败. 版本冲突现象: 冲突发生时,subversion会在当前工作目录中保存所有的目标文件版本[上次更新版本.当

转载&gt;&gt; svn冲突问题详解 SVN版本冲突解决详解

本文转自http://www.cr173.com/html/46224_1.html 解决版本冲突的命令.在冲突解决之后,需要使用svnresolved来告诉subversion冲突解决,这样才能提交更新.冲突发生 时,subversion会在WorkCopy中保存所有的目标文件版本(上次更新版本.当前获取的版本,即别人提交的版本.自己更新的版本.目标文件. 开发人员都知道代码管理工具是开发中一个必不可少的工具,这里也不废话详细介绍了.不管你个人喜欢git还是svn还是其他,但还有一大部分公司在

.Net Framework项目引用.NetStandard标准库出现版本冲突解决办法

今天在工作中出现一个引用问题,害我找问题找了很久.起因是在一个Winform项目下需要引用一个.NetStandard标准库,标准库引用了System.ComponentModel.Annotations程序集,版本是4.5.0,在Winform项目运行过程中抛出了以下异常: “未能加载文件或程序集“System.ComponentModel.Annotations, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3

SVN版本冲突解决

解决冲突有三种选择: A.放弃自己的更新,使用svn revert(回滚),然后提交.在这种方式下不需要使用svn resolved(解决) B.放弃自己的更新,使用别人的更新.使用最新获取的版本覆盖目标文件,执行resolved filename并提交(选择文件—右键—解决). C.手动解决:冲突发生时,通过和其他用户沟通之后,手动更新目标文件.然后执行resolved filename来解除冲突,最后提交.

Newtonsoft.Json 版本冲突解决

在做asp.net MVC 开发时,因为引用的dll 中使用了更高版本的 Newtonsoft.Json ,导致运行时发生错误, 查资料说是因为webApi使用了Newtonsoft.Json 导致了,我的项目中没有用到webapi,因此,在Global.asax 中把 下面这行代码屏蔽后,果然不再报错了. // WebApiConfig.Register(GlobalConfiguration.Configuration); 但是,当我在发布该项目时,又遇到了以下错误: 无法解决“Newton

新浪SAE部署:503 JDK版本冲突解决

上午把一个应用部署到SAE上,结果访问503错误.关键日志: ----------------------------------------------------org.eclipse.jetty.servlet.ServletHolder$1: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.web.servlet.mvc.