From: Warren Young Date: December 1 2007 6:16am Subject: Re: linking mysql++ 2.3.2 List-Archive: http://lists.mysql.com/plusplus/7204 Message-Id: <4750FC3C.506@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Hudson wrote: > /usr/local/include/mysql++/common.h:157: error: 'MYSQL_FIELD' does not name > a type I don't see how you can get this error without an earlier one complaining that one of the MySQL C API headers couldn't be found. Regardless, it probably means the directory containing those files isn't in your #include path. How you set that up in Eclipse is something you'll have to figure out; I've only used Eclipse briefly, and it was for PIC microcontrollers, not very high on the list of popular deployment platforms for MySQL++. > (I'm using multiple threads and don't want to define a seperate SSQLS for > each thread or put a lock on the .table(str) method between each insert., if > that makes any sense..) Um, no, can't say it does make sense. SSQLS::table() returns a reference to const char*, and the only reason it isn't char* const instead is because you might want to change the table name _once_ if the SSQLS has a different name than the table it belongs to. If you do need that change, it can happen while only a single thread is running, so there's no chance for a race condition. Unless, I suppose, you're doing something weird like reusing one SSQLS for multiple tables just because they share the same structure. That's just lazy. One table per SSQLS, one SSQLS per table. > /usr/bin/ld: Undefined symbols: > Wdbaccesstypes::equity_row::names You've defined MYSQLPP_SSQLS_NO_STATICS globally instead of defining it for all modules but one. That leaves two statics undefined per SSQLS. Unfortunately, the complete consequences of this macro were only documented here on the mailing list until recently. It's documented in what will be the v3 user manual (section 5.5, ATM) if you want to check out the svn version and build it....