GEustace@massey.ac.nz (Glen Eustace) (12/04/89)
I have just read a comment by Carl about 'att' programs using UCB
networking? How can you do this? We have wanted to use the x25
functions and the UCB socket functions in the same program. The x25
stuff is in the att libraries, the socket stuff in the ucb ones. We have
taken heed of the comments posted earlier about not linking a program
with both libraries, so, what's the solution?
--
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand. Phone: +64 63 69099 x7440 GMT+12
E-Mail via Internet: G.Eustace@massey.ac.nz
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>csg@pyramid.pyramid.com (Carl S. Gutekunst) (12/07/89)
In article <420@massey.ac.nz> GEustace@massey.ac.nz (Glen Eustace) writes: >I have just read a comment by Carl about 'att' programs using UCB >networking? How can you do this? I *knew* I shouldn't have said that. Mixing universes can be done either of two ways: - Use the syscall(2) indirect system call to get the facility you want from the other universe. This works well for simple things, like flock(2) or gethostname(2). - Separate your att and bsd needs into separate source files, compile them in their appropriate universes, and manually link in both libc.a's. This is the only reasonable way to do Berkeley networking, and was the technique used when we added BSD networking to HoneyDanBer UUCP. The problem with mixing library modules *is* significant, and not for the weak of heart. You (reasonably) can only have one of any given function. So things that exist in both universe but are not compatible -- all of stdio, for exam- ple -- will be accessible only to the source modules from one universe. This actually worked out very well in adding BSD networking to HDB. tcpcall() was excised from callers.c into its own source module, and compiled in the BSD universe. It issued no stdio function calls, so it was very nearly a dropin. >We have wanted to use the x25 functions and the UCB socket functions in the >same program. The x25 stuff is in the att libraries, the socket stuff in >the ucb ones. That's a bunch of rot. Just compile everything in the UCB universe. X.25 will work just fine. (Actually, there is a problem with process groups that it does do better in the att universe than the ucb universe. But unless you are making unusually sophisticated use of signals and multitasking, you won't see it.) <csg>