From: Dan Nelson
Date: August 23 2002 7:09pm
Subject: Re: Still trying to build libmysqld.a on Tru64
List-Archive: http://lists.mysql.com/mysql/117918
Message-Id: <20020823190955.GA54162@dan.emsphone.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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
compiler.
 
>      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 /usr/shlib/libc.so
> #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) "net_serv.cc":533
> #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) "libmysqld.c":620
> #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") "webengine_db.c":1462
> #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 wsd-install

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.

-- 
	Dan Nelson
	dnelson@stripped