您当前位置: 首页 »

unix编程环境学习

分类目录归档: unix编程环境学习

【ios、x264】将静态库打包成动态库,链接时的text relocations错误

最近在ios上出现将多个sdk放到一个app时,有各种开源静态库冲突的问题;于是考虑将自己用到的库进行打包成动态库版本,以此解决冲突问题。

在进行打包成动态库时,发现x264问题最大。打包出来的库在链接期出现text relocations错误,网上找了以后发现基本都是进行忽略这个错误,事实上这个错误忽略了没用,app启动时还是会出现相应的crash。

换了几个版本的xcode进行测试,发现x264编译会出现不同情况的告警和错误,根据底部罗列的参考文章,估计xcode的编译器可能也有一些bug。

后来模仿android上的编译方式,在x264里加入了–enable-pic和–disable-asm顺利编译通过,但由于osx和xcode版本的因素,模拟器上的并没有编译出来,仅仅编译了armv7和arm64。

 

参考文章:

MacOSX下编译linphone(text-relocation错误说明)

libxxx.so- text relocations问题的终极解决方案(android)

Linker error when using incremental builds on iPhone

Android Gradle编译so库或运行时出现 text relocations 崩溃的正确解决方法

2018-06-15 | | [linux总结], unix编程环境学习, 编码技巧, 音视频_图像相关, 音视频编解码

【ios、x264】将静态库打包成动态库,链接时的text relocations错误已关闭评论

【MacOSX、iOS、跨平台编译】在跨平台编译时MacOSX Serria/XCode是我遇到bug最多的平台

最近被安排来搞定android、ios、mac、windows下的webrtc、ffmpeg和x264的编译问题。

除了由于webrtc配置工程的问题在windows下我自己的搭建环境无法使用,最终求助于之前使用的虚拟机环境以外,android下的webrtc都比较顺利,同样也是编译anroid环境的和windows环境的ffmpeg,相对来说也是比较顺畅(虽然还是出现了一些坎坷)。

但在Mac环境下编译webrtc、ffmpeg和x264就没有那么幸运了。简直就是人间地狱,首先说明一下,这个Mac机原先是有其他开发者在上面编译成功过这三个工程的,到我之后就开始出现了一大堆问题(当然也有可能我用的是用户新帐号的缘故)。

 

人间地狱的开始

  • 先说一说编译webrtc遇到的坑爹问题。由于webrtc编译环境我们只输出静态库,并不输出一个framework或者app,所以并不需要关心太多app层面的问题(如证书相关)。虽知道在webrtc的gyp检查项目中会对证书冲突做检查,由于机器中存在多个证书,导致gyp阶段无法生成正确的编译配置参数。导致折腾了一周,最后才发现和证书有关。虽然这个问题和gyp有一定的关系,但也只是我对mac上编译和交叉编译的被坑的起点。

 

  • 接着是x264和ffmpeg编译时,由于给我的工程之前都是能够成功编译的,现如今拿过来,除了Mac平台可以通过以外,真机和模拟器都不行。折腾来折腾去几天,最后发现是clang去找依赖的时候找错了,找了mac的依赖环境,而不是去找iphoneos的依赖,然后怎么调都没用。很是坑爹,就拿网上的现成脚本来跑也是不行。

最后去查config.log,发现一堆错误,其中ffmpeg的错误还有一个叫做gas-preprocessor.pl的执行错误,由于是通过git直接从网上拿下来的脚本,在没有任何修改的情况下,通过sftp发到mac里面,给了执行权限之后通过命令行直接执行一点问题都没有,但通过configure执行时就一直报没有权限的错,怎么也想不明白;后来试着用curl拿文件,居然通了。当时我就估计如果不是字符集的问题,就是权限标记位的问题。

接着再继续修改关于依赖的问题,仅仅一个交叉编译工具clang,居然在不同的工程里面对同一个路径参数能够出现多种不同的行为,后来还特意看了一下clang是不是GNU开源社区的代码,通过–version看到的内容如下:

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

可见这个坑是苹果自己的。可能是由于命令行的长度的不同,导致解析命令行的bug?或者其他什么坑爹问题?反正我是不知道了,近几年开始苹果的产品也不见得有多少优势了,正在被一点点拉小差距。如果不是为了混口饭吃,苹果的任何产品我真的不想去碰!

2017-03-20 | | linux-shell, shell, unix编程环境学习, 图像处理, 音视频_图像相关, 音视频编解码

【MacOSX、iOS、跨平台编译】在跨平台编译时MacOSX Serria/XCode是我遇到bug最多的平台已关闭评论

通过windows和linux在socket上的几点相同点,来揣测windows和linux在某些实现上的相似

首先,我是一个完全的linux开发初学者,我仅仅在windows做开发,由于兴趣与工作的缘故碰到了通过已有的socket模型搭建好的网络库。下面就说说在windows下,我了解到socket模型(准确是标准socket模型,对于微软封装过的一些模型我不是很清楚)

1,普通阻塞是socket:

普通的socket模型,就是msdn中对socket api族介绍中最简单的那个例子。这种最简单,在执行效率上相对较低,在处理send/recv(sendto/recvfrom)时,函数是处于阻塞的。在简单环境,或者写一些简单的测试工具时,这是一种比较理想的用法。

2,同步 select模型

同步select模型,其实可以是理解为普通阻塞式sokcet的一个扩展,就是利用select来对socket句柄进行监听,避免由于调用send/recv(sendto/recvfrom)时出现阻塞。

3,异步select模型

异步select模型,可以看成是同步select的一种变化。即send/recv(sendto/recvfrom)函数不会阻塞,调用立即返回,并需要同时配合select函数一同使用。

4,IOCP

异步IO模型,使用上可以和异步select模型类比;但这并非标准socket模型。

 

然后接下来再说一下几个模型的差别:

1,普通socket、select模型,在调用send/recv(sendto/recvfrom)函数时,均会出现一次多余的内存拷贝。即,用户态传如一个buffer时,在转为交给协议栈之前,必须通过内存拷贝的方式,将数据复制到内核态的内存中。

2,windows上select集合最大值大约是64/128(有系统版本决定);换句话说一个调用select函数的线程,最大可监听64/128个socket句柄

*3,据网上各种文档介绍到,select是基于内核态线程轮询完成,具体不详,有待考证!

4,IOCP 和其他几者最大区别在于内存拷贝上,由于IOCP是通过共享内存(即内存映射)。在windows中内存映射属于一个特殊的内存管理器的管辖范围,他即不属于内核态,也不属于用户态内存,当对于内核态或用户态线程来说,只要通过调用内存映射函数,就可以直接访问这块内存(但得到的逻辑地址或许是不同的)。

由于在WSARecv/WSASend之类函数中,提交的均为共享内存,因此无需做任何内存拷贝。所以在IOCP上,性能要更好的多。同时本人的了解范畴也仅限于这一块,对于IOCP的事件投递过程并不是很清楚,但根据《软件调试》一书中对“windows系统调试/windows软件调试”设计的讲述来看,IOCP这种的实现应该是在内核态也同样创建了和用户态以之对应的内核服务线程。

 

接着再说说linux,刚刚看了一下epoll的介绍。

发现epoll是基于事件回调+内存映射来实现IO上的高效;同时这篇文章也还介绍了几个常用的socket模型在linux中的大概实现。通过这篇文章至少能够看出,linux和windows在对socket的实现上存在很大的相似。

可见linux和windows存在很多相似的地方,如果linux和windows互相对应着学,理解起来可能会快很多。

2015-11-16 | | [linux总结], linux kernel, unix编程环境学习, win api

通过windows和linux在socket上的几点相同点,来揣测windows和linux在某些实现上的相似已关闭评论

【debian 7】查看可执行文件依赖的so,极其目录

在编译ffmpeg的时候,发现libx264的so无法加载;后来发现加载的so位置不对。

通过ldd可以查看可执行文件以来的so文件极其位置,执行后命令输出如下:

aaa@debian-dev:~/dev_mobile$ ldd 'ffmpeg'
	linux-gate.so.1 =>  (0xb77be000)
	libx264.so.142 => /lib/libx264.so.142 (0xb75d9000)
	libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb75b3000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7599000)
	librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb7590000)
	libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7577000)
	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7413000)
	libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb740f000)
	/lib/ld-linux.so.2 (0xb77bf000)
2014-07-03 | | unix编程环境学习

【debian 7】查看可执行文件依赖的so,极其目录已关闭评论

插入api 用在代码单元测试

以前做过一段时间的LLT,对于LLT的实现感觉很奇怪。

LLT主要是用于函数单元级测试,以及多函数之间的debug。

在测试某个函数时,其实关心的只是函数本身流程和值计算是否正确。对于被函数如何调用其他函数,或者调用是否正确都不关心。因此需要对被测函数内部的函数调用情况作修改。

在windows上面,就用用到了hook中的一种。插入api,即替换函数的第一条汇编指令。

readmore

2012-05-01 | | unix编程环境学习, 思考

插入api 用在代码单元测试已关闭评论

重新调整了规划

今天去看了那些招聘会,回来的路上感觉到,还是有些地方需要重新鉴定一下。现在有很多的企业都在招C++程序员,只可惜大部分都是基于.net环境的。

之所以会招.net环境的人,那是因为和.net的发展有关联。其实,.net应该是来源于2种语言。一种是C另一种还是VB,提出.net的概念的时候,本来就只是打算升级ASP所存在的一些弊端。

听说了,C++,有好几个方言版本。但就是.net的开发速度最快,效率也未必最高。反而一些牛XX企业,也许正喜欢用别的方言版本。MS的东西,我真的不敢恭维。再进一步弱化用户的同时,有时候也在某种程度上在弱化程序员。

readmore

2009-05-23 | | [linux总结], [窥视自我], *生活*, unix编程环境学习

重新调整了规划已关闭评论

开篇

由于学校的学生科研项目。由于自己对自己想法的偏执。网友的推荐,我开始学习了unix环境编程.


这本书一开始也没有注意。后来看着看才发现这本书是10年前写的。书里面讲的内容很多,很详细(对于我这个非计算机专业的人来说)。不过一样还是需要具备一些基础知识。


首先,至少需要知道什么是*inx。我是在debian环境里面熟悉linux的。同时手头还有一本linux内核讲解的书籍。当然这本书也是一样的很难。由于专业问题,看着非常的吃力。有时候还有不想看,自己逃避过很长的一段时间。不过毕竟是我向往的工作。linux嵌入式系统。所以还是在某种动力下,看了linux和unix的这两本书。


看的时候的确很痛苦,不过当我坚持出来的时候。我发现很多事情变得容易得多了。目前还没看完。以后很多我觉得重点的东西我一样会放上来,就算作为备忘录也是很好的。

2008-02-12 | | unix编程环境学习

开篇已关闭评论