编译makefile的时候到make编译连接阶段总是提示,无法打开某某库或者某某库的格式不对(1 先看看32位,64位是否对应:BITS,cflags lflags....,2 是否将.OS .a等依赖库的目录导入变量LIBS) 然后看看是不是没有对应位数的编译工具, 需要安装 gcc-multilib 这个软件包,在Ubuntu 上安装这个软件包:sudo apt-get install gcc-multilibg++ 也同样如此sudo apt-get install g++-multili

gdb调试c程序打不到断点的原因可能是编译c文件的时候没有加-g选项,-g选项是编译加debug信息的,不加是打不到断点的 g++编译cpp文件 g++ -g -c *.cpp       编译 g++ -g -o exec *.o   链接 或 g++ *.cpp -o exec g++编译生成.a 静态库文件,.so为动态库 gcc *.cpp -lcp-demangle -o exec 选项 -l (ell) 通过添加前缀 lib 和后缀 .a 将跟随它的名字变换为库的名字 libcp-d

缘起,我的vs 2003无法新建工程,又不喜欢用vs 2013那样的重量级开发工具(就写两行代码,测试测试一些基本的语法规则或算法). 想来vs应该可以像GCC或G++那样直接用命令行编译Cpp文件,那样就省得我那么麻烦了. 我的步骤是这样的: 1. 打开Visual Studio .NET 2003 命令提示 进入cmd界面 2. cd  D:\proj2003\pureCode切换到cpp所在目录 D:\proj2003\pureCode>cl calcsize.cpp 3. 这样就会在当前

atom 有script插件可以直接调用很多编译器,试了很多次一直出问题找不到文件,查了文档之后发现script只支持OSX和linux. 所以,还是使用gpp-compiler比较靠谱 gpp-compiler 安装 安装MinGW编译器 主要是g++,具体模块另百度吧. 将g++.exe的位置添加到环境变量 E:\programfiles\MinGW-0.6.2\bin 在atom中,setting->install 搜索并安装gpp-compiler 打开cpp文件,f5编译运行 就这么就

在CentOS环境下编译CPP时报出 undefined reference to `__gxx_personality_v0' collect2: ld 以上错误,调查了一下,加上参数[-lstdc++]就可解决 例: gcc -lstdc++ a.cpp 参考自http://mlq.blog78.fc2.com/?mode=m&no=14

一.编写代码 1.打开命令行终端,输入vim test.cpp,新建了一个文件叫做“test.cpp”:如果以前已经建立过这个文件,则是打开这个名字的文件. 2.按回车进入编辑界面,输入i进入编辑模式,开始编写程序 3.程序写完之后, 按esc键退出编辑模式,回到命令行模式,在输入  ":w"表明存盘,然后输入“:q”退出vim编辑器:也可以直接输入“:wq”直接完成这两个步骤. 二.编译代码 在命令行输入  g++ -Wall test.cpp -o  test 编译代码    (注

直接在命令行窗口调用cl编译cpp文件 往往不能通过. 主要原因是一些头文件及可执行文件未在环境变量中设置.可以通过执行VSVAR32.BAT批处理文件来设置环境变量,注意vs2005跟2008的放置位置可能不同,如果不在cl.exe当前路径下,可以去/Common7/Tools目录下寻找. 批处理文件中主要是set命令临时配置的环境变量,所以开机之后需要重新运行该bat文件才能执行cl命令. 另附cl命令使用说明 CL.exe 是控制 Microsoft C 和 C++ 编译器与链接器的 32

今天在跑<Robust Object Tracking via Sparsity-based Collaborative Model>这篇文章的代码时候,发现出现如下错误: 发现错误时由于vgg_kmiter这个c类型的函数引起的,于是百度查看先关知识,原来是没有编译vgg_kmiter引起的错误,并且在此指出:由于高matlab版本不再支持mxCreateScalarDouble,而被变为mxCreateDoubleScalar,因而要把所有的cpp源文件中出现mxCreateScalarD

在Linux里面混了一个多月,vim编程用得甚爽.无奈前天将Linux里面的编程文件夹误删,而技术不精无法找回,悲痛欲绝.再者,无限怀念windows里面的游戏,并觉得现在在Linux里面也学不到什么东西,遂决定回到windows. 回到windows里面第一件事就是想把Linux里面的vim完美移植到windows.花了两天功夫,大部分功能已基本能够实现.当中遇到的最大困难是在windows里面实现用gcc/g++编译调试c/cpp文件,现在就把我这个过程完整记录下来. 1,首先下载安装Min

代码: CXX := g++ CFLAGS := -g TARGET := xxx.exe SRCS := $(wildcard *.cpp) OBJS := $(patsubst %cpp,%o,$(SRCS)) all:$(TARGET) %.o:%.cpp     $(CXX) $(CFLAGS) -c $< $(TARGET):$(OBJS)     $(CXX) $(CFLAGS) -o $@ $^ clean:     rm -rf $(TARGET) *.o 操作: make xx

2014-01-17 23:36 5128人阅读 评论(1) 收藏 举报 分类: 资料集(282) 版权声明:本文为博主原创文章,未经博主允许不得转载. 之前使用网上的一个开源代码,被封装成Windows DLL库提供给外部使用.由于项目需要,需要将代码封装成静态库.于是,创建了一个Win32的静态库工程,将开源中的.h和.cpp文件都添加到该静库工程中.但是编译时却出现了这样的错误:libdui\source\stb_image.c : fatal error C1853: “.\Debug\

今天大波又提起昨天我说的那个程序.这样的,起初我想写一个makefile,每次写完新代码后一键编译目录下所有的.cpp文件. 原因是用makefile的话,每次要把目标文件加紧去才能编译.感觉不方便.想写一个makefile,一劳永逸.每次写完新代码后直接编译,不用再加入目标文件. 但查了很多治疗,没发现能解决问题的代码.大波问我,干嘛不用shell写一个呢.所以,我暂时放弃makefile,用shell写了一个. 实现的基本功能:编译目录下所有.c和.cpp文件. 代码: #! /bin/ba

手工输入项目需要编译的cpp文件到Android.mk里的缺点 1)繁琐,如果cpp文件很多,简直无法忍受 2)手工输入过程中容易出现错误 3)如果cpp文件更改名称,需要修改Android.mk文件 ....等等 下面的样例代码转自:https://gist.github.com/andyque/6060595 [plain] view plaincopy <span style="font-family:SimHei;font-size:18px;">LOCAL_PAT

最近在看matlab code时,由于本人使用的是64系统,而code中的mex文件时在32位系统上编译的,所以需要重新自己编译maxflowmex.cpp,但是直接mex maxflowmex.cpp时,出现以下错误: maxflowmex.obj : error LNK2019: 无法解析的外部符号 "public: __cdecl Graph<float,float,float>::Graph<float,float,float>(int,int,void (__c

做了一个实验. 最后build失败,失败的原因是变量i被重定义了.原本按照我的思路,是不应该失败的.因为我用了条件编译,若先编译Source.cpp,则会#define __HEADER_H__并且定义变量i,等到之后再编译main.cpp时,由于已经定义__HEADER_H__,就会跳过变量i的定义.最终i只被定义一次,完美. 不管怎么说,编译器是不会出错的,仔细寻找一下原因吧.根据上面的实验结果可以推测出,两个cpp文件中#ifndef 和 #endif之间语句都得到了执行. 将上面的代码稍

1.多个cpp文件在同一级目录 参考:https://jingyan.baidu.com/article/2f9b480d7ceb3d01ca6cc224.html 此时可通过修改Code Runner的命令参数来编译. Code Runner右键 扩展设置,打开setting.json,如图修改为*.cpp,表示编译所有cpp文件. 这样操作只能编译所有cpp文件在同一目录下,对于多级目录,需要使用makefile或者cmake文件. 2.多个cpp在多级目录 参考:https://blog.

C++ Builder是最快的C++编译器之一,从编译速度来说也可以说是最快的win32C++编译器了.除了速度之外,C++builder的性能也在其它C++编译器的之上,但许多Delphi程序员仍受不了C++builder工程的编译速度.的确,delphi的速度要比任和c++的编译器都要快好多.Delphi在编译一个小工程的时候可能不到一秒,大的工程一般也在5秒钟这内编译完成了. 为什么delphi会比c++builder快这么多?是否有方法来c++builder的编译速度?本文就讲解了为什么

关于头文件和源文件的分别 首先,我们可以将所有东西都放在一个.cpp文件内. 然后编译器就将这个.cpp编译成.obj,obj是什么东西? 就是编译单元了.一个程序,可以由一个编译单元组成, 也可以有多个编译单元组成. 如果你不想让你的源代码变得很难阅读的话, 就请使用多个编译单元吧.(一个函数不能放到两个编译单元里面,但两个以上 就可以分别放在一个单元,也就是cpp里面) 那么就是一个.cpp对应一个.obj,然后将所有的obj链接起来(通过一个叫链接器的程序), 组成一个.exe,也就是程序

预编译头文件的由来 也许请教了别的高手之后,他们会告诉你,这是预编译头,必须包含.可是,这到底是为什么呢?预编译头有什么用呢? 咱们从头文件的编译原理讲起.其实头文件并不神秘,其在编译时的作用,就是把自己的所有内容直接“粘贴”到相应的 #include 语句处.其实,编译器在编译你的程序的时候,所做的第一件事,也就是展开所有的 #include 语句和 #define 语句. 头文件的出现,固然给书写程序带来了很大方便.可是到了 Windows 时代后,慢慢就呈现出一些问题了.几乎所有的 Win

编译Android源代码分为两种情况: 1. 完整编译源码: ./mk_aliphone.sh --> 完整编译脚本 --> 6735  输入对应的编号 --> userdebug adb new(-->remake) 上述指令流程后,若报错,则将错误解决后,执行. ./mk_aliphone.sh后开始编译流程 2. 源码编译完成后,单独编译模块: . ./build/envsetup.sh (当前目录:build/目录上级目录) --> 初始化环境的脚本:envsetup

最表面的机制是: 头文件是程序的界面(是代码界面),提供给程序员以  类.模版.函数等一系列的声明,让程序员知道应该怎么调用里面的"东西". 从动态链接库的角度看: 头文件提供界面,使得程序员在需要加载一个库函数的时候(这里也仅仅是举简单的例子)查看头文件就知道怎么加载这个动态库内部的函数. 从软件的扩展来说: 将头文件作为界面,再去定义它的实现,这样只要保证界面不变(头文件不变),就可以只修改实现文件,而不必修改其他的实现代码.比如你有一个sort()函数来排序,在一个大程序中,你后