最新免费av在线观看,亚洲综合一区成人在线,中文字幕精品无码一区二区三区,中文人妻av高清一区二区,中文字幕乱偷无码av先锋

登錄 免費(fèi)注冊(cè) 首頁(yè) | 行業(yè)黑名單 | 幫助
維庫(kù)電子市場(chǎng)網(wǎng)
技術(shù)交流 | 電路欣賞 | 工控天地 | 數(shù)字廣電 | 通信技術(shù) | 電源技術(shù) | 測(cè)控之家 | EMC技術(shù) | ARM技術(shù) | EDA技術(shù) | PCB技術(shù) | 嵌入式系統(tǒng)
驅(qū)動(dòng)編程 | 集成電路 | 器件替換 | 模擬技術(shù) | 新手園地 | 單 片 機(jī) | DSP技術(shù) | MCU技術(shù) | IC 設(shè)計(jì) | IC 產(chǎn)業(yè) | CAN-bus/DeviceNe

uClibc和uC-lib有什么區(qū)別?(根據(jù)網(wǎng)上資料整理)

作者:zlei 欄目:ARM技術(shù)
uClibc和uC-lib有什么區(qū)別?(根據(jù)網(wǎng)上資料整理)
What is the difference between uC-libc and uClibc
  
  There are two libc libraries commonly used with uClinux. uC-libc and uClibc. They are quite different despite their similar names. Here is a quick overview of how they are different.  
  

uC-libc is the original library for uClinux. It was based on sources from the Linux-8086 C library which was PART of the ELKs project with m68000 SUPPORT added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete libc implementation, however, some of the API's are a little non-STANDARD and quite a few common libc routines are not present. Currently it has stable SUPPORT for m68000, ColdFire and ARM (Non-MMU) architectures. It was primary design goal is to be small and light weight. It does try to conform to any STANDARDs, although its API tries to be compatible with most libcs, it is not always exactly the same.

uClibc is a derivative of uC-libc designed to fix the problems with uC-libc. It makes all the API's STANDARD (correct types, args, etc), fills in many of the missing routines, and has been ported to a lot of architectures. In general it tries to provide glibc compatibility so that porting applications to the smaller uClibc is quite easy. It can be used on STANDARD VM Linux and uClinux. To make it even more compact it can also be compiled as a shared library on most platforms with MMU SUPPORT Erik Andersen has been the driving force behind uClibc and has done a great job. uClibc SUPPORTs a large array of processors: m68000, Coldfire, ARM, MIPS, v850, x86, i960, Sparc, SuperH, ALPHA, PowerPC and HITACHI 8. uClibc is much easier to ADAPT to a new architecture and its ever growing platform SUPPORT is testimony to this.

The uClinux distribution provides an environment that can compile using either uC-libc or uClibc depending on your needs. For m68000 and Coldfire platforms it is generally better to chose uC-libc as it SUPPORTs shared libraries and is the most commonly used libc for these CPUs. uClibc also works quite well with almost all platforms SUPPORTed by the distribution. Which libc you choose to use will be decided by your requirements.





uClinux有兩個(gè)經(jīng)常使用的libc庫(kù):uC-libc和uClibc.雖然兩者名字很相似,其實(shí)
有很大的不同,下面就簡(jiǎn)單的介紹一下二者的不同之處.
uC-libc是最早為uClinux開(kāi)發(fā)的庫(kù).它基于Linux-8086 C庫(kù)的源碼,而Linux-8086
C庫(kù)是Jeff Dionne和Kenneth Albanowski為EKLs項(xiàng)目支持m68000添加的.uC-libc
是一個(gè)完全的libc實(shí)現(xiàn),但是,其中有一些api是非標(biāo)準(zhǔn)的,有些libc的標(biāo)準(zhǔn)也沒(méi)有
實(shí)現(xiàn).現(xiàn)在,uC-libc穩(wěn)定地支持m68000,ColdFire和ARM(沒(méi)有MMU)架構(gòu).它的首要
設(shè)計(jì)目標(biāo)是小,"輕".它嘗試著和所有的標(biāo)準(zhǔn)一致,雖然它的API和很多l(xiāng)ibc都相容,
但是似乎并不像它想的那樣和所有標(biāo)準(zhǔn)一致.

uClibc就是為了解決這個(gè)問(wèn)題從uC-libc中發(fā)展出來(lái)的.它的所有API都是標(biāo)準(zhǔn)的
(正確的返回類(lèi)型,參數(shù)等等),它彌補(bǔ)了uC-libc中沒(méi)有實(shí)現(xiàn)的libc標(biāo)準(zhǔn),現(xiàn)在已經(jīng)
被移植到多種架構(gòu)中.基本上,它試著和glibc兼容,這樣將應(yīng)用程序用uClibc改寫(xiě)
就很容易.它能夠在標(biāo)準(zhǔn)的VM linux和uClinux上面使用.為了應(yīng)用程序的簡(jiǎn)潔,它
甚至可以在大多數(shù)支持MMU的平臺(tái)上被編譯成共享庫(kù).Erik Anderson在uClibc背
后做了很多的工作.uClibc支持一系列的處理器:
m68000,Coldfire,ARM,MIPS,v850,x86,i960,Sparc,SuperH,ALPHA,PowerPC和
HITACHI 8.不斷增加的平臺(tái)支持顯示uClibc能夠很容易的適應(yīng)新的架構(gòu).
uClinux發(fā)行版提供了環(huán)境能夠讓你選擇使用uC-libc或是uClibc編譯.對(duì)于
m68000和Coldfire平臺(tái)來(lái)說(shuō),選擇uC-libc還是稍微好一點(diǎn),因?yàn)樗С止蚕韼?kù),而
共享庫(kù)是這些cpu經(jīng)常使用的libc.uClibc也幾乎和所有的平臺(tái)都能很好的工作.
選擇哪種libc取決于你的需求.

2樓: >>參與討論
zlei
second
Should I use uClibc or uC-libc
  
  Many people ask this question the first time they use uClinux. If you haven't already ready looked at the differences between the two libraries, you should. Here is some more information to help determine the best choice for your SYSTEM.  
  

Firstly, uC-libc ONLY supports ARM and m68k CPUs, so for anything else, uClibc is probably the one you want.
For Coldfire platforms uC-libc has been used more extensively than uClibc and is generally considered the best default for first time users. Once you get more comfortable with the environment you may decide to SWITCH.

For ARM and other m68k variants the choice will depend on your application. uC-libc may be a little smaller and most certainly has had it's data section requirements trimmed for use as a shared library (under 16KB with uC-libc vs. greater than 32KB with uClibc). uClibc on the other hand provides a more standards compliant library, so if you are porting new applications to uClinux this may save you some effort getting the new applications going.

So while the choice is still left with the user, hopefully it will be easier to decide give some of the information above.


我該使用uClibc還是uC-libc?
很多人在初次使用uClinux的時(shí)候都會(huì)問(wèn)這個(gè)問(wèn)題.如果你沒(méi)有閱讀過(guò)兩者的不通,
你應(yīng)該會(huì)問(wèn).下面有點(diǎn)更多的信息來(lái)幫助你決定哪種是你系統(tǒng)的最好選擇.
首先,uC-libc僅僅支持ARM和m68k CPU,所以如果你使用其他的cpu,uClibc可能是
你想要的.
對(duì)于Coldfire平臺(tái),uC-libc比uClibc做了很多擴(kuò)展,被認(rèn)為是初次使用者的最好
選擇.當(dāng)你對(duì)環(huán)境適應(yīng)之后,你可以決定是否改變.
對(duì)于ARM和其他的m68k變種,選擇哪種由你的應(yīng)用程序來(lái)決定.uC-libc可能更小,
它對(duì)做共享庫(kù)使用而裁剪了數(shù)據(jù)區(qū)(data section)(uC-libc16k,uClibc大于
32k).而另一方面,uClibc提供的是一個(gè)更加標(biāo)準(zhǔn)的庫(kù),所以如果你是把一個(gè)新應(yīng)
用程序移植到uClinux,uClibc會(huì)減輕你很多工作.
選擇是使用者必須面對(duì)的,希望上面的信息能對(duì)你們有幫助.

3樓: >>參與討論
zlei
原文
http://www.ucdot.org/article.pl?sid=02/08/21/1124218
http://www.ucdot.org/article.pl?sid=02/09/30/0523232

不是我翻譯的,我忘了是哪位了,謝謝他!

* - 本貼最后修改時(shí)間:2005-3-25 13:13:19 修改者:zlei

參與討論
昵稱(chēng):
討論內(nèi)容:
 
 
相關(guān)帖子
求助,內(nèi)存問(wèn)題
我想要能跑s3c44b0x的uclinux內(nèi)核源碼!謝謝了!
關(guān)于ARM  GPIO口的問(wèn)題!
請(qǐng)問(wèn)ARM9系列GPIO口的驅(qū)動(dòng)能力是多少?
sos
免費(fèi)注冊(cè)為維庫(kù)電子開(kāi)發(fā)網(wǎng)會(huì)員,參與電子工程師社區(qū)討論,點(diǎn)此進(jìn)入


Copyright © 1998-2006 www.udpf.com.cn 浙ICP證030469號(hào)