为了让xmake更好得支持交叉编译,这个版本我重构了整个工具链,使得工具链的切换更加的方便快捷,并且现在用户可以很方便地在xmake.lua中扩展自己的工具链。
xmake是一个基于Lua的轻量级现代化c/c++的项目构建工具,主要特点是:语法简单易上手,提供更加可读的项目维护,实现跨平台行为一致的构建体验。
合抱之木,生于毫末;九层之台,起于垒土;千里之行,始于足下。--(老子·道德经 )
阅读笔者的其他文章,我们了解了编译过程中的预处理、词法分析、语法分析、编译、链接等步骤。经常和编译型语言打交道的开发者对于可执行文件的编译过程肯定不陌生。我们用 Xcode 构建一个程序的过程中,会把源文件 (.m 和 .h) 文件转换为一个可执行文件。这个可执行文件中包含的字节码将会被 CPU (iOS 设备中的 ARM 处理器或 Mac 上的 Intel 处理器) 执行。
搜索了一下,发现核心原因是Mac下ranlib命令采用了GNU版本,而非Apple版本导致的,下面详细展开报错原因和解决办法。
它使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
笔者在使用 `rbenv`[1] 安装 ruby 时,遇到一个头文件缺失导致无法编译失败的问题。
2000年,伊利诺伊大学厄巴纳-香槟分校(University of Illinois at Urbana-Champaign 简称UIUC)这所享有世界声望的一流公立研究型大学的 Chris Lattner(他的 twitter @clattner_llvm ) 开发了一个叫作 Low Level Virtual Machine 的编译器开发工具套件,后来涉及范围越来越大,可以用于常规编译器,JIT编译器,汇编器,调试器,静态分析工具等一系列跟编程语言相关的工作,于是就把简称 LLVM 这个简称作为了正式的名字。Chris Lattner 后来又开发了 Clang,使得 LLVM 直接挑战 GCC 的地位。2012年,LLVM 获得美国计算机学会 ACM 的软件系统大奖,和 UNIX,WWW,TCP/IP,Tex,JAVA 等齐名。
背景是我们项目升级某个SDK,结果发现项目和SDK出现符号冲突。 符号冲突是接入SDK有可能会出现的问题,本文便尝试从技术角度去解决。
LLVM的编译过程相当复杂,iOS代码运行需要经过:预处理、编译、汇编、链接四个关键阶段,具体的流程如下图:
众所周知从Xcode10起,苹果摒弃了对libstdc++库的支持转而支持libc++库了。这两个库在Xcode9甚至更早的版本就已经同时存在于系统中并且可供开发者选择,当然在Xcode9时代苹果就已经宣布了将要废弃libstdc++的信息了。
c++ modules已经正式纳入了c++20草案,msvc和clang也已经基本实现了对modules-ts的支持,随着c++20的脚步离我们越来越近,xmake也开始对c++modules提前做好了支持。
在咱们日常开发中,或多或少都会用到 Xcode 内置的一些CLI工具,但是大部分小伙伴可能只是会用到一些具体的命令,今天我们就一起来聊一聊 Xcode 内置的常见Command Lines Tool。
本系列文章会通过对 clang 源码进行拆解的方式,逐步对 clang 内部的各种逻辑进行介绍。
今天看到一篇讲 Swift Crash 的文章一个 Swift Crash 引发的讨论...原文作者从Swift源码和UIKitCore -[UIView(UIKitManual) autorelease] 汇编代码的角度对 crash 的原因进行了分析。
编程语言的很多特性都是依赖于编译器的。比如,与 C 语言的枚举相比,Swift 的枚举就依赖编译器实现了关联值等高级特性。
这边文章不是一个如何引导,尽管它确实展示了如何编译和调试共享库和可执行文件。为了解动态加载的内部工作方式进行了优化。写这篇文章是为了消除我在该主题上的知识欠缺,以便成为一名更好的程序员。我希望它也能帮助您变得更好。
最近看到一篇有意思的技术文章:《抖音研发实践:基于二进制文件重排的解决方案 APP启动速度提升超15%》。
原生的应用程序比转换的应用程序运行效率更高,因为编译器能够针对目标架构来优化代码。如果一个应用程序只支持 x86_64 架构,那必须在 Apple 芯片上的 Rosetta 转换下运行。通用二进制文件本身就可以在 Apple 芯片和基于 Intel 的 Mac 机上运行,因为它包含了两种架构的可执行代码。
xmake 是一个基于 Lua 的轻量级跨平台构建工具,使用 xmake.lua 维护项目构建,相比 makefile/CMakeLists.txt,配置语法更加简洁直观,对新手非常友好,短时间内就能快速入门,能够让用户把更多的精力集中在实际的项目开发上。
B(l)utter是一款针对Flutter移动端应用程序的逆向工程分析工具,当前版本的B(l)utter仅支持Android libapp.so(ARM64),可以帮助广大研究人员对基于Flutter开发的移动端应用程序进行逆向工程分析。
CPU 由上亿个晶体管组成,在运行的时候,单个晶体管只能根据电流的流通或关闭来确认两种状态,我们一般说 0 或 1,根据这种状态,人类创造了二进制,通过二进制编码我们可以表示所有的概念。但是,CPU 依然只能执行二进制代码。我们将一组二进制代码合并成一个指令或符号,创造了汇编语言,汇编语言以一种相对好理解的方式来编写,然后通过汇编过程生成 CPU 可以运行的二进制代码并运行在 CPU 上。
解决方法:可能是由于粘贴网页上的代码的时候两行之间的回车引起的,有未识别的回车或者换行,找到,删除掉就 OK了。
一、前情回顾 最近把公司的一个视频处理程序更新了一个版本,准备提交测试的发现了崩溃的情况。这个程序采用Qt和ffmpeg技术栈开发,主要用于对视频进行渲染拼接处理,在Windows和mac两个平台同时进行发布。在windows上测试完一切正常,然而就在我以为一切大功告成的时候,测试的同事直接给我来了个当头棒喝,程序崩溃了!没有道理啊,同一套代码在Windows上安然无恙,在Mac上为何直接崩溃?好消息是程序在崩溃的时候保存了dump文件。 📷 这得感谢前段时间集成的Google Breakpa
NDK 全称 Native Development Kit,也就是原生开发工具包 ,官网对它有详细的 中文介绍 。可能一说到 NDK 或 JNI ,大家脑子里第一反应就是集成 C/C++ 。其实 JNI 的含义是 Java Native Interface ,这种接口允许 Java 和其他语言进行交互的,包括但不限于 C/C++ 。目前 Rust 也可以通过 JNI 来和 Java 交互,虽然不太成熟。
作者 | Strager 译者 | 马可薇 策划 | 褚杏娟 C++ 漫长的构建时间可谓臭名昭著,编程圈的“我的代码在编译”只是个段子,但 C++ 让这个段子长盛不衰。 谷歌 Chromium 规模的项目在新硬件上的构建时间长达一小时,而在老硬件上的构建时间更是达到了六个小时。虽然也有海量的调整方案能加速构建速度,还有不少削减构建内容但极易出错的捷径供人选择,再加上数千美元的云计算能力,Chromium 的构建时间仍是接近十分钟。这点我完全无法接受,人们每天都是怎么干活的啊? 有人说 Rus
在实际编译代码的过程中,我们经常会遇到"undefined reference to"的问题,简单的可以轻易地解决,但有些却隐藏得很深,需要花费大量的时间去排查。工作中遇到了各色各样类似的问题,按照以下几种可能出现的状况去排查,可有利于理清头绪,从而迅速解决问题。
node-gyp是用Node.js编写的跨平台命令行工具,用于为Node.js编译本机插件。它包含gyp-next项目的供应商副本,该副本以前由Chromium团队使用,已扩展用来支持Node.js本机插件的开发。
怎么会有如此方便的文档查看工具?顿时觉得被各种加载奇慢的 API 文档坑苦了好多年!于是很开心地下载了我常用的 API 文档,并且找到了它在 Windows 下的替代品 Zeal 推荐给朋友们,感觉世界从此美好了许多。
Objective-C文件的编译过程主要包括clang前端的预处理、编译、后端优化中间表示、生成汇编指令、链接、生成机器码这几个步骤。我们可以借助clang -ccc-print-phases xxx.m命令查看某个OC源文件的编译的过程,如下: 输入命令
我们程序员编写的源代码是人类语言,我们可以很轻松得理解;但是对于计算机硬件(CPU)而言,这些源代码就好比是天书,它根本无法理解,更无法直接执行。计算机只能够识别某些特定的二进制指令,所以在程序真正运行之前,必须要把源代码转换成计算机可以识别的二进制指令。
2021 年 11 月,我们决定评估 arm64 架构在 Uber 的可行性。我们的大多数服务是用 Go 或 Java 编写的,但我们的构建系统只能编译成 x86_64。现在,得益于开源合作,Uber 拥有了一个独立于系统的构建工具链,可以无缝地支持多种架构。我们使用这个工具链来引导 arm64 主机。本文将分享我们是如何着手去做这件事情的,以及我们早期的想法、遇到的问题、达成的一些成就和未来的方向。
http://blog.csdn.net/yongyinmg/article/details/41513917
今天,笔者从 百度App Objective-C/Swift 组件化混编之路(二)- 工程化 时,就被灌输了一个”新知识“:module 会供链接器使用 。
我们曾经在上一篇文章中 https://cloud.tencent.com/developer/article/1744552 提到 Swift 及相关组件的编译会耗费大量的磁盘空间。
Conan 2.0 版本已经发布很久了,配套的 cmake-conan 工具也同时得到了更新,在原有 Conan 1.x 版本上增强了功能,对开源项目和公司内部已有的 CMake 项目非常友好,接入简单。本文主要介绍 cmake-conan 的应用场景以及交叉编译的实战。
今天开始,我们对编译器架构系统LLVM进行一个简单的了解和分析,了解完LLVM的编译流程之后,简单实现一个Clang插件玩玩。下面就开始今天的内容。
Pipeline: Compilation Action Construction:根据每个输入的文件和类型,组建 action(比如 PreprocessJobAction)
比如,当我们进行点击下图的运行按钮(Run Button)** (▶️)时,Xcode就会调用 Build System 进行 APP 的构建过程 。
在 iOS 和 macOS 开发中, Swift 包现在变得越来越重要。Apple 已经努力推动桥接那些缝隙,并且修复那些阻碍开发者的问题,例如阻碍开发者将他们的库和依赖由其他诸如 Carthage[1] 或 CocoaPods[2] 依赖管理工具迁移到 Swift 包依赖管理工具的问题,例如没有能力添加构建步骤的问题。这对任何依赖一些代码生成的库来说都是破坏者,比如,协议和 Swift 生成。
Kotlin Native是一种将Kotlin源码编译成不需要任何VM支持的目标平台二进制数据的技术,编译后的二进制数据可以直接运行在目标平台上,它主要包含一个基于LLVM的后端编译器的和一个Kotlin本地运行时库。设计Kotlin Native的目的是为了支持在非JVM环境下进行编程,如在嵌入式平台和iOS环境下,如此一来,Kotlin就可以运行在非JVM平台环境下。
如果我们是通过 CocoaPods 引入第三方,那么在命令行执行 pod install 之后,查看项目目录就可以看到多了一个 xcworkspace 文件,如下:
为了提高工程的编译速度,准备把第三方库编译成 Framework。这样就可以省掉编译这些第三方库的很多时间了。
领取专属 10元无门槛券
手把手带您无忧上云