headers
Hiromichi Watari | 2 Apr 2011 23:57
Picon
Favicon

Problem linking STL::map with mysqld

Hi,
I'm trying to use STL container "map" with MySQL server but I'm getting the following link error at the very end.

CXXFLAGS="-DUSE_SYS_STL"

table.h has the following

#include <map> 
.
.
.
std::map<int,int> foo;

Are there any name conflicts, since table.h is eventually included in just about every source ?
I'm not sure if I can use namespace to work around this problem ?

Thanks,
Hiromichi

-----------------------------------------------------------------------------------------------------------------------------------------------------------
.
.
.
.
.
[100%] Building CXX object sql/CMakeFiles/sql.dir/sql_yacc.cc.o
[100%] Building CXX object sql/CMakeFiles/sql.dir/sql_builtin.cc.o
Linking CXX static library libsql.a
[100%] Built target sql
[100%] Building CXX object sql/CMakeFiles/mysqld.dir/main.cc.o
(Continue reading)

Permalink | Reply | 7 comments |
headers
Magnus Blåudd | 3 Apr 2011 19:33
Picon
Favicon

Re: Problem linking STL::map with mysqld

On 2011-04-02 23:57, Hiromichi Watari wrote:
> Hi,
> I'm trying to use STL container "map" with MySQL server but I'm getting the following link error at the very end.
>
>
> CXXFLAGS="-DUSE_SYS_STL"
>
> table.h has the following
>
> #include<map>
> .
> .
> .
> std::map<int,int>  foo;
>
>
> Are there any name conflicts, since table.h is eventually included in just about every source ?
> I'm not sure if I can use namespace to work around this problem ?
>

Hi Hiromichi,

the MySQl Server coee is normally compiled with the compiler flags set 
so that you need too explicitly instantiate the templates you use.

Instantiate your template with code like

template std::map<int,int>;

at the end ouf your source file.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hiromichi Watari | 3 Apr 2011 21:54
Picon
Favicon

Re: Problem linking STL::map with mysqld

Hi Magnus,
Thank you for your suggestion, I included the following at the end of table.h and I got similar and more errors.
Looks like I might have to write my own map container (oh nooooooooo !).
Hiromichi

bool is_simple_order(ORDER *order);

/****************************************************************************
  Used templates
****************************************************************************/
#ifdef HAVE_EXPLICIT_TEMPLATE_INSTANTIATION
template class std::map<int,int>;
#endif

#endif /* MYSQL_CLIENT */

#endif /* TABLE_INCLUDED */

----------------------------------------------------------------
[100%] Building CXX object sql/CMakeFiles/sql.dir/sql_yacc.cc.o
[100%] Building CXX object sql/CMakeFiles/sql.dir/sql_builtin.cc.o
Linking CXX static library libsql.a
[100%] Built target sql
[100%] Building CXX object sql/CMakeFiles/mysqld.dir/main.cc.o
Linking CXX executable mysqld
libsql.a(mysqld.cc.o): In function `std::map<int, int, std::less<int>,
std::allocator<std::pair<int const, int> > >::operator=(std::map<int, int, std::less<int>,
std::allocator<std::pair<int const, int> > > const&)':
/usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_map.h:253:
undefined reference to `std::_Rb_tree<int, std::pair<int const, int>,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tor Didriksen | 4 Apr 2011 09:15
Picon
Favicon

Re: Problem linking STL::map with mysqld

On 2011-04-03 21:54, Hiromichi Watari wrote:
> Hi Magnus,
> Thank you for your suggestion, I included the following at the end of table.h and I got similar and more errors.
> Looks like I might have to write my own map container (oh nooooooooo !).
> Hiromichi
>
>
>    
Hiromichi

You are probably linking with gcc rather than g++
Doing
   'export CXX=g++'
before configuring/building will most likely solve your problem.

-- didrik

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org
Permalink | Reply | 3 comments |
headers
Hiromichi Watari | 4 Apr 2011 16:49
Picon
Favicon

Re: Problem linking STL::map with mysqld

didrik
Thank you for your suggestion, I tried it but I got the exact same errors.
Hiromichi

--- On Mon, 4/4/11, Tor Didriksen <tor.didriksen <at> oracle.com> wrote:

> From: Tor Didriksen <tor.didriksen <at> oracle.com>
> Subject: Re: Problem linking STL::map with mysqld
> To: internals <at> lists.mysql.com, hiromichiwatari <at> yahoo.com
> Date: Monday, April 4, 2011, 3:15 AM
> On 2011-04-03 21:54, Hiromichi Watari
> wrote:
> > Hi Magnus,
> > Thank you for your suggestion, I included the
> following at the end of table.h and I got similar and more
> errors.
> > Looks like I might have to write my own map container
> (oh nooooooooo !).
> > Hiromichi
> >
> >
> >    
> Hiromichi
> 
> You are probably linking with gcc rather than g++
> Doing
>    'export CXX=g++'
> before configuring/building will most likely solve your
> problem.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sergei Golubchik | 4 Apr 2011 17:03
Favicon

Re: Problem linking STL::map with mysqld

Hi, Hiromichi!

For historical reasons MySQL uses -fno-implicit-templates.
Either disable that or instantiate all your templates explicitly.

To disable: remove it from configure.cmake.

To instantiate explicitly: look at the error message, it says, for
example

...  undefined reference to `std::_Rb_tree<int, std::pair<int const, int>,
std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int
const, int> > >::_M_erase(std::_Rb_tree_node<std::pair<int const, int> >*)'

which means, you need to put in your source, somewhere:

#ifdef HAVE_EXPLICIT_TEMPLATE_INSTANTIATION
namespace std {
template _Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >,
std::less<int>, std::allocator<std::pair<int const, int> >
>::_M_erase(std::_Rb_tree_node<std::pair<int const, int> >*);
}
#endif

and repeat for all undefined symbols.

On Apr 02, Hiromichi Watari wrote:
> Hi,
> I'm trying to use STL container "map" with MySQL server but I'm
> getting the following link error at the very end.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tor Didriksen | 4 Apr 2011 17:06
Picon
Favicon

Re: Problem linking STL::map with mysqld

On 2011-04-04 16:49, Hiromichi Watari wrote:
> didrik
> Thank you for your suggestion, I tried it but I got the exact same errors.
> Hiromichi
>
>    

Better suggestion:
Remove the '-fno-implicit-templates' flag (easy to find in configure.cmake)
Otherwise you will need explicit instantiation of a *lot* of things..

You will also have to link with g++ (verify that by using 'make 
VERBOSE=1' for the final link step)

-- didrik

> --- On Mon, 4/4/11, Tor Didriksen<tor.didriksen <at> oracle.com>  wrote:
>
>    
>> From: Tor Didriksen<tor.didriksen <at> oracle.com>
>> Subject: Re: Problem linking STL::map with mysqld
>> To: internals <at> lists.mysql.com, hiromichiwatari <at> yahoo.com
>> Date: Monday, April 4, 2011, 3:15 AM
>> On 2011-04-03 21:54, Hiromichi Watari
>> wrote:
>>      
>>> Hi Magnus,
>>> Thank you for your suggestion, I included the
>>>        
>> following at the end of table.h and I got similar and more
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hiromichi Watari | 5 Apr 2011 01:39
Picon
Favicon

Re: Problem linking STL::map with mysqld

Hi didrik and Sergei,

Thank you very much for taking time to answer my question.
I removed the -fno-implicit-templates flag.  Voila ! it works.

I owe you guys one, have a nice day !
Hiromichi

--- On Mon, 4/4/11, Tor Didriksen <tor.didriksen <at> oracle.com> wrote:

> From: Tor Didriksen <tor.didriksen <at> oracle.com>
> Subject: Re: Problem linking STL::map with mysqld
> To: "Hiromichi Watari" <hiromichiwatari <at> yahoo.com>
> Cc: internals <at> lists.mysql.com
> Date: Monday, April 4, 2011, 11:06 AM
> On 2011-04-04 16:49, Hiromichi Watari
> wrote:
> > didrik
> > Thank you for your suggestion, I tried it but I got
> the exact same errors.
> > Hiromichi
> >
> >    
> 
> Better suggestion:
> Remove the '-fno-implicit-templates' flag (easy to find in
> configure.cmake)
> Otherwise you will need explicit instantiation of a *lot*
> of things..
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zardosht Kasheff | 6 Apr 2011 18:32
Picon

Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?

Hello all,

Another question on this. Is the ONLY way an frm file may change is if
an alter table occurs that is a metadata change only?

-Zardosht

On Wed, Mar 30, 2011 at 10:14 AM, Dmitry Lenev <Dmitry.Lenev <at> oracle.com> wrote:
> Hello Zardosht!
>
> * Zardosht Kasheff <zardosht <at> gmail.com> [11/03/30 17:56]:
>> Actually, let me put this question another way. Suppose during a call
>> to handler::open, we return an error because the frm file generated
>> from the TABLE* parameter does not match the frm file we stored on
>> disk (due to some system crash at an inopportune time).
>>
>> What, as a storage engine, can we do to get the user back to a well
>> known state where the frm file he is using matches what we have on
>> disk?
>
> Here is what, AFAIK, NDB does.
>
> If during call to handler::ha_open() it is discovered that local version
> of table/.FRM is out-of-date HA_ERR_TABLE_DEF_CHANGED error is returned.
>
> Upon getting such error code in server layer acquires appropriate locks,
> invalidates corresponding entry in table definition cache and then
> calls ha_create_table_from_engine() routine. The latter essentially calls
> discover method of handlerton to get new version of .FRM and writes it
> to disk.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jonas Oreland | 6 Apr 2011 23:23
Picon
Favicon

Re: storage engine access to serialized version of a TABLE or TABLE_SHARE?

On 04/06/11 18:32, Zardosht Kasheff wrote:
> Hello all,
> 
> Another question on this. Is the ONLY way an frm file may change is if
> an alter table occurs that is a metadata change only?

if I understand your question correctly you should
look in handler.cc : update_frm_version
it makes a pwrite to frm-file, updating version...

/Jonas

> 
> -Zardosht
> 
> On Wed, Mar 30, 2011 at 10:14 AM, Dmitry Lenev <Dmitry.Lenev <at> oracle.com> wrote:
>> Hello Zardosht!
>>
>> * Zardosht Kasheff <zardosht <at> gmail.com> [11/03/30 17:56]:
>>> Actually, let me put this question another way. Suppose during a call
>>> to handler::open, we return an error because the frm file generated
>>> from the TABLE* parameter does not match the frm file we stored on
>>> disk (due to some system crash at an inopportune time).
>>>
>>> What, as a storage engine, can we do to get the user back to a well
>>> known state where the frm file he is using matches what we have on
>>> disk?
>>
>> Here is what, AFAIK, NDB does.
>>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane