This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
From: rodneybrown@pmsc.com Date: Mon, 15 Feb 99 14:05:23 -0500 Snapshot gdb-19990209 fails to build because of missing opcode/Makefile all target, when configured on AIX-4.2.0, UnixWare 2.1.1 and SunOS 4.1.3. NB - while I'm patching up rather than pulling down a full tar.gz, the brik -Cb < gdb.crc worked & I did (belatedly) run the postpatch scripts. I think this is all resolved now. There is some experimentation going on in opcodes-land... Further look at missing SOLIB_.* externals building on AIX-4.2.0 I think that the relevant defines could be copied straight from the coff-solib.h and the include for xcoffsolib.h be pushed into a config/ header file. Copying the definitions should work, because they are just placeholders until somebody besides HP defines them usefully for their OS. Actually, looking at all of the *solib.h stuff, I seem some candidates for simplification - one file (coff-solib.h) is never used, some are used in inappropriate places, and they all go to a lot of trouble to use macros, when a function pointer would be just as easy and not require a bunch of #define/#include trickery. The reason I haven't patched this in is that gdb/eval.c includes xcofflib.h for a struct vmap definition. This whole thing is moderately tangled - it's ugly for AIX because the main program can be in a dynamically loaded library, which makes trouble for GDB algorithms that expect to know where to find _start and suchlike. I hear rumors of IBMers hacking on all this anyway, so there's not much point in going to be a lot of trouble on xcoff solib stuff until we hear more about what they're up to. Stan