README.aix

   1 $Id: README.aix,v 1.4 2000/10/08 17:16:29 gerald Exp $
   2
   3 After much work and toil, Craig Rodrigues was able to compile libpcap
   4 and Ethereal on AIX 4.3.2.  His odyssey is document in various e-mails
   5 at http://www.ethereal.com/lists/ethereal-dev/199911/
   6
   7 Here are a few excerpts.  Note that, to configure "libpcap" to use DLPI
   8 rather than BPF (which it'll apparently use by default on AIX),
   9 specifying the flag
  10
  11         --with-pcap=dlpi
  12
  13 to the "configure" script for "libpcap" should do the trick.
  14
  15 The source code changes to Ethereal mentioned below should be in the
  16 current source tree.  The changes to the GLib configure script is in
  17 GLib 1.2.7; the changes for the "-lgdk" problem are probably still
  18 necessary in the current version of GTK+.
  19
  20 Subject: Re: [ethereal-dev] Re: [ethereal-users] Problems compiling 0.7.7 under AIX 4.3.2
  21 From: Gilbert Ramirez <gram@xiexie.org>
  22 Date: Fri, 5 Nov 1999 16:58:17 -0600
  23 To: Guy Harris <guy@netapp.com>
  24 Cc: Craig Rodrigues <rodrigc@mediaone.net>, ethereal-dev@zing.org
  25
  26
  27 On Fri, Nov 05, 1999 at 01:42:44PM -0600, Guy Harris wrote:
  28 >
  29 >
  30 > Hmm.
  31 >
  32 > Looks suspiciously similar to the previous error; have you tried
  33 > recompiling GTK+ with "xlc_r"?
  34
  35 I believe glib and gtk+ should both be compiled with xlc_r. I haven't
  36 compiled on AIX in a long time, but I think it's because glib is including
  37 pthread stuff, so the re-entrant C library, libc_r, is needed.
  38
  39
  40 Compiler Invocation
  41
  42 When compiling a multi-threaded program, you should invoke the C compiler
  43 using one of the following commands:
  44
  45 xlc_r
  46     Invokes the compiler with default language level of ansi.
  47 cc_r
  48     Invokes the compiler with default language level of extended.
  49
  50
  51 These commands ensure that the adequate options and libraries are used to be
  52 compliant with the X/Open Version 5 Standard. The POSIX Threads
  53 Specification 1003.1c is a subset of the X/Open Specification.
  54
  55 The following libraries are automatically linked with your program when using these commands:
  56
  57 libpthreads.a
  58             Threads library.
  59 libc.a
  60             Standard C library
  61
  62
  63 For example, the following command compiles the foo.c multi-threaded C source file and produces the foo executable file:
  64
  65 cc_r -o foo foo.c
  66
  67 See the cc command for more information about C For AIX.
  68
  69
  70 --gilbert
  71
  72
  73 To: ethereal-users@zing.org
  74 Subject: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
  75 From: Craig Rodrigues <rodrigc@mediaone.net>
  76 Date: Mon, 8 Nov 1999 10:46:25 -0500
  77 Cc: ethereal-dev@zing.org
  78
  79
  80 Hi,
  81
  82 After much sweat and toil, I have managed to get gtk 1.2.6 to
  83 compile and not dump core under AIX.  The solutions were to
  84 (1) apply the attached patch to the configure.in in the glib-1.2.6
  85 subdirectory
  86
  87 (2)  In the file gtk+-1.2.6/gtk/Makefile, add a link flag -lgdk to link
  88 in gdk.
  89
  90 I have submitted (1) to the gtk-devel mailing list where it has been
  91 accepted.  (2) is an uglier problem, but for now, adding -lgdk by hand
  92 seems to work.
  93
  94 Now I have a problem....I compiled gtk, and that works.
  95 I compiled ethereal (after some minor mods), and it starts,
  96 but when I click on Capture -> Start, I get:
  97
  98 "There are no network interfaces that can be opened."
  99
 100 I am running as root, so I don't think permissions are a problem.
 101
 102 Any ideas?
 103
 104 Thanks.
 105 --
 106 Craig Rodrigues
 107 http://www.gis.net/~craigr
 108 rodrigc@mediaone.net
 109
 110 *** configure.in.old    Thu Oct  7 17:27:43 1999
 111 --- configure.in        Sun Nov  7 19:34:36 1999
 112 ***************
 113 *** 795,809 ****
 114           fi
 115           if test "$ac_cv_func_getpwuid_r" = "yes"; then
 116                   AC_MSG_CHECKING(whether getpwuid_r is posix like)
 117 !                       # getpwuid_r(0, NULL, NULL, 0) is the signature on
 118 !                       # solaris, if that is not found, the prog below won't
 119 !                       # compile, then the posix signature is assumed as
 120 !                       # the default.
 121 !                       AC_TRY_COMPILE([#include <pwd.h>],
 122 !                               [getpwuid_r(0, NULL, NULL, 0);],
 123 !                               [AC_MSG_RESULT(no)],
 124 !                               [AC_MSG_RESULT(yes)
 125 !                               AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
 126           fi
 127   fi
 128   if test x"$have_threads" = xposix; then
 129 --- 795,809 ----
 130           fi
 131           if test "$ac_cv_func_getpwuid_r" = "yes"; then
 132                   AC_MSG_CHECKING(whether getpwuid_r is posix like)
 133 !                       # The signature for the POSIX version is:
 134 !                       # int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)
 135 !                       AC_TRY_COMPILE([#include <pwd.h>
 136 !                                         #include <sys/types.h>
 137 !                                         #include <stdlib.h>],
 138 !                               [getpwuid_r((uid_t)0, NULL, NULL, (size_t)0, NULL);],
 139 !                               [AC_DEFINE(HAVE_GETPWUID_R_POSIX)
 140 !                               AC_MSG_RESULT(yes)],
 141 !                               [AC_MSG_RESULT(no)])
 142           fi
 143   fi
 144   if test x"$have_threads" = xposix; then
 145
 146
 147
 148 To: ethereal-dev@zing.org
 149 Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal problem
 150 From: Craig Rodrigues <rodrigc@mediaone.net>
 151 Date: Wed, 10 Nov 1999 12:18:47 -0500
 152
 153
 154
 155 Hi,
 156
 157 OK, I'm getting closer and closer to this working on AIX.
 158
 159 Things I've done:
 160
 161 (1) In a bunch of places in the code I removed '//' style C++ comments
 162 which the IBM C compiler didn't like.
 163
 164 (2) I also found some places in the code like:
 165
 166 enum some_enum {  FOO, BAR, };
 167
 168 IBM C did not like the trailing "," after BAR.
 169
 170 (3) In packet-ipv6.h, IPV6_VERSION is defined, but that is already
 171 defined in <netinet/in.h> on AIX 4.3, so for now I just commented that out.
 172
 173 (4) in packet-afs.c, when it sucks in <netinet/in.h>,  in.h sucks in
 174 <sys/machine.h> which defines LITTLE_ENDIAN.  This conflicts with
 175 LITTLE_ENDIAN in globals.h.  So what I did was, in globals.h, I added:
 176
 177 #ifdef HAVE_NETINET_IN_H
 178 #include <netinet/in.h>
 179 #endif
 180
 181 So after doing all these things, I can compile ethereal and run it.
 182 I can list the
 183 correct network interfaces on my system: lo0 and en0.  However,
 184 when I start capturing packets on en0, they are all of the protocol type
 185 "TRMAC" and "TR".  The only problem is, I'm not on a Token Ring network.
 186
 187 Any ideas?
 188
 189 No. Time        Source                Destination           Protocol   Info
 190 1 0.000000    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 191 2 0.210304    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 192 3 0.926080    0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 193 4 0.4236416   0a:30:a1:08:00:45     06:74:60:08:00:5a     TR   Token-Ring Unknown
 194 5 0.4712064   6f:06:74:60:08:00     5a:8a:30:a1:00:00 TR MAC Unknown Major Vector: 127
 195
 196
 197 ---------------------
 198 It turns out that libpcap was using IFT_* numbers instead of DLT_* numbers for
 199 link types. That has been fixed
 200 ---------------------
 201
 202
 203 To: tcpdump-workers@tcpdump.org
 204 Subject: [ethereal-dev] Sucess with libpcap under AIX
 205 From: Craig Rodrigues <rodrigc@mediaone.net>
 206 Date: Sat, 20 Nov 1999 03:34:50 -0500
 207 Cc: ethereal-dev@zing.org
 208
 209
 210 Hi,
 211
 212 I have managed to successfully compile and use the latest
 213 snapshot of libpcap under AIX using DLPI.  bpf is majorly
 214 brain-dead under AIX, and very unsupported.  Rather than
 215 find all the bugs in AIX's bpf, I decided to try using
 216 dlpi, which is officially supported.
 217
 218 The first step is to get the setup right.  To determine if
 219 you have the dlpi driver loaded correctly, type:
 220 strload -q -d dlpi
 221
 222 If the result is:
 223 dlpi: yes
 224
 225 then you are ready to use dlpi.
 226
 227 If you get:
 228 dlpi: no
 229
 230 Then you need to type:
 231 strload -f /etc/dlpi.conf
 232
 233 Check again with strload -q -d dlpi that the dlpi driver is loaded.
 234
 235 I had to make one minor code change to pcap-dlpi.c.  Maybe someone
 236 can explain it to me, because I am not familiar with dlpi or
 237 streams programming.  It took me hours to figure this out, because
 238 I'm not familiar with dlpi.
 239
 240 In pcap-dlpi.c, lines 316-320:
 241 #if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
 242        if (dlbindreq(p->fd, 0, ebuf) < 0 ||
 243            dlbindack(p->fd, (char *)buf, ebuf) < 0)
 244             goto bad;
 245 #endif
 246
 247 I changed it to:
 248 #if !defined(HAVE_HPUX9) && !defined(HAVE_HPUX10_20) && !defined(sinix)
 249        if (dlbindreq(p->fd, 1620, ebuf) < 0 ||
 250            dlbindack(p->fd, (char *)buf, ebuf) < 0)
 251             goto bad;
 252 #endif
 253
 254 I picked the number 1620 out of thin air.  The second parameter
 255 to dlbindreq() sets the value of dl_sap.  This dl_sap
 256 value is then passed along to the DLPI driver through
 257 the DL_BIND_REQ primitive.  I guess that it cannot be 0 under
 258 AIX, but I'm not sure.
 259
 260 If someone knows anything about DLPI, I'd appreciate a clarification.
 261 Basically, I am just using the DLPI specification at:
 262 http://www.opengroup.org/onlinepubs/009638599/ which is pretty good.
 263 The AIX documentation is not so well written.
 264
 265 But basically, after I fixed up pcap-dlpi.c, I managed to get libpcap
 266 working under AIX.  This enabled me to successfully run Ethereal,
 267 ie. all the packets on my Ethernet network correctly showed up
 268 as Ethernet and not Token Ring in the Ethereal screen.
 269
 270 YAY!
 271 --
 272 Craig Rodrigues
 273 http://www.gis.net/~craigr
 274 rodrigc@mediaone.net
 275
 276 Date: Thu, 11 Nov 1999 23:47:02 -0500
 277 From: Craig Rodrigues <rodrigc@mediaone.net>
 278 To: ethereal-dev@zing.org
 279 Subject: Re: [ethereal-dev] AIX: gtk problem solved, now an ethereal  problem
 280
 281 On Thu, Nov 11, 1999 at 11:50:23AM -0800, Guy Harris wrote:
 282 > > The only differences between gtkclist.c in the gtk distribution and
 283 > > gtkclist.c in the ethereal distribution relate to the ROW_ELEMENT
 284 > > macro.  It looks like an optimization for retrieving the GList item
 285 > > when the requested row is the last row in the list.
 286 >
 287 > Yup - as per my other mail, Ethereal does that rather a lot when
 288 > building the CList, and the optimization changes quadratic behavior to
 289 > linear behavior.
 290 >
 291 > > Any ideas why this causes trouble?
 292 >
 293 > Mismatches between the layouts of data structures as declared in the
 294 > "gtk/gtk*.h" files in the Ethereal source tree and the layouts as
 295 > declared in the header files in the GTK+ source (either due to header
 296 > file differences - although the header files appear to be identical to
 297 > the GTK+ 1.2.6 ones - or due to compiler behavior differences)?
 298
 299 I tried stepping things through the debugger, and constantly
 300 hit the same segfault inside gdk_string_width(), line 308 of gdkfont.c
 301
 302 Fails on line: switch(font->type),
 303 where *font is: (type = -1, ascent = -1, descent = -1)
 304
 305 Stack trace:
 306 gdk_string_width(font = 0x7caf01a4, string = "../"), line 308 in "gdkfont.c"
 307 gtk_file_selection_populate(fs = 0x20094468, rel_path = "", try_complete = 0), line 1341 in "gtkfilesel.c"
 308 gtk_file_selection_init(filesel = 0x20094468), line 513 in "gtkfilesel.c"
 309 gtk_type_new(0xc315), line 403 in "gtktypeutils.c"
 310 gtk_file_selection_new(title = "Ethereal: Open Capture File"), line 524 in "gtkfilesel.c"
 311 file_open_cmd_cb(0x200640f4, 0x0), line 79 in "file_dlg.c"
 312
 313 Removing gtkclist.o from libui.a and recompiling removed this problem.
 314
 315 Any ideas?  I'm stumped.
 316
 317 --
 318 Craig Rodrigues
 319 http://www.gis.net/~craigr
 320 rodrigc@mediaone.net