本机编译工程和远程连接编译工程时，生成的执行文件大小相差很多

helenhf 2014-07-09 10:21:18

环境：BCB6.0 + TeeChart 7 + Visual Studio 2005
项目：BCB开发界面，使用TeeChart7绘制曲线；VC开发底层驱动，提供dll库给BCB调用；调用约定是stdcall；编译选项里use dynamic...和build with runtime package前的勾去掉了。除了主界面以外总共启动了11个线程用来访问驱动和更新界面上的数据显示。生成的执行文件是放在一个没有安装bcb的windows xp sp2上运行的。

直接在本机编译BCB工程时，生成的执行文件大小为2.77M，运行一段时间后错误百出，最常见的是某个刷新线程挂起，偶尔界面主线程会直接退出，还有RichEdit在Resize时会弹出Out of memory...的错误。

通过另外一台机器远程连接到本机上编译BCB工程时，拖拽一下主窗口的位置，保存工程并退出BCB，然后重新打开工程再次执行编译，生成的执行文件大小为2.72M，比上述2.77M的版本要稳定得多。

比较了一下两次编译生成的obj文件几乎完全一样，只有BCB安装目录下的vcl60.csm文件内容相差甚远。

求线索，远程上来到底有啥不同~~~

...全文

733 5 打赏收藏转发到动态举报

写回复

5 条回复

切换为时间正序

请发表友善的回复…

发表回复

宝龙哥 2015-09-23

打赏
举报

回复

将工程复制到那台完成编译的机器上看看效果如何

laowang2 2015-09-23

打赏
举报

回复

看看是不是硬盘出问题了，我上次编译的程序总是报内存错误，在虚拟机上编译一下又正常。

我不懂电脑 2014-07-09

打赏
举报

回复

还是检查代码，看有什么问题吧。

fxworld 2014-07-09

打赏
举报

回复

我觉的远程或本地编译本质上是相同的，因编译设置的不同会产生一些区别。 csm 文件只是一个预编译文件，目的只是加快编译速度，对编译结果不会产生影响。你描述的问题，应该是因多线程访问应受保护的对象的同步问题，应该由开发者在编码时考虑，和编译器一点关系都没有。

dataxdata 2014-07-09

打赏
举报

回复

怎样远程编译的？

范围：CPU上可以识别的代码和数据。全部的代码总和。要求：从定义开始的设计。完整性，彻底地定义从无开始的整个设计。这是因为软件之软，也是因为硬件平台的多样性和特殊性。完整把握，从头设计是第一原则。因为软件世界自己并不能统一，还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。在这样的视野下，操作系统只是一个部分，一个模块，不同的操作系统任你选择；语言的选择是运行环境的选择（每种语言有每种语言的运行时布局）；所谓框架只是“类库＋运行环境”的一种构造。没有对其负载能力、操作强度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范。性能：运行过程的收敛（长时间运行的均态）。操作强度设计（串行处理速度），负载能力设计（并发处理的量）。可靠性设计。软件问题的3个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU系统和数字加速硬件） 2、交互操作（界面），专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互），程控和网络访问的调度（服务器）。软件项目的3个部分：（把3个阶段由纵向横过来，进行统筹）分解文档，集成平台，可维护性要求。软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方，需要对文档进行恰如其分说明。原则是，每段代码，每处需要理解的地方，如果和总体架构相关，就要有说明。软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势，软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。软件只有一个，而观察的视角很多。要采用最适合的观察视角，让软件一目了然。软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果，研究报告反映；工程过程则必须采用过程刻画。软件规范使用的语言一定要有普遍语义，但描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体，才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要考虑纳入新的发展，那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义，越具体指导意义越大，但通用性则越小。所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此，不能规范具体的架构。到是可以做：应用架构规范的规范。逻辑架构的特殊性。可以判断，任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻辑。否则，软件不可能那么轻快实用。软件逻辑，鬼魅也。而需求分析，必须是现实实用的，而不是同构/仿真的－这似乎是反对象分析的。因为这里强调的是和软件的交互界面，这个界面远远没有反映现实世界的结构。须知，软件强调的是数据处理，是输入输出。否则，就不能达到最简化。可能现实世界的结构映射，最适合的方式是数据库－采用纯数据结构进行映射。除此之外，能有更合适的技术吗？面向对象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢？这再次表明，在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术，有它的有限性。也反映了，包含软件应用在内的现实架构已经固定。如果软件是数据处理，是输入输出，那么软件结构也就可以确定了！可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象，象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。工业控制也开启了新的软件世界，因为软件要从分离的输入建立“综合感知”，感知到设备状态，然后做出响应。软件有其固有的物理属性，也就是计算的量。算法领域，无论算法的论证多么曲折，求得的结果，物化为软件，总是“早已熟知”的软件。这一区分，是定义软件规范的基石。算法构造领域是和软件完全不同的领域，算法不是软件。算法类似数学系统。也一如数学系统那样多样。软件构造。算法总要转化为软件，这就是软件构造问题。寻址系统，数组。软件把自己的生成作为问题，给算法开辟了新的领域。软件生成，是一个“构造－编译”问题。手工构造，自动编译。语言的发展，是一个软件生成的历史。所谓统一建模，所谓设计模式，其实都是软件生成的问题。需求分析。需求分析本质上是独立的。所谓OOA，面向对象的建模，把程序构造概念上升到需求分析领域可能是不对的。一个先验的，复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握，难求对需求分析的创造性发展。需求分析应该专注于需求分析本身，独立发展，一切为了准确、快捷的分析。需求分析层次高一些，抽象一些，自由一些，这样可以充分表达需求的本质。反而可以促进更高级别的程序自动生成。软件生成的历史。软件生成是为了解决人机沟通，让“计算机语言”更接近普通人的思维逻辑。把这种“高级计算机语言”翻译成可以执行的代码，就是软件生成（代码生成）的任务。而软件编制是专业人员的事情，因此语言问题的本质其实不那么重要。须知，经过培训，莫尔司码的电报发报可以比说话的语速还快！因此，计算机语言的前途迷茫；实际上也确实迷茫，历史上语言的层出不穷本身就说明了问题，至今仍然如此。在当今，必须建立这样的观点：语言是因人而异的；面对一个语言的时候，要清醒，首先明确“这是为谁设计的语言”；也就是说，需求分析之前的需求是要明确，让什么人来设计软件，然后为他们选择合适的语言。软件生成除了代码生成，还包括另外一个意思：软件构造。这在前面已经论述过了。只是，这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制，产生大量的代码，应付实际问题的量。立体构造。这里还有一个立体问题，实际问题的构造可能产生立体构造，如同建筑，基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里，没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来，带来的问题是：这个构造本身必须能够证明自己是正确的。1）能产生软件2）构造逻辑上正确，确实能解决应用问题。构造本身有一个属性，它有通用性。根本原理是通用的；总体构造本身具有一般性，也就是抽象性、实际问题无关性；局部构件具有通用性。也就是说，这里存在容器和容量的区别，构造是容器，实际问题是装在容器中的量。一个好的容器要能顶住容量的压力；一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的，只与架构本身有关。这也就是说，架构本身自我构造的，因此也就是科学。可能软件构造本身是澄清问题的工作，明确“容量”的特点，为软件构造的选择提供准确的依据，杀鸡不要用牛刀。实际问题的“容量”很容易测量，因为它反映为应用的规模，流程的流量。（架构是什么？架构是否存在？如果我们所说非虚，那么如何为架构下一个定义－一定是一个由具体业务流量和模式支撑的架构）软件（算法）的构造。一个是数据的复杂性（内在互相关系），一个是计算方法（步骤和缓冲）。从宏观角度，数据关系是更根本的东西。目前的高级语言，变量和流程（顺序、分支－步骤；循环－缓冲和迭代）研究的多，而数据复杂性构造不足。同构现象。CPU指令集合可以说是硬件直接实现的软件。软件帝国从这里提取软件精神，并升华它。从硬件的角度，从寄存器和指令执行流程，体现出的是变量和迭代（顺序更迭，循环往复）。（迭代流程）基于固定寻址的变量，经过寻址接口，可以处理任意数据，从而把迭代流程变成了一般流程。CPU的基本过程，产生了指令和数据，指令天生具有子程序的基因（一般流程），数据天生具有数据结构（寻址能力）的基因。高级的构造一般也是这种结构的类似：设计一套类似CPU的机制，支撑程序和数据；独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制；迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础。抽象是数据化的工厂，也因此必须研究抽象技术。抽象技术。所谓抽象，就是具体化，是范围的界定和比对（两种具体化对象之间的比对）。如果范围界定的完整，那么比对建立的联系就是普遍联系，普遍联系也就是所谓抽象原则。评价标准。软件架构需要评测。这种评测是“在商言商”似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法，每种架构本身也就具体化，是一种具体的架构。一种具体化的架构，就可以识别；可以识别则可以客观评测。可以按照立体架构的“压力”、“流量”等概念进行评测。需求的把握－需求的变化。我们希望永恒不变的需求，核心需求和需求方式（表现和满足步骤）；而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤，需求源于现实核心深处，软件是一件衣服。这种观点下，软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。软件和算法的分开软件的构造作为软件的通用属性需求的独立推论：算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分，因为它是通用的软件构造技术。计算技术和应用之间有明显的区别，是两种不同的成分。软件规范是纯粹的，只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了（也就是怎么自动计算，或者说什么是可计算的），剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。所谓算法，就是明确问题，然后发现用自动计算的方式解决问题。从这个意义上说，软件是应用问题导向的。那么，也就是要以问题为中心谈论软件。不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术。所以，区分软件计算技术和应用问题的成分，是软件规范需要首先识别的东西。解决问题。本质上是把问题装到变量里面的过程，是放大CPU寄存器的过程。表示层：（把局面、环境；起点和终点需要定义在一个世界里）装进去，组织起来。计算层（展开层）：基于表示，定义问题解决步骤（定义运动和过程）。需求分析。问题描述采用的方法可能应该和软件算法完全分开。否则不能发现问题描述的创造性方法，不能表达问题本质。阐述问题，写文章我们有某篇布局之法；哲学研究我们有严谨的逻辑方法。需求分析，我们一定可以创造自己的方法。这是什么方法？满足使用要求，满足使用流程。离散/隔离各个需求。事实上，面向外部的分析理解和面向内部的分析理解之间有鸿沟。因为这是两个不同的世界。在两个相差悬殊的世界之间，搭建的构造也必然多种多样，以奇为平常。那么，建立联系的媒介少的可怜。可能问题本身也正在于这种联系的分析和设计。软件的量，是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分。软件的出现不仅仅是被动地适应显示需求，同时也改变了现实需求本身。这种和现实需求融合在一起形成的状态，正是软件活跃的部分。在以前，仅仅以“应用软件”指称是不够的。（操作系统、编译软件、应用软件）在范畴上，分为三个层次，或说3个范畴域： 1、活跃的、黏性的动态层次。应用层。和现实之间的界面，是设备逻辑。需求简化、解决方案的奇异性；应用算法的专业性。这是软件形象最活跃的部分。这里用的是抽象（业务流程）和具体（设备能力）统一的思维方法，构造逻辑的软件过程同时又是可以用具体进行描述的；动态的、物理的分析手段（物理的量）。业务流程的设计几乎就是艺术设计。 2、中间层。程序构造层。语言、编译技术、数据结构、设计方法（过程、数据、对象）等可以形式化的计算机科学的任务。对程序能力进行抽象，设计程序自动化生成的一套系统：语言、计算系统、编译系统。这是在静态和活跃部分之间的层次。这里的观念：设计方法、主程序、程序过程（和应用层的过程不是一一对应的）。 3、静态层。软件的量，度量层。所有程序构造过程的差别消失了。这是软件的静态观点。每层都有对软件的自己的理念，概念、过程和模型。两个层的对比，则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方。在应用层，抽象的、逻辑过程强一些。想象的部分占据主要的部分。需要对现实的业务，基于设备的具体能力，进行构造。 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”，而第2层论述的是“程序”。软件和程序的研究方法不同。程序研究方法是完备的，而软件不完备。程序开发应当体现软件特性。1）是逻辑的过程，总体的过程和子过程的观察和校验程序。2）软件的量层次上，软件的规模、运行强度和稳定性指标的自测试程序。第二阶段一定要有一个标准。软件如衣服，软件的交付文档应当显示出衣服是如何编织起来的。（相对于需求，软件是衣服，非核心；相对于硬件，软件是衣服，包裹）要有一个理论说明。架构也是衣服的一个部件，类似衣服的连接方式，模块集合的重心比对。衣服是一个没有核心的结构。软件也一样要显示出这个特性。无论如何，我们需要有观察软件的眼光，无论一套软件依据什么样的理论产生。什么是软件？描述是软件的存在形式（文本格式）。软件一定是可执行的（这是软件的严肃性，精确、定量）。软件是异化的，一般异化为具体、特例（对抽象力最好的归结方式）（没有完美满足需求的软件，相对于需求，软件只能满足固定的需求，而不能满足需求的变化，即一款软件总是具体的；由一般产生出具体的思考方法，也就是构造的方法；或着是磁力打造，一个好的理论一定对现实素材有吸引力，向磁铁一般；这也是在矛盾中建造现实的方法，只要是具体的就肯定是可以分析出潜在矛盾、不完美的，问题不仅仅是分析、认识现实，还要能够构造现实；不存在完美的现实，只存在完美的理论科学研究的方法是简化。工程的方法是‘相似’，复制发现事物时的状态，那么事物的表现就会复现。在具体化这里，软件和硬件工作的方法在结果上实现了一致。只是方向不同，软件是从一般进行到具体；硬件一开始就是从具体出发，层层构造，搭建系统。硬件的设计明显具有以工艺、器件为核心的特征。配合器件的特新，进行外围设计。在硬件领域，是‘具体’为上；在软件领域，是‘具体’为下。）对具体性的解释：组成所有物资的电子、质子、中子是圆的、相同的，但是这些相同的东西组成的原子则有几百种不同。每次量的规模的添加，都导致特殊性的添加。对于软件来说，也是如此。如下的概念是母庸质疑的，软件如同大山，沟壑鲜明。（这种巨大的特殊性，一定是和巨大的需求特殊性相应的）。 “软件以文本形式存在；软件在执行着；软件以个例的形式存在”，归结为在一起就是“软件是具体的”。低一级别的定义：软件与数据和逻辑相关（数据和逻辑是软件的基本语义）。软件与过程相关（积分（存储，数据的数据化）和步骤（逻辑）；过程是步骤的遍历，是数据的消长变化）。执行的异化。区分独立执行和整体执行的概念。独立执行的代码称为模块，否则只是‘片段’。独立性和数据完整性相关，数据越庞大那么不独立的代码片段越多，模块就越大。模块独立性具有比和整体执行所要求的更大的自由度，也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量；模块的执行设计应该为了获取更大的自由度；自由度是模块可执行性质量的评定指标。对于整体执行的设计来说，自由度设计可能是设计过程的主导方法，它和全面、完整的需求理解相关，也和需求变化相关；因此自由度设计也是需求定位的设计。软件的量，也就是软件的能力。这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等。软件是运行的，软件是自我构造的，软件的全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的。需要构造在功能层次上的互相配合，解释这种完整性。显然每个部分都具有独立的完整性；完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性。反过来，系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质。这好比太极拳，要在一个完满的氛围里运动。软件能力是比代码高一个级别的抽象。又是构成软件内涵的基础语义。 ‘设备能力’的概念更基础，可以统一所有其它能力；又可以作为以硬件为中心的观念的基础。能力的获得在于‘二分’。在于互相支撑的界面，支撑在一起的双方互为能力。 1．所谓需求分析，我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析。借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求，分析需求。因为领域、术语、行业表述习惯的原因，这个阶段千差万别。 2．其次是电脑的使用方式－电脑技术（外设、通信和电脑本身的硬件形态），尝试去设计合适的使用方式和硬件解决方案。这里有使用环境、专业技术、成本、时间，以及个人习惯等原因，同样是一个精彩的过程。对领域工作方式的熟悉、外设相关的专业技术背景、折中技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定。 3．进一步，确定使用者角色。使用者和使用地点关联。使用地点也就是前面电脑使用方式的一部分。这是一个沟通过程，也是对有了电脑辅助参与，相关领域习惯改革的问题。 4．然后，进入二元分析阶段：使用者管角度、客观功能角度，分析功能，并完成二者之间的映射。这个阶段，功能被量化。职能量化。职能和功能之间会有模糊，有授权的转移。这个阶段就是充分考虑这些问题。 5．然后，进入传统的需求分析阶段。计算架构和功能描述的规格分析。使用者界面规划（详细、规格级别）。界面规划、功能、架构三者之间组成互动的具体化过程。最后会产生系统级别的文档。运行实体、接口；系统运行态、实体接口的输入输出规格。 6.然后，实体级别的程序构造阶段。算法构造和程序构造。主要是从资源占用的角度确定宏观的算法。在这个阶段，是程序文档化阶段。文档这个属于是这个阶段的工具。最后会产生严格的程序模块的文档。所有这些文档组合起来，可以构成运行流程。这些文档化的程序就是逻辑化的程序本身。 7.最后，编码阶段用一种具体的语言，按照模块文档的接口、资源、算法要求，编制代码。

使用git管理KEIL5工程的忽略文件前置知识使用KEIL5开发stm32比较方便，在程序编译、连接等中间过程中会产生很多无用文件。比如一个STM32项目正常编译通过后整个项目大小为：使用正点原子提供的keilkill.bat执行无用文件删除后文件大小为：可以看出体积相差10倍多，一般为了备份保存，我们只需要保存执行完keil killbat的项目文件夹即可。注意：删除无用文件后，不...

12年嵌入式开发，一直在一线做产品研发，深深明白，看懂编译流程，掌握代码是如何编译非常重要做一个芯片方案，从拿到资料和代码开始，第一件事就是编译代码，解决编译问题另外，看懂代码也必须看懂编译过程，哪些参与编译，哪些在什么条件编译其次，根据不同产品方案，一定要修改代码，不可避免要修改编译脚本很多同学只懂得简单的添加一个编译驱动，如何选择配置文件，内核这套编译体系工作的本质非常模糊或者不清楚。本课程分析内核vmlinux生成规则，单个文件如何生成，内核模块的生成，整个kernel的编译体系，让你对内核有更深入的掌握。

编译 OpenWrt 的过程就像是复读机，除了选择系统组件外，几乎每次编译都是复制粘贴相同的命令。而理解每一条命令的作用、什么时候该去执行，这样才能更好的去解决编译中遇到的问题，更顺利的编译出固件。

作者简介小明，携程移动开发工程师，专注于移动端框架和基建开发；黄拉欢，携程移动开发经理，专注于移动端框架建设及性能调优。一、背景Android 项目一般使用 Gradle 作为构建打包工具，随着业务需求的不断迭代，代码量提升的同时，Gradle 编译耗时也在不断的增长，而编译速度会直接决定开发流程效率的高低，影响面主要涉及到开发和测试阶段。对于火车票项目，经过长期的迭代过程导致模块众多工程庞大...

VCL组件使用和开发

604

社区成员

13,460

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章