Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!news.MediaCity.com!usenet From: "H.J. Lu" <hjl@gnu.ai.mit.edu> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD vs Linux Date: Wed, 10 Apr 1996 09:16:55 -0700 Organization: Ooops Lines: 169 Message-ID: <316BDEF7.2F9D8135@gnu.ai.mit.edu> References: <4issad$h1o@nadine.teleport.com> <31657509.5E45C160@gnu.ai.mit.edu> <4k4cfa$ava@uriah.heep.sax.de> <3169406A.61F8D18D@gnu.ai.mit.edu> <4kcsjc$ii@dyson.iquest.net> <316AA938.74276335@gnu.ai.mit.edu> <4kfpcm$dgs@coyote.Artisoft.COM> NNTP-Posting-Host: jimi.innovix.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------78E5D0EF563DB2276068481A" X-Mailer: Mozilla 2.01 (X11; I; Linux 1.3.81 i586) This is a multi-part message in MIME format. --------------78E5D0EF563DB2276068481A Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Terry Lambert wrote: > > "H.J. Lu" <hjl@gnu.ai.mit.edu> wrote: > ] John S. Dyson wrote: > ] > > ] > can do to improve FreeBSD's quality right now. Given that > ] > Linux NEEDED a real shared lib scheme, it was reasonable at > ] > the time for Linux to adopt ELF. FreeBSD had a REAL shared > ] > lib scheme for the last 2yrs at least. > ] > ] Correct me if I am wrong. There are no simple ways to create > ] a shared C++ library under FreeBSD. > > This is not true. FreeBSD supports the concept of linker sets, > and uses them correctly in the initialization of virtual base > classes, even without ELF. I am talking about file scope constructors/destructors. With ELF, the shared C++ library works beautifully even if with dynamic loading. The beautify is everything is supported by ELF specs. No ugly hacks are necessary. It works on all ELF systems. > > ] Also the MT support will not be as good as with ELF. > > I don't understand why this would be the case -- can you explain? See the end of my message. > Same for FreeBSD. > > Linux is *really* not using any feature of ELF that isn't already > in the existing FreeBSD ld.so, compiler, linker, assembler, and > a.out format. > I am using those features in the Linux C library behind your back. You don't even know it. My C library won't compile without ELF plus some cool features from the GNU binutils. Thanks, Ian and Ken. > > ] ELF is one opportunity for Unix to create new, innovative > ] softwares. I hate to see Unix miss the chance. > > We agree. But this opportunity has yet to become practice; > until it does, there is no compeilling reason to switch the > user base. > > Build something cool with it that we can't do without it, and > we'll certainly switch. > A few cool softwares are already there. Some of them run best under ELF, or may I say Linux? Very few people know how to take advantage of ELF. I was hoping with FreeBSD moving to ELF, more people can use ELF to write cool Unix softwares. I have a few ideas for C++ and other stuff with ELF and dynamic loading. If someone is really interested, please send me email. We can discusss them in private. I read a book on the C++ history. One main reason they didn't specify shared library was lack of a good binary format. With ELF, it is not a problem. Only sky is the limit of your imagination. But you have to know how ELF works to write programs for it. H.J. --------------78E5D0EF563DB2276068481A Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mt" We use weak aliase to allow the user to use the same symbol for non-ANSI purpose. But libc may use a different symbol name to access the non-ANSI functions for internal use. Pthreads can override it for MT. If the programmer knows what he/she is doing, he/she can also override the non-ANSI function via the internal name. For an ANSI function foo (), we use foo () to access it and pthreads will override it for MT if necessary. Basically, as far as the C library is concerned, __libc_foo () is for non-ANSI function and foo () is for ANSI. If feasible, we can make it all __libc_foo () and make foo () an aliase for __libc_foo () for an ANSI function, foo (). 1. All none ANSI symbols are exported as weak symbols. 2. All none ANSI functions should reference the none ANSI symbols fooo () via the internal names, that is __libc_foo (). 3. System calls using file descriptor are ST. 4. The glibc should provide the pthread support with minimum overhead to single thread programs: A. If there is foo_r () in pthread, we can leave foo () alone. Programmers should use foo_r () for thread. B. If foo () is thread-safe, we leave it alone. C. For foo (), the filename should be foo.c and no leading '_'. D. For a non-ANSI function, foo (), users can redefine foo () in his/her programs without interferring the C library. __libc_foo () is provided as a way for internal access to the libc definition of foo () and for pthreads to override it with a MT safe version. a. If it is thread-safe, it is defined as __libc_MT_foo (). We make __libc_foo () as an aliase and foo () as a weak aliase of __libc_MT_foo (). b. If it is not thread-safe, it is defined as __libc_ST_foo (). We make __libc_foo () and foo () as weak aliases of __libc_ST_foo (). E. For an ANSI function, foo (): a. If it is thread-safe, it is defined as foo (). b. If it is not thread-safe, it is defined as __libc_ST_foo (). We make foo () as a weak aliases of __libc_ST_foo (). F. If foo () is in libpthreads: a. If it is not ANSI, we defined it as __libc_MT_foo () which can call __libc_ST_foo () if necessary. We make foo () as a weak () alias of __libc_MT_foo (). b. If it is ANSI, we defined it as foo () which also can call __libc_ST_foo () if necessary. G. The pthread support will be provided as a shared library only, libpthreads.so. The purpose of this proposal is to find to provide a consistent API for both MT and ST programs. For C library users: 1. For ANSI function, a ST foo () will be provided by default. With -lpthreads, a MT foo () will be provided. 2. For non-ANSI function, user can use open (), read () .... for other purpose without disturbing C library. For C library developers: 1. For ANSI function, A. If it is not MT, foo () will get __libc_ST_foo () by default. With -lpthreads, __lib_MT_foo () in libpthreads will be used. __libc_ST_foo () can be used to get the ST version of foo (). B. If it is MT, foo () is foo (). 2. For non-ANSI function, A. If it is not MT, __libc_foo () will get __libc_ST_foo () by default. With -lpthreads, __lib_MT_foo () in libpthreads will be used. __libc_ST_foo () can be used to get the ST version of foo (). B. If it is MT, __libc_foo () is __libc_foo (). --------------78E5D0EF563DB2276068481A--