Debian下编译glibc库问题

starli

天啊，低版本2.2.3的也有问题啊，到底是那里出了问题啊。又换了2.5的，连configure都不成功，居然出现“the arm is not supported"。

T-bagwell

是不是需要打patch啊

starli

我也觉得有必要试试打补丁

starli

给gcc打了补丁还是不行啊。glibc要不要打补丁？我再试试给内核打补丁！

snail_314

自己build cross tool?干嘛？？不要告诉我你们公司要求的。。。

starli

自己编译有什么问题吗？当然不是公司要求的啦，我只是我想学习学习嵌入式方面的啊，就从编译工具链开始啊。

snail_314

学习嵌入式从编译工具链开始绝对是错误的。。。
要么照着人家的instruction做什么问题都不出，就叫做build成功了。要么就是遇到问题后打了一堆自己也不知道的补丁多半还是google出来的结果，一知半解的捣鼓成功后结果换了一个版本后又没辙了。这种东西用来学习嵌入式是嵌入式培训市场的浮躁结果。。。

starli

楼上说的挺有道理。那你说应该从什么开始，写程序，写驱动？

snail_314

我个人觉得从看经典书开始。包括一些经典的网站，比如www.embedded.com，上面的一些专栏非常有启发性。不一定非要实践，如果要实践的话，就一定要先想明白“我这次实践的目的是什么？是为了验证什么知识点？“实践的效率很大程度上决定于你对GNU tool的熟悉，比如make，比如autotools，就拿autotools来说，http://www.lrde.epita.fr/~adl/autotools.html看过了么？还有gcc, ld, ldd等，比如“我用什么命令可以看gcc是怎么找头文件的搜索目录的”，“ld所谓的script是干什么用的”，这些工具当然需要长期的积累，info gcc, info ld都够花好长时间来学习了。熟悉了这些工具后，再比如看工具连的构建，比如你看了《build embedded linux》那本书之后，你看作者在编译arm-gcc时所加的那几个--without-xxx, 或者--enable-xxx选项，你就可以更快的“找到”加他们的理由（比如看configure.ac源文件），这样也可以帮助你google的效率，尽量做到不要人云亦云，一知半截。
其实这些东西实践多了我觉得还很浪费时间，抓住核心就行。因为出来工作后你会发现能用的上的少之又少，我intel, TI的同事同学他们都是用的母公司早已build好的工具连了，哪里用得上你我这些廉价工程师来做这些“高风险”的活儿。现在openembedded等成熟的套件更是让哪怕上游的芯片商都不再需要关注这些“dirty work”。
所以，我觉得与其把时间花在这些事上，不如把专业（如自动化控制，图形图像等领域知识）学好，我现在也在一家芯片商做嵌入式开发，工作中的瓶颈都是在专业知识上。这些才是决定你在嵌入式行业个人发展能到多高的高度。

snail_314

就像一提到linux就是kernel, driver我觉得也不对，linux 上的software stack， middleware stack才是让其发光的地方，看看现在火得不得了的android就知道了。包括nokia的maemon, palm的webOS，intel的moblin，对，他们都是基于linux的，但基本只限于kernel而已，而是上层的stacks才是体现他们“不一样”或者说“价值”的地方。看看现在montavista这些嵌入式老兵现在都不再把重点放在kernel移植上了（芯片商基本都在做这个事），他们都把注意力放在了stacks上面