Path: utzoo!attcan!uunet!decwrl!elroy.jpl.nasa.gov!turnkey!jackv From: jackv@turnkey.tcc.com (Jack F. Vogel) Newsgroups: comp.unix.aix Subject: Re: bind 4.8.x and AIX 1.2 ? Message-ID: <1990Aug03.155517.27053@turnkey.tcc.com> Date: 3 Aug 90 15:55:17 GMT References: <26b7929a.68e3@petunia.CalPoly.EDU> Reply-To: jackv@turnkey.TCC.COM (Jack F. Vogel) Distribution: comp Organization: Turnkey Computer Consultants, Westchester, CA Lines: 67 In article <26b7929a.68e3@petunia.CalPoly.EDU> booga@polyslo.CalPoly.EDU (Steve Jankowski [cut]) writes: [...stuff about the nameserver being back-level deleted...] >We have the same problem here and I've started a port of named from >4.8.1 to AIX 1.2 on a PS/2. The problem with AIX (especially the >PS/2) is their (ahem) crappy C compiler. named uses bit fields to pick >apart request packets. This is a less than portable solution, but >it's ok since most C compilers honor the spirit of bit fields and >pack the bits into the smallest space possible. But, the AIX >compiler just makes every bit field 32-bits and leaves it at that. Yup, ran into this problem in the new port I mentioned in a previous posting. Interestingly enough, the 370 Metaware compiler does things correctly! However there isn't any option to the 386 compiler to keep it from doing this, oh well :-{. >If you look in arpa/nameser.h you'll notice that they've put in >two unsigned chars and a bunch of macros to replace the bit fields. >(this is in the structure that represents a request packet) >This means lots of manual labor to change each reference to the >structure. I started the work, but stopped when I heard that >we would be getting AIX 1.2 which reportedly has named from >4.8.1. But I just string'ed the binary and I'm not impressed; >the dates in the file are all from 1986. The new BIND is in what I believe is called the July preventative update as I said previously, I don't know if you have to request it or if you get it automatically. The easiest way to tell if it is installed is to see if you have a new binary, /etc/named-xfer. This is the asyncronous zone transfer facility, if its there you have the new nameserver. Now a little bit on how the port was done... In my first attempt at the code I went ahead as you described and used the macros, and as you noticed this is a fair amount of work and change to the code. Then a friend working in our Boston office (Thanks Brad!) came up with a creative way around this problem and this is what I actually implemented in the code that's shipping. The header structure as shipped by Berkeley contains an unsigned short id variable and then 2 unsigned chars carved up as the bitfields. What I did was make one unsigned int as a 32-bit bitfield and just declare the first 16 bits as the id. Doing this the PS/2 compiler leaves things alone. You can take a look at this change after installing the update. The important thing to observe if you use this structure is that you must define BIT_ZERO_ON_LEFT for the 370 and BIT_ZERO_ON_RIGHT for the PS/2. Also, just as a tip for those out there who might want to build nslookup or other related tools, be sure you use -DBSD=4.3 and -D_BSD in your compiler defines in addition to those mentioned above, then in your link command be sure and include -lbsd. With the new nameser.h and these proper defines the BSD source should build and work without modification. >If I actually go through with the port and get it working, I'll >let people know. Hope you don't waste too much time before you see this :-}. I suggest you call your IBM representative and request the latest preventative update for this fix. As I mentioned in a previous followup, I also finished the sendmail 5.61 port and it is also in this update. Disclaimer: I get paid to solve problems, not to speak for LCC or IBM. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM