Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.misc Subject: Re: Barriers to NetBSD/FreeBSD binary compatibility? Date: 15 Aug 1994 23:33:23 GMT Organization: Weber State University, Ogden, UT Lines: 90 Message-ID: <32ou03$c7u@u.cc.utah.edu> References: <32okpu$17u@spool.cs.wisc.edu> NNTP-Posting-Host: cs.weber.edu In article <32okpu$17u@spool.cs.wisc.edu> jcargill@grilled.cs.wisc.edu (Jon Cargille) writes: ] ] Can someone outline the reasons behind the lack of binary ] compatibility between NetBSD and FreeBSD? ] ] This seems like a major bummer for the user community, and I think ] it's one of the reasons that there are fewer "neatly packaged" ] freeware programs for *BSD than for "the other free unix clone" ] (mention no names, incite no flames... ;-) ] ] The "ports" collection for FreeBSD is very nice, but I've heard that ] they won't run for NetBSD users. ] ] Seriously, I think everyone would benefit if NetBSD and FreeBSD could ] both run the same binaries. But from what I understand, they can't. ] ] Why not? You neglect to say which versions of NetBSD and FreeBSD you are using. I will assume you are running a NetBSD with shared libraries, meaning one without an official revision number associated with it? The differences between the systems as far as running each others binaries are primarily differences in the level of POSIX conformance, and specifically XPG3/XPG4 conformance with regard to the static _ctype_ locale support. When you link with a shared library, you are not actually doing dynamic linking -- you are doing partially dynamic linking. Calling stubs for functions, a jump table, and all static and global data (like constant strings) are copied into your image. The only thing that is really shared is the text (code) portion of the library. So two systems with otherwise identical interfaces can result in an incompatible shared library because of the data objects in the library -- even those object local to one or more routines in a library -- since the data from one library will be used by another. This is not strictly a free OS phenomenon: many Dell UNIX X programs will not run on UnixWare (for instance) without some library hacking because Dell, in their finite wisdom, put bcopy and family in the X library, and many programs only indirectly (through the Xlib) using bcopy fail to find it in the UnixWare Xlib (there are several other symbols that are the same way). It is possible to run these binaries anyway -- by copyining over the FreeBSD shared libraries that reference the FreeBSD linked binaries statically-linked-library-data in the expected manner. This will, unfortunately, result in some problems with NetBSD binaries if you install the FreeBSD libraries on tof of the NetBSD libraries, so you will need to fut them in their own directory (like /usr/FreeBSD_lib, with a symbolic link from /FreeBSD_lib). The next thing you will have to do is "wrapper" the programs with a shell script that runs the real program after setting LD_LIBRARY_PATH; for this to work, you will need to unset the "cheat" paths in ldconfig, or the NetBSD libraries will be given precedence. This will result in a slightly longer load time for all programs... you want to get rid of that, then you need to run homgenous (all NetBSD or all FreeBSD) binaries. My typical shell script is the same shell script for all binaries, with a hard link to each binary name. In it, I set the LD_LIBRARY_PATH, then run the command fb_$0 (after renaming all my FreeBSD originated binaries from <name> to fb_<name>). To resolve the discrepancies between libraries, you'd need to convince the parties in both camps that they should spend 20% of their time talking to each other instead of coding -- this leads to a number of bad OEM situations (just like real OS vendors) because of differences in schedules and level of operability. Personally, I'd put NetBSD's libraries as quite technically advanced over FreeBSD's, but FreeBSD tends to have a more regular and frequent release schedule (the second being more important for users who don't want to roll their own stuff, while the first is more important from a technical perspective). There is a window of opportunity for this in the switch to the 4.4 source base, since neither camp has yet made a release to be incompatible with: so get politicing, and you too can be a hero to millions! Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.