Date: Sat, 30 Oct 1999 12:43:10 +0200 From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Chris Costello <chris@calldei.com> Cc: Warner Losh <imp@village.org>, obrien@freebsd.org, freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991030124309.A43205@daemon.ninth-circle.org> In-Reply-To: <19991029134549.B535@holly.calldei.com> References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-On [19991030 00:00], Chris Costello (chris@calldei.com) wrote: >On Fri, Oct 29, 1999, Warner Losh wrote: >> In message <19991029132257.A535@holly.calldei.com> Chris Costello writes: >> : I'm seeing more and more of a need for a compat library for >> : Linux and GNU software in general. Adding unnecessary bloat to >> : our libc isn't necessary, in my opinion. >> >> The problem with this is that it becomes harder to build on FreeBSD >> because you have to add additional, non-standard libraries to the >> build process. This is the fault of the author of the tool, since >> they used non-standard interfaces, so maybe it wouldn't be too bad. >> The risk we run in not supporting them in libc is the perception that >> FreeBSD isn't compatible (never mind what the sstandards say). > > That's the problem. I honestly can't begin to think of a perfect >way of getting around Linux developers putting kludge after kludge >on top of poorly written workarounds on top of hacks that were never >really fully implemented (as far as libc goes). Put their >functions in our libc and we end up with a bigger, bloated libc. >Make a new library and cause trouble for people wanting to build >the latest greatest Linux program on FreeBSD. Yet still, we shouldn't follow suit to giving in to libc bloating. Basically what our Linux brothers are doing is creating aliases for often used functions/series of functions. I don't think we want to bloat the library with this. I already changed configure.in on a emulator port I am coding on to check for libgnugetopt and .h. I think we need, next to the linuxulator, also a compatlinux lib. And if this causes trouble for people wanting to build the latest and greatest, then so be it. I'd rather have our base system as slick, well-thought out and what not as it is now. (And yes I know I asked about adding some getopt stuff to unistd.h, but I revised my statement on that. ;) ) On the topic of having to add non-standard libraries before compilation, you can also argue that adding non-standard functions to a standards library is also a no-no. =) If I look at the libcompatlinux (or whatever name it would get) more closely I would probably see a (g)libc(5) which is stripped down from all duplicate stuff in order to avoid claches with -lc. On an aside, glibc changes things in their sources almost every day. That's how `stable' their libc is. Stable being stable in terms of touching the sources. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>; Network/Security Specialist BSD: Technical excellence at its best Man is the Dream of the dolphin... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991030124309.A43205>