In the last episode (Aug 23), Randall Severy said:
> At 11:28 AM 8/23/2002 -0500, Dan Nelson wrote:
> > That actually shouldn't be a problem. Binutils and gcc configures
> > itself to match the file formats of the host system.
> Yup, that's what I thought as well, which is why I struggled for
> nearly a week to figure it out. The linker simply refused to find
> (resulting in "Undefined" errors) symbols in libmysqld.a that were
> compiled from C++ source files (objects built from C source files
> were fine) when libmysqld.a was built using GNU ar instead of the
> Compaq ar utility.
Aah. C++ is the one exception, since the ABI is still changing. You
always have to make sure all your C++ code was compiled with the same
> As it turned out, this crash was a red herring, as the
> wsd-install program was still linked with the GCC-built libmysqld.a,
> which has all kinds of other problems. I rebuilt wsd-install with
> debugging and with the 4.0.2 libmysqld.a and got a completely
> different crash (but nearly identical to the 'wsd' program crash):
> Assertion failed: vio->packets, file lib_vio.c, line 118
> Abort process (core dumped)
> Core file produced from executable 'wsd-install'
> Thread 1 terminated at PC 0x3ff8057d728 by signal ABRT
> #13 0x3ff801c22b0 in __assert(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 0x3ffc0184000) in
> #14 0x1200ce2f0 in vio_read(vio=0x140071300, buf=0x1408c0d60="\377\033\004Unknown
> table \'wsd_users\'", size=4) "lib_vio
> #15 0x1200e04b4 in my_real_read(net=0x140042380, complen=0x11fffa700)
> #16 0x1200e09bc in my_net_read(net=0x140
> #17 0x1200d8000 in net_safe_read(mysql=0x140042380) "libmysqld.c":95
> #18 0x1200d94d0 in read_rows(mysql=0x140042380, mysql_fields=0x0, fields=5)
> #19 0x1200db18c in mysql_read_query_result(mysql=0x140042380) "libmysqld.c":1163
> #20 0x1200db670 in mysql_real_query(mysql=0x140042380, query=0x11fffa9a8="drop table
> wsd_users", length=20) "libmysqld.c":1284
> #21 0x1200daf38 in mysql_query(mysql=0x140042380, query=0x11fffa9a8="drop table
> wsd_users") "libmysqld.c":1116
> #22 0x1200a30d0 in query_db(query_string=0x11fffa9a8="drop table wsd_users")
> #23 0x12009c8b4 in load_database(table_filename=0x11fffbceb="wsd.dbschema",
> defprefix=0x11fffb130="wsd", dbprefix=0x11fffb188="") "webinstall.c":2970
> #24 0x12009f680 in process_install() "webinstall.c":3706
> #25 0x12009faa0 in main(argc=3, argv=0x11fffc018) "webinstall.c":3780
> #26 0x120091968 in __start(0x3ffc01842c8, 0x6, 0x1, 0x1, 0x14, 0x3ffc0184000) in
Still wrapped :)
> It looks like both problems occur when a database error occurs
> (this one was "Unknown table", the previous one was "Table doesn't
> exist"). When initializing the database, the wsd-install program
> issues a "drop table" command prior to every "create table" command.
> For brand-new databases, the error from the "drop table" command is
> ignored. But instead of the normal MySQL error handling, these
> errors appear to be triggering that assert call in vio_read.
It looks like a mysql developer will have to look at vio_read and
figure out why the assert's failing.