欢迎来到皮皮网网首页

【代练源码后台】【android生活源码】【ihuan源码代理】重载内核 源码_重载内核 源码是什么

来源:个人网站引导页源码 时间:2024-11-23 16:58:39

1.nestjs和eggjs哪个好?
2.如何为嵌入式开发建立交叉编译环境

重载内核 源码_重载内核 源码是重载重载什么

nestjs和eggjs哪个好?

       nestjs为什么不火

       因为操作不简便

       Nest.js是用于构建高效且可伸缩的服务端应用程序的渐进式Node.js框架。支持Typescript、内核内核面向AOP编程、源码源码支持typeorm、重载重载Node.js版的内核内核spring、构建微服务应用。源码源码代练源码后台

       Nest.js是重载重载用于构建高效且可伸缩的服务端应用程序的渐进式Node.js框架。支持Typescript、内核内核面向AOP编程、源码源码支持typeorm、重载重载Node.js版的内核内核spring、构建微服务应用。源码源码

       年前端最火的重载重载技术是什么?

       我认为的年前端开发者最应该掌握的一些比较火爆的技术与知识点。

       1,内核内核前端框架和语言层面

       9月份Vue3.0发布,源码源码声称对TypeScript有着更好的开发体验,通过从不同框架级别TS支持上,我们可以看出社区的整个风向从年的大家都去学习应用TS,变成了大家如何把TS用的更好这个方向上来了。

       所以我认为今年TypeScript的火热程度还是应该排名很靠前的,我今年也使用TypeScript重构了Daruk的服务框架推出了2.0版本,让TS开发者拥有更好的TS开发体验。

       接下来就是两大重磅框架的更新历程对比,Vue3前面说了一句。而React也在十月也发布了React的release版本。这两大主流框架的频繁更新,也说明了社区和作者都在一同演化。

       在Vue3中除了更好的支持TS外,还更新了CompositionAPI。而React主要是集中精力在升级体验上,虽然没有新的Feature但是提升了和解决了很多之前版本潜在的问题。

       要说哪个最火还是要看个人实际的使用场景和喜好,但是年来看还没有别的框架可以与之一战。

       2,大前端相关技术栈

       今年基于Chromium的微软edge浏览器也已经推出。google在web端的android生活源码发展产生了对开发者深刻的影响。Chrome+也已经发布多个版本,提供了一系列的新特性,比如CoreWebVitals标准,DesktopPWA等都值得我们去关注。

       我们说完了浏览器相关的那点技术之后,再聊聊大前端相关的一些技术实践,比如Flutter。

       很多前端在今年已经从web开发转型为Flutter开发,学习和使用Dart技术来构建UI,这是很多大厂的前端工程师正在经历的事情(包括我的部门也在尝试这个事情),这个趋势应该在未来几年还会持续。

       客户端electron在今年也有着长足的进展,一年内多次更新版本一路到了.1.5。随着疫情影响,国内在线教育的又一波兴起。很多桌面软件,网课软件都在采用这个技术来进行开发,市场上的岗位也开始变多,electron技术可以说在今年也有火的趋势。

       然后我们再看看BFF层,nestjs依然坚挺,越来越多的人开始跳过学习express和koa开始学习更丰富的web框架了,比如egg或者我的daruk,开发者已经在慢慢形成共识,在webframework的路上开始越走越远,裸写nodejsweb服务的时代已经开始慢慢褪去。

       不得不提的还有serverless在前端的普及,在年到达了一个新的高潮。阿里云,腾讯云,头条云等等国内的互联网厂商也都开始大玩serverless概念。从对内服务开始转向对外服务,普及的势头很猛,也有落地的趋势和场景。今年的ihuan源码代理D2同样也有serverless的专场,可见受重视程度非比寻常。

       3,工程化提效和个人素质提升

       再离我们近一些的推动生产力的技术,比如据我所知在用CI/CD和pipeline管理上线流程的公司越来越多,这种去年还可以出去吹一吹的东西,今年也逐步变成了业界标配基础能力,如果不会的同学可要抓紧学习了。

       年前大家都疯狂吐槽面试刷medium题目没用,而年后大家开始默认面试某些公司都至少要刷到medium程度的题目。这对很多前端来说是一个心智和素质的提升与转变,大家在接触新技术的同时,也慢慢发现,前端整个职业环境的变化,越来越多的公司对人的整体综合素质要求变高了。

eggjs为什么口碑不好

       质量问题。eggjs为什么口碑不好的原因是质量问题,因为eggjs质量差,售价高。口碑,指众人口头的颂扬,泛指众人的议论;群众的口头传说,相当于一种大众嘴边经常提起的事情或组织。

NG全家桶全栈项目实践总结

       Angular在国内使用的人并不像国外那么多,基本都是外企在用,但其框架的思想却仍可以为我们所借鉴,在某些问题没有思路的时候可以参考ng相关的处理,ng处理方式和思维确实比较超前,但也因此而曲高和寡。本文旨在通过ng全家桶项目(前端Angular+后端NestJS7)的实践来总结对于ng架构中一些亮点的关注与思考,Angular和Nest在前后端框架的处理上同出一脉,对比起来更有借鉴意义。

       [目录结构]

       [目录描述]

       整个前端项目是基于angular脚手架生成的,其基本目录结构是在src的app下进行相关组件和页面的模块开发,main.ts和index.html是整个单页应用的主入口,根目录下angular.json用于配置相关的idea源码导出打包编译等环境配置参数

       [实践分享]

       [目录结构]

       [目录描述]

       后端项目是基于nestjs框架的大型后台项目配置,api模块主要是对外输出的接口,auth、filters、guard、interceptors、middlewares、pipes等是对于需要的模块进行统一的收集处理,main.ts是主入口文件,用于启动及相关配置等,app.module.ts是用来收集所有模块的导入,ng基于模块的方式可以起到非常好的隔离效果

       [实践分享]

       首先,对于没有用过ng的同学科普一下,angular其实分为两个大版本,一个是angular1.x的,也就是ng1,也就是现在还有的angularjs,另一个版本是ng2以后的版本,ng2之后被谷歌收购后,完全重写了框架,唯一和1.x相通的估计也就剩那几个思想还在了:模块化、依赖注入、双向绑定、MVC,对于1.x感兴趣的同学可以去看Vue的1.x的版本,基本算是简化版的ng1.x,Vue2之后就和后来的ng分道扬镳了,vue2主要是以发布订阅来替代依赖注入的思路,扯远了...(ps:想看ng1版本的可以看这个地址,居然还有更新...angularjs官方仓库),这里分析的主要是Ng,ng8之后除了引入Ivy(Ivy架构官方介绍)这个编译渲染器之外,其实改动不大,主要就是在优化以及废除和新建一些api等等。Ng的源码很庞大,goggle自研了一个bazel自动化构建工具,高级论坛源码ng自然也是靠这个构建的,对bazel感兴趣的同学,可以看这个Google软件构建工具Bazel原理及使用方法介绍,我这里就不展开所有的源码,整体的核心大框架如下:

       nestjs是nodejs的web应用的一个大的集成,它最初是基于express封装的一个后端框架,后来将服务端各种理念都使用js实现了一下,虽然不能和成熟的服务端语言框架如java等进行媲美,但是服务端所需要的东西基本都具备了,对于有需求想要使用js来开发后端的同学是个不错的选择,个人认为简单的bff,比如想自己模拟的开发个后台接收请求,选择node直接写或者使用express、koa就可以,对于有一定的中间层给前端处理,可以选用阿里的egg,对于如何基于egg构建中间层,可以看看这篇文章如何为团队定制自己的Node.js框架?(基于EggJS),对于大型的服务端,尤其是前端是以ng为主栈的,可以优先考虑使用nestjs;其次对于io较多而计算较少的(js本身的特质),或者服务端需要与c++配合的,大型服务端应用也可以使用nest。nest默认是不采用微服务的形式的,nest将不同的平台封在了不同的platform下,这里只分析普通的以express为platform的形式,对于喜欢微服务的同学,可以对比和java的springcloud的区别,这里就不做表述了,其整体的核心结构大致如下:

       这里主要在对依赖注入的实现做一个简单的理解分享,其思路是一脉相承的,对于理解后端理念的依赖注入有很好的理解,这也正是后端前端化的一个体现,也是最早的MVC框架向后来的MVVM框架过度的一个历史过程,依赖注入方式对于最早的前端框架还是有纪念意义的,但是对于ng全家桶来说,这算是其基本哲学的一个基本面

       bAngular/b

       先来看一下ng是如何实现injector的,这里重点在于使用了抽象类来重载不同函数的使用,对于provider循环依赖的处理,利用了一个Map数据结构来区分不同的Provider

       bNest/b

       再来看一下,nest的实现,不同于ng的实现,nest是利用参数和继承父类参数来确定整个的循环依赖关系的,其没有使用重载来实现,但都对循环依赖做了处理,其基本思路是一致的。

       总结:从nest和ng对injector的实现可以看出,虽然都是注射器的实现,但是由于呈现方式的不同,因而在实现方式上也会有所不同,对于ts而言,选用interface还是抽象类,确实可以借鉴java的模式思路,对于习惯js的我们来说,对于整个数据类型的扩展(如:抽象类、接口)等是需要向后端借鉴的。整体来说,对于依赖注入的实现最关键的就是在于处理provider的整个依赖问题,这两者都是采用token的方式来区分对待到底是属于哪一个provider,然后对于特殊的相关依赖循环的问题做对应的处理

       ng整个生态体系在国内应用的并不广,但并不妨碍其作为前端理念的扩展先行者的这样一个角色,个人认为其在隔离性以及系统性方面都是要优于vue和react的,因而对于目前比较流行的微前端框架(ps:对于ng的微前端应用,可以参考这篇文章第期使用Angular打造微前端架构的ToB企业级应用),个人觉得在沙箱隔离等系统融合方面确实可以借鉴一下ng的某些思路,或许正是由于这个原因,它才是三大框架中最先上ts的,也有可能整个ng的开发者更像是传统的软件工程师,对于整个开发要做到定义数据、定义模型、系统设计等等,对于大型项目而言,这样确实会减少很多因bug而需要重复修改的时间,但是对于小型项目,个人认为还是vue更合适。虽然对于国内,ng基本已经属于明日黄花了,但是它的一些理念及设计思路确实还是值得借鉴的,在这个内卷的时代,各大应用都在向着高级化、大型化发展,说不定哪天ng又在国内重回巅峰了呢,虽然很难~~哈哈哈,各位加油!

北大青鸟设计培训:node编程开发技术的发展趋势?

       node技术成为web前端领域的主流开发工具可以说本身就是一个美丽的误会,当初这个技术被开发出来使用的时候主要是为了解决后端的问题才出现的。

       今天,济南java课程培训机构就一起来了解一下node技术的发展历程和未来的发展趋势。

       a)Node8进入LTS时代Node.js大的变化是进入Node8时代,它是一个稳定的长期支持版本(LTS),除了性能提升外,还有以下几个要点。

       Async/Await支持。

       其实在Node.jsv7.6就可以通过flag支持了,在node8里直接落地。

       通过Async函数可以更好的进行异步流程控制,远离CallbackHell。

       在Async函数里,你可以通过await调用Promise,以及通过co包裹的generator,可以说,向前是完美的Async函数,向后也完美兼容各种遗留代码,称为异步终极解决方案不为过。

       ES6模块支持。

       通过vue/react、webpack、babel和typescript等火爆发展,es6模块得到了广泛普及和应用,在Node.jsv8.5可以通过--experimental-modules来开启这个体验版特性。

       当然,你想在Node.js更早版本里使用ES6模块,可以采用@std/esm模块。

       HTTP2支持。

       在Node.jsv8.8就开始默认启用了,http2对服务器端推送,多通道复用等特性,能够更好地为浏览器便利,是性能优化的利器。

       b)企业级Web开发基础框架除了应用广泛的主流Web框架Koa外,Fastify也是一直劲敌,作者MatteoCollina是Node.js核心开发,Stream掌门,性能优化专家。

       Fastify基于Schema优化,对性能提升极其明显。

       狼叔认为这是企业级Web开发,他在这里给我们介绍了3个知名框架。

       b1)Egg.js阿里开源的企业级Node.js框架Egg发布2.0,基于Koa2.x,异步解决方案直接基于AsyncFunction。

       框架层优化不含Node8带来的提升外,带来%左右的性能提升。

       Egg采用的是『微内核+插件+上层框架』模式,对于定制,生态,快速开发有明显提升,另外值得关注的是稳定性和安全上,也是极为出色的。

       b2)NestNest是基于TypeScript和Express的企业级Web框架。

       很多人开玩笑说,Nest是像Java开发方式的,确实,Nest采用TypeScript作为底层语言,TypeScript是ES6超集,对类型支持,面向对象,Decorator(类似于Java里注解Annotation)等支持。

       在写法上,保持Java开发者的习惯,能够吸引更多人快速上手。

       TypeScript支持几乎是目前所有NodeWeb框架都要做的头等大事,在年Nest算个知名项目,值得一提。

       b3)ThinkJSThinkJS是一款拥抱未来的Node.jsWeb框架,致力于集成项目佳实践,规范项目让企业级团队开发变得更加简单,更加高效。

       秉承简洁易用的设计原则,在保持出色的性能和至简的代码同时,注重开发体验和易用性,为WEB应用开发提供强有力的支持。

       ThinkJS是国产老牌Web框架,在年月发布v3版本,基于Koa内核,在性能和开发体验上有更好的提升。

       整体来看,Node.js在企业Web开发领域日渐成熟,无论微服务,还是Api中间层都得到了非常好的落地。

       年,唯一遗憾的是Node.js在servless上表现的不太好,相关框架实践偏少。

       c)不可不见的Api中间层前端越来越复杂,后端服务化,今日的前端要面临更多的挑战。

       一个典型的场景就是在服务化架构里,前端面临的头痛的问题是异构API,前后端联调的时候,多个后端互相推诿,要么拖慢上线进度,要么让前端性能变得极其慢。

       进度慢找前端,性能差也找前端,但这个锅真的该前端来背么?Node.js的Api中间层应用很好地解决了这个问题。

       后端不想改的时候,实在不行就前端自己做,更灵活,更能应变。

       透传接口,对于内网或者非安全接口,可以采用中间层透传。

       聚合接口,对异构API处理非常方便,如果能够梳理model,应变更容易。

       Mock接口,通过Mock接口,提供前端开发效率,对流程优化效果极其明显,比如去哪儿开发的yapi就是专门解决这个问题的。

       除此之外,前端如果想做一些技术驱动的事儿,SSR(服务器端渲染)和PWA(渐进式Web应用)也是非常不错的选择。

       d)新领域(深度学习、区块链等)

如何为嵌入式开发建立交叉编译环境

       ã€€ã€€ä¸‹é¢æˆ‘们将以建立针对arm的交叉编译开发环境为例来解说整个过程,其他的体系结构与这个相类似,只要作一些对应的改动。我的开发环境是,宿主机 i-redhat-7.2,目标机 arm。

       ã€€ã€€è¿™ä¸ªè¿‡ç¨‹å¦‚下

       ã€€ã€€1. 下载源文件、补丁和建立编译的目录

       ã€€ã€€2. 建立内核头文件

       ã€€ã€€3. 建立二进制工具(binutils)

       ã€€ã€€4. 建立初始编译器(bootstrap gcc)

       ã€€ã€€5. 建立c库(glibc)

       ã€€ã€€6. 建立全套编译器(full gcc)

       ã€€ã€€ä¸‹è½½æºæ–‡ä»¶ã€è¡¥ä¸å’Œå»ºç«‹ç¼–译的目录

       ã€€ã€€1. 选定软件版本号

       ã€€ã€€é€‰æ‹©è½¯ä»¶ç‰ˆæœ¬å·æ—¶ï¼Œå…ˆçœ‹çœ‹glibc源代码中的INSTALL文件。那里列举了该版本的glibc编译时所需的binutils 和gcc的版本号。例如在 glibc-2.2.3/INSTALL 文件中推荐 gcc 用 2.以上,binutils 用 2..1 以上版本。

       ã€€ã€€æˆ‘选的各个软件的版本是:

       ã€€ã€€linux-2.4.+rmk2

       ã€€ã€€binutils-2..1

       ã€€ã€€gcc-2..3

       ã€€ã€€glibc-2.2.3

       ã€€ã€€glibc-linuxthreads-2.2.3

       ã€€ã€€å¦‚果你选的glibc的版本号低于2.2,你还要下载一个叫glibc-crypt的文件,例如glibc-crypt-2.1.tar.gz。 Linux 内核你可以从www.kernel.org 或它的镜像下载。

       ã€€ã€€Binutils、gcc和glibc你可以从FSF的FTP站点ftp://ftp.gun.org/gnu/ 或它的镜像去下载。 在编译glibc时,要用到 Linux 内核中的 include 目录的内核头文件。如果你发现有变量没有定义而导致编译失败,你就改变你的内核版本号。例如我开始用linux-2.4.+vrs2,编译glibc-2.2.3 时报 BUS_ISA 没定义,后来发现在 2.4. 开始它的名字被改为 CTL_BUS_ISA。如果你没有完全的把握保证你改的内核改完全了,就不要动内核,而是把你的 Linux 内核的版本号降低或升高,来适应 glibc。

       ã€€ã€€Gcc 的版本号,推荐用 gcc-2. 以上的。太老的版本编译可能会出问题。Gcc-2..3 是一个比较稳定的版本,也是内核开发人员推荐用的一个 gcc 版本。

       ã€€ã€€å¦‚果你发现无法编译过去,有可能是你选用的软件中有的加入了一些新的特性而其他所选软件不支持的原因,就相应降低该软件的版本号。例如我开始用 gcc-3.3.2,发现编译不过,报 as、ld 等版本太老,我就把 gcc 降为 2..3。 太新的版本大多没经过大量的测试,建议不要选用。

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€2. 建立工作目录

       ã€€ã€€é¦–先,我们建立几个用来工作的目录:

       ã€€ã€€åœ¨ä½ çš„用户目录,我用的是用户liang,因此用户目录为 /home/liang,先建立一个项目目录embedded。

       ã€€ã€€$pwd

       ã€€ã€€/home/liang

       ã€€ã€€$mkdir embedded

       ã€€ã€€å†åœ¨è¿™ä¸ªé¡¹ç›®ç›®å½• embedded 下建立三个目录 build-tools、kernel 和 tools。

       ã€€ã€€build-tools-用来存放你下载的 binutils、gcc 和 glibc 的源代码和用来编译这些源代码的目录。

       ã€€ã€€kernel-用来存放你的内核源代码和内核补丁。

       ã€€ã€€tools-用来存放编译好的交叉编译工具和库文件。

       ã€€ã€€$cd embedded

       ã€€ã€€$mkdir build-tools kernel tools

       ã€€ã€€æ‰§è¡Œå®ŒåŽç›®å½•ç»“构如下:

       ã€€ã€€$ls embedded

       ã€€ã€€build-tools kernel tools

       ã€€ã€€3. 输出和环境变量

       ã€€ã€€æˆ‘们输出如下的环境变量方便我们编译。

       ã€€ã€€$export PRJROOT=/home/liang/embedded

       ã€€ã€€$export TARGET=arm-linux

       ã€€ã€€$export PREFIX=$PRJROOT/tools

       ã€€ã€€$export TARGET_PREFIX=$PREFIX/$TARGET

       ã€€ã€€$export PATH=$PREFIX/bin:$PATH

       ã€€ã€€å¦‚果你不惯用环境变量的,你可以直接用绝对或相对路径。我如果不用环境变量,一般都用绝对路径,相对路径有时会失败。环境变量也可以定义在.bashrc文件中,这样当你logout或换了控制台时,就不用老是export这些变量了。

       ã€€ã€€ä½“系结构和你的TAEGET变量的对应如下表

       ã€€ã€€ä½ å¯ä»¥åœ¨é€šè¿‡glibc下的config.sub脚本来知道,你的TARGET变量是否被支持,例如:

       ã€€ã€€$./config.sub arm-linux

       ã€€ã€€arm-unknown-linux-gnu

       ã€€ã€€åœ¨æˆ‘的环境中,config.sub 在 glibc-2.2.3/scripts 目录下。

       ã€€ã€€ç½‘上还有一些 HOWTO 可以参考,ARM 体系结构的《The GNU Toolchain for ARM Target HOWTO》,PowerPC 体系结构的《Linux for PowerPC Embedded Systems HOWTO》等。对TARGET的选取可能有帮助。

       ã€€ã€€4. 建立编译目录

       ã€€ã€€ä¸ºäº†æŠŠæºç å’Œç¼–译时生成的文件分开,一般的编译工作不在的源码目录中,要另建一个目录来专门用于编译。用以下的命令来建立编译你下载的binutils、gcc和glibc的源代码的目录。

       ã€€ã€€$cd $PRJROOT/build-tools

       ã€€ã€€$mkdir build-binutils build-boot-gcc build-gcc build-glibc gcc-patch

       ã€€ã€€build-binutils-编译binutils的目录

       ã€€ã€€build-boot-gcc-编译gcc 启动部分的目录

       ã€€ã€€build-glibc-编译glibc的目录

       ã€€ã€€build-gcc-编译gcc 全部的目录

       ã€€ã€€gcc-patch-放gcc的补丁的目录

       ã€€ã€€gcc-2..3 的补丁有 gcc-2..3-2.patch、gcc-2..3-no-fixinc.patch 和gcc-2..3-returntype-fix.patch,可以从 http://www.linuxfromscratch.org/ 下载到这些补丁。

       ã€€ã€€å†å°†ä½ ä¸‹è½½çš„ binutils-2..1、gcc-2..3、glibc-2.2.3 和 glibc-linuxthreads-2.2.3 的源代码放入 build-tools 目录中

       ã€€ã€€çœ‹ä¸€ä¸‹ä½ çš„ build-tools 目录,有以下内容:

       ã€€ã€€$ls

       ã€€ã€€binutils-2..1.tar.bz2 build-gcc gcc-patch

       ã€€ã€€build-binutls build-glibc glibc-2.2.3.tar.gz

       ã€€ã€€build-boot-gcc gcc-2..3.tar.gz glibc-linuxthreads-2.2.3.tar.gz

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€å»ºç«‹å†…核头文件

       ã€€ã€€æŠŠä½ ä»Ž www.kernel.org 下载的内核源代码放入 $PRJROOT /kernel 目录

       ã€€ã€€è¿›å…¥ä½ çš„ kernel 目录:

       ã€€ã€€$cd $PRJROOT /kernel

       ã€€ã€€è§£å¼€å†…核源代码

       ã€€ã€€$tar -xzvf linux-2.4..tar.gz

       ã€€ã€€æˆ–

       ã€€ã€€$tar -xjvf linux-2.4..tar.bz2

       ã€€ã€€å°äºŽ 2.4. 的内核版本解开会生成一个 linux 目录,没带版本号,就将其改名。

       ã€€ã€€$mv linux linux-2.4.x

       ã€€ã€€ç»™ Linux 内核打上你的补丁

       ã€€ã€€$cd linux-2.4.

       ã€€ã€€$patch -p1 < ../patch-2.4.-rmk2

       ã€€ã€€ç¼–译内核生成头文件

       ã€€ã€€$make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig

       ã€€ã€€ä½ ä¹Ÿå¯ä»¥ç”¨ config 和 xconfig 来代替 menuconfig,但这样用可能会没有设置某些配置文件选项和没有生成下面编译所需的头文件。推荐大家用 make menuconfig,这也是内核开发人员用的最多的配置方法。配置完退出并保存,检查一下的内核目录中的 include/linux/version.h 和 include/linux/autoconf.h 文件是不是生成了,这是编译 glibc 是要用到的,version.h 和 autoconf.h 文件的存在,也说明了你生成了正确的头文件。

       ã€€ã€€è¿˜è¦å»ºç«‹å‡ ä¸ªæ­£ç¡®çš„链接

       ã€€ã€€$cd include

       ã€€ã€€$ln -s asm-arm asm

       ã€€ã€€$cd asm

       ã€€ã€€$ln -s arch-epxa arch

       ã€€ã€€$ln -s proc-armv proc

       ã€€ã€€æŽ¥ä¸‹æ¥ä¸ºä½ çš„交叉编译环境建立你的内核头文件的链接

       ã€€ã€€$mkdir -p $TARGET_PREFIX/include

       ã€€ã€€$ln -s $PRJROOT/kernel/linux-2.4./include/linux $TARGET_PREFIX/include/linux

       ã€€ã€€$in -s $PRJROOT/kernel/linux-2.4./include/asm-arm $TARGET_PREFIX/include/asm

       ã€€ã€€ä¹Ÿå¯ä»¥æŠŠ Linux 内核头文件拷贝过来用

       ã€€ã€€$mkdir -p $TARGET_PREFIX/include

       ã€€ã€€$cp -r $PRJROOT/kernel/linux-2.4./include/linux $TARGET_PREFIX/include

       ã€€ã€€$cp -r $PRJROOT/kernel/linux-2.4./include/asm-arm $TARGET_PREFIX/include

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€å»ºç«‹äºŒè¿›åˆ¶å·¥å…·ï¼ˆbinutils)

       ã€€ã€€binutils是一些二进制工具的集合,其中包含了我们常用到的as和ld。

       ã€€ã€€é¦–先,我们解压我们下载的binutils源文件。

       ã€€ã€€$cd $PRJROOT/build-tools

       ã€€ã€€$tar -xvjf binutils-2..1.tar.bz2

       ã€€ã€€ç„¶åŽè¿›å…¥build-binutils目录配置和编译binutils。

       ã€€ã€€$cd build-binutils

       ã€€ã€€$../binutils-2..1/configure --target=$TARGET --prefix=$PREFIX

       ã€€ã€€--target 选项是指出我们生成的是 arm-linux 的工具,--prefix 是指出我们可执行文件安装的位置。

       ã€€ã€€ä¼šå‡ºçŽ°å¾ˆå¤š check,最后产生 Makefile 文件。

       ã€€ã€€æœ‰äº† Makefile 后,我们来编译并安装 binutils,命令很简单。

       ã€€ã€€$make

       ã€€ã€€$make install

       ã€€ã€€çœ‹ä¸€ä¸‹æˆ‘们 $PREFIX/bin 下的生成的文件

       ã€€ã€€$ls $PREFIX/bin

       ã€€ã€€arm-linux-addr2line arm-linux-gasp arm-linux-objdump arm-linux-strings

       ã€€ã€€arm-linux-ar arm-linux-ld arm-linux-ranlib arm-linux-strip

       ã€€ã€€arm-linux-as arm-linux-nm arm-linux-readelf

       ã€€ã€€arm-linux-c++filt arm-linux-objcopy arm-linux-size

       ã€€ã€€æˆ‘们来解释一下上面生成的可执行文件都是用来干什么的

       ã€€ã€€add2line - 将你要找的地址转成文件和行号,它要使用 debug 信息。

       ã€€ã€€Ar-产生、修改和解开一个存档文件

       ã€€ã€€As-gnu 的汇编器

       ã€€ã€€C++filt-C++ 和 java 中有一种重载函数,所用的重载函数最后会被编译转化成汇编的标号,c++filt 就是实现这种反向的转化,根据标号得到函数名。

       ã€€ã€€Gasp-gnu 汇编器预编译器。

       ã€€ã€€Ld-gnu 的连接器

       ã€€ã€€Nm-列出目标文件的符号和对应的地址

       ã€€ã€€Objcopy-将某种格式的目标文件转化成另外格式的目标文件

       ã€€ã€€Objdump-显示目标文件的信息

       ã€€ã€€Ranlib-为一个存档文件产生一个索引,并将这个索引存入存档文件中

       ã€€ã€€Readelf-显示 elf 格式的目标文件的信息

       ã€€ã€€Size-显示目标文件各个节的大小和目标文件的大小

       ã€€ã€€Strings-打印出目标文件中可以打印的字符串,有个默认的长度,为4

       ã€€ã€€Strip-剥掉目标文件的所有的符号信息

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€å»ºç«‹åˆå§‹ç¼–译器(bootstrap gcc)

       ã€€ã€€é¦–先进入 build-tools 目录,将下载 gcc 源代码解压

       ã€€ã€€$cd $PRJROOT/build-tools

       ã€€ã€€$tar -xvzf gcc-2..3.tar.gz

       ã€€ã€€ç„¶åŽè¿›å…¥ gcc-2..3 目录给 gcc 打上补丁

       ã€€ã€€$cd gcc-2..3

       ã€€ã€€$patch -p1< ../gcc-patch/gcc-2..3.-2.patch

       ã€€ã€€$patch -p1< ../gcc-patch/gcc-2..3.-no-fixinc.patch

       ã€€ã€€$patch -p1< ../gcc-patch/gcc-2..3-returntype-fix.patch

       ã€€ã€€echo timestamp > gcc/cstamp-h.in

       ã€€ã€€åœ¨æˆ‘们编译并安装 gcc 前,我们先要改一个文件 $PRJROOT/gcc/config/arm/t-linux,把

       ã€€ã€€TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC

       ã€€ã€€è¿™ä¸€è¡Œæ”¹ä¸º

       ã€€ã€€TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc -D__gthr_posix_h

       ã€€ã€€ä½ å¦‚果没定义 -Dinhibit,编译时将会报如下的错误

       ã€€ã€€../../gcc-2..3/gcc/libgcc2.c:: stdlib.h: No such file or directory

       ã€€ã€€../../gcc-2..3/gcc/libgcc2.c:: unistd.h: No such file or directory

       ã€€ã€€make[3]: *** [libgcc2.a] Error 1

       ã€€ã€€make[2]: *** [stmp-multilib-sub] Error 2

       ã€€ã€€make[1]: *** [stmp-multilib] Error 1

       ã€€ã€€make: *** [all-gcc] Error 2

       ã€€ã€€å¦‚果没有定义 -D__gthr_posix_h,编译时会报如下的错误

       ã€€ã€€In file included from gthr-default.h:1,

       ã€€ã€€from ../../gcc-2..3/gcc/gthr.h:,

       ã€€ã€€from ../../gcc-2..3/gcc/libgcc2.c::

       ã€€ã€€../../gcc-2..3/gcc/gthr-posix.h:: pthread.h: No such file or directory

       ã€€ã€€make[3]: *** [libgcc2.a] Error 1

       ã€€ã€€make[2]: *** [stmp-multilib-sub] Error 2

       ã€€ã€€make[1]: *** [stmp-multilib] Error 1

       ã€€ã€€make: *** [all-gcc] Error 2

       ã€€ã€€è¿˜æœ‰ä¸€ç§ä¸Ž-Dinhibit同等效果的方法,那就是在你配置configure时多加一个参数-with-newlib,这个选项不会迫使我们必须使用newlib。我们编译了bootstrap-gcc后,仍然可以选择任何c库。

       ã€€ã€€æŽ¥ç€å°±æ˜¯é…ç½®boostrap gcc, 后面要用bootstrap gcc 来编译 glibc 库。

       ã€€ã€€$cd ..; cd build-boot-gcc

       ã€€ã€€$../gcc-2..3/configure --target=$TARGET --prefix=$PREFIX \

       ã€€ã€€>--without-headers --enable-languages=c --disable-threads

       ã€€ã€€è¿™æ¡å‘½ä»¤ä¸­çš„ -target、--prefix 和配置 binutils 的含义是相同的,--without-headers 就是指不需要头文件,因为是交叉编译工具,不需要本机上的头文件。-enable-languages=c是指我们的 boot-gcc 只支持 c 语言。--disable-threads 是去掉 thread 功能,这个功能需要 glibc 的支持。

       ã€€ã€€æŽ¥ç€æˆ‘们编译并安装 boot-gcc

       ã€€ã€€$make all-gcc

       ã€€ã€€$make install-gcc

       ã€€ã€€æˆ‘们来看看 $PREFIX/bin 里面多了哪些东西

       ã€€ã€€$ls $PREFIX/bin

       ã€€ã€€ä½ ä¼šå‘现多了 arm-linux-gcc 、arm-linux-unprotoize、cpp 和 gcov 几个文件。

       ã€€ã€€Gcc-gnu 的 C 语言编译器

       ã€€ã€€Unprotoize-将 ANSI C 的源码转化为 K&R C 的形式,去掉函数原型中的参数类型。

       ã€€ã€€Cpp-gnu的 C 的预编译器

       ã€€ã€€Gcov-gcc 的辅助测试工具,可以用它来分析和优程序。

       ã€€ã€€ä½¿ç”¨ gcc3.2 以及 gcc3.2 以上版本时,配置 boot-gcc 不能使用 --without-headers 选项,而需要使用 glibc 的头文件。

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€å»ºç«‹ c 库(glibc)

       ã€€ã€€é¦–先解压 glibc-2.2.3.tar.gz 和 glibc-linuxthreads-2.2.3.tar.gz 源代码

       ã€€ã€€$cd $PRJROOT/build-tools

       ã€€ã€€$tar -xvzf glibc-2.2.3.tar.gz

       ã€€ã€€$tar -xzvf glibc-linuxthreads-2.2.3.tar.gz --directory=glibc-2.2.3

       ã€€ã€€ç„¶åŽè¿›å…¥ build-glibc 目录配置 glibc

       ã€€ã€€$cd build-glibc

       ã€€ã€€$CC=arm-linux-gcc ../glibc-2.2.3/configure --host=$TARGET --prefix="/usr"

       ã€€ã€€--enable-add-ons --with-headers=$TARGET_PREFIX/include

       ã€€ã€€CC=arm-linux-gcc 是把 CC 变量设成你刚编译完的boostrap gcc,用它来编译你的glibc。--enable-add-ons是告诉glibc用 linuxthreads 包,在上面我们已经将它放入了 glibc 源码目录中,这个选项等价于 -enable-add-ons=linuxthreads。--with-headers 告诉 glibc 我们的linux 内核头文件的目录位置。

       ã€€ã€€é…ç½®å®ŒåŽå°±å¯ä»¥ç¼–译和安装 glibc

       ã€€ã€€$make

       ã€€ã€€$make install_root=$TARGET_PREFIX prefix="" install

       ã€€ã€€ç„¶åŽä½ è¿˜è¦ä¿®æ”¹ libc.so 文件

       ã€€ã€€å°†

       ã€€ã€€GROUP ( /lib/libc.so.6 /lib/libc_nonshared.a)

       ã€€ã€€æ”¹ä¸º

       ã€€ã€€GROUP ( libc.so.6 libc_nonshared.a)

       ã€€ã€€è¿™æ ·è¿žæŽ¥ç¨‹åº ld 就会在 libc.so 所在的目录查找它需要的库,因为你的机子的/lib目录可能已经装了一个相同名字的库,一个为编译可以在你的宿主机上运行的程序的库,而不是用于交叉编译的。

       ã€€ã€€å›žé¡µé¦–

       ã€€ã€€å»ºç«‹å…¨å¥—编译器(full gcc)

       ã€€ã€€åœ¨å»ºç«‹boot-gcc 的时候,我们只支持了C。到这里,我们就要建立全套编译器,来支持C和C++。

       ã€€ã€€$cd $PRJROOT/build-tools/build-gcc

       ã€€ã€€$../gcc-2..3/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c,c++

       ã€€ã€€--enable-languages=c,c++ 告诉 full gcc 支持 c 和 c++ 语言。

       ã€€ã€€ç„¶åŽç¼–译和安装你的 full gcc

       ã€€ã€€$make all

       ã€€ã€€$make install

       ã€€ã€€æˆ‘们再来看看 $PREFIX/bin 里面多了哪些东西

       ã€€ã€€$ls $PREFIX/bin

       ã€€ã€€ä½ ä¼šå‘现多了 arm-linux-g++ 、arm-linux-protoize 和 arm-linux-c++ 几个文件。

       ã€€ã€€G++-gnu的 c++ 编译器。

       ã€€ã€€Protoize-与Unprotoize相反,将K&R C的源码转化为ANSI C的形式,函数原型中加入参数类型。

       ã€€ã€€C++-gnu 的 c++ 编译器。

       ã€€ã€€åˆ°è¿™é‡Œä½ çš„交叉编译工具就算做完了,简单验证一下你的交叉编译工具。

       ã€€ã€€ç”¨å®ƒæ¥ç¼–译一个很简单的程序 helloworld.c

       ã€€ã€€#include <stdio.h>

       ã€€ã€€int main(void)

       ã€€ã€€{

       ã€€ã€€printf("hello world\n");

       ã€€ã€€return 0;

       ã€€ã€€}

       ã€€ã€€$arm-linux-gcc helloworld.c -o helloworld

       ã€€ã€€$file helloworld

       ã€€ã€€helloworld: ELF -bit LSB executable, ARM, version 1,

       ã€€ã€€dynamically linked (uses shared libs), not stripped

       ã€€ã€€ä¸Šé¢çš„输出说明你编译了一个能在 arm 体系结构下运行的 helloworld,证明你的编译工具做成功了。

       è½¬è½½ä»…供参考,版权属于原作è€