stl_list undefined error in compiling mysql

[Edward Peschko]

All,

Got the following error in compiling the latest version of mysql
(mysql-5.6.13). I'm not sure if this is a gcc problem or a mysql
problem, but it looked very standard library related, so I thought I'd
point it out here.

I look at the stl_list.h file and see it is in an #if block, with

#if __cplusplus >= 201103L

#

evaluating as false even though the version of gcc is 4.8.1. Doing a:

gcc -dM -E /tmp/test.p

shows __cplusplus defined as:

#define __cplusplus 199711L

which is clearly wrong for 4.8.1 (isn't it?)

Any assistance on parsing or dealing with this error would be very
much appreciated - just tried the alternate block in stl_ist.h without
success.

Ed

../../innobase/libinnobase.a(fil0fil.cc.o): In function
`std::list
>::_M_insert(std::_List_iterator, char co
nst* const&)':
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
../../../sql/libsql.a(handler.cc.o): In function `std::list
>::_M_insert(std::_List_iterator, char const* co
nst&)':
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
../../../sql/libsql.a(mysqld.cc.o): In function `std::list >::_M_insert(std::_List_iterator, THD*
const&)':
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
../../../sql/libsql.a(mysqld.cc.o): In function `std::list >::_M_erase(std::_List_iterator)':
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1570: undefined
reference to `std::__detail::_List_node_base::_M_unhook()'
../../../sql/libbinlog.a(binlog.cc.o): In function
`std::list
>::_M_insert(std::_List_iterator, std::string
const&)':
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
/pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined
reference to 
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'

default system path questions

[Edward Peschko]

All,

I found much to my dismay today that -I doesn't always work as
intuited. Namely, if I set CFLAGS to:

-I/path/to/gcc/include

where the default system path is:

/path/to/gcc/lib/gcc/i686-pc-linux-gnu/3.4.6/include
/usr/local/include
/path/to/gcc/include
/usr/include

the expected behavior would be to have the libraries searched before
any of the above are searched. But no, gcc silently ignores this
request, and finds the unwanted version of the include that I want in
/usr/local/include, due to not 'wanting to defeat system headers'.

This I guess I can understand (although it would be very nice to get a
warning). What I can't understand is why /usr/local/include is placed
*above* /path/to/gcc/include in this ordering. Since when is a
directory that has arbitrary installs from userland considered a
necessary part of system headers? Shouldn't the detection order be:

/path/to/gcc/lib/gcc/i686-pc-linux-gnu/3.4.6/include
/path/to/gcc/include
/usr/local/include
/usr/include

if /usr/local/include is to be included at all..

And come to think of it, why *is* the -I ignored? Why doesn't the
preprocessor just trust the user and that they know what they are
doing? Why is -nostdinc even necessary?

Ed

ld linking behaviour

[Edward Peschko]

All,

When I link with a shared library, for example:

 env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC
-L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
/usr/lib/libconfig.so

the ld command follows the version, and links to the specific version
of the library, not the library itself. An ldd dump shows :

prompt% ldd blib/arch/auto/Conf/Libconfig/Libconfig.so
linux-gate.so.1 =>  (0xe000)
libconfig.so.8 => /usr/lib/libconfig.so.8 (0xf7fe2000)
libc.so.6 => /lib/tls/libc.so.6 (0xf7eb7000)
/lib/ld-linux.so.2 (0x56555000)


How can I make it so that the ld command instead links to the
libconfig.so library itself (so that if a newer, binary compatible,
version of libconfig comes out it can use it transparently)?

I can do:

env LD_PRELOAD=/usr/lib/libconfig.so ldd
blib/arch/auto/Conf/Libconfig/Libconfig.so

and get the desired result, but I'd rather not deal with extra
environment settings..

Thanks much,

Ed

gcj build issues.

[Edward Peschko]

All,

I'm just curious - what version of gcc has the latest stable gcj? I've
been trying to build gcc-4.4.0 on solaris and have been running into
multiple issues:

1. gperf (version 3.0.4) generates incorrect code killing the build:

../.././gcc/cp/cfns.gperf:84: error: 'gnu_inline'
attribute present on 'libc_name_p'
../.././gcc/cp/cfns.gperf:9: error: but not here
 gmake[3]: *** [cp/except.o] Error 1

2. hardcoded '/bin/sh' references in files cause build
incompatibilities (fails on solaris -
 Comparing stage 2 to stage 3.. since they are hardcoded,
not fixable by setting
 CONFIG_SHELL)

3. ecj not part of the build, hence causing at runtime:

 ld.so.1: ecj1: fatal: libgcc_s.so.1: version `GCC_4.2.0' not
found (required by file
/userdata/ebay/interface/FI/tools/beta/lib/libgcj.so.10)
 ld.so.1: ecj1: fatal: libgcc_s.so.1: open failed: No such
file or directory
 gcj: Internal error: Killed (program ecj1)
Please submit a full bug report.
See  for instructions.

I can get through 1 and 2, but 3 has me stumped. Why isn't ecj
encorporated in the build (if it is a dependency), and where is an ecj
that works with gcc-4.4?

I'll submit bugs for these, but really - where is there a
tinderbox-like compile farm which shows both status of automated
builds on different OSes, and dependencies to make these automated
builds successful? I would think this would save tons of time.

Ed

using gcc's lexer/parser (was: Re: 'recording' program execution.)

[Edward Peschko]

ok,

wrt the below, I was giving it some thought, and was wondering how
usable the gcc lexer/parser combo was by itself, how 'pluggable' it
was - my hope was that I could take the lexer/parser and instead of
making an executable out of the incoming code, I could transform the
code in place, ie: add extra code of my own choosing that I would then
compile with gcc.

How feasible would that be? Where's a good place to start?

Thanks,

Ed



On Fri, Oct 31, 2008 at 11:24 AM, Edward Peschko <[EMAIL PROTECTED]> wrote:
> Richard,
>
> Thanks for the info... I'll try it out - I'm assuming that what you
> get out of this is very similar to what you get out of dtrace when you
> instrument a pid on entry and return.. Having a full trace is very
> helpful in tracking things down.
>
> I'd like to go further in c code even than what I have right now,
> something I really can't do without a 'true' solution..
>
>  In perl, I've implemented reverse watch points - such that you give
> the environment a certain data sequence/ascii string, and it monitors
> all assignments and prints out the point in the code where they were
> done, the variable that was set, and the values it was set to.
>
> It does this by parsing the code for assignments, and then comparing
> the variable to the  value(s) given by the user.
>
> I suppose I could do the same thing with my hack that does tracing, by
> realizing that an assignment is occuring, keeping track of the
> variable types of the code that I'm instrumenting, and defining a
> different macro for each type of assignment, but I'm coming awful
> close to writing a parser for c/c++ at that point and I don't think
> the structure I've built would support it..
>
> Which is too bad, because that is doubly helpful (above and beyond a
> simple trace) for programs that you do not know.
>
> You see the behavior of the program in the form of strings being
> output, but don't know the structure, etc. so you poke and prod it by
> setting the reverse watchpoint to a string you know is going to be
> output, run it, get the variable name you should be looking at, and
> trace the stack back to the point where you are interested...
>
> How easy this would be to do even with the support of gcc/g++ is
> questionable, but it would be a killer function for debugging
> programs. With reverse tracepoints, I can typically get to perl
> problems 10 times faster than I can without them, especially with more
> complicated structures with huge object hierarchies..
>
> Ed
>
>
>
> On Fri, Oct 31, 2008 at 3:57 AM, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
>> On Fri, Oct 31, 2008 at 10:18 AM, wuxi <[EMAIL PROTECTED]> wrote:
>>> [EMAIL PROTECTED] wrote:
>>>>
>>>> have a look at the flag -finstrument-functions for gcc.
>>>
>>> as far as I know, this could only record at function entry and return ?
>>>
>>> but sometimes recording all the "trace" of how program behaves is useful for
>>> debugging purpose.
>>>
>>> further, using a binary instrumentation tool like PIN could only record the
>>> low level instruction trace
>>
>> I would suggest to do the instrumentation in the frontends as there
>> you still know
>> the original statement boundaries.  Note that the original program text may 
>> be
>> not readily available there, so you might need to hack libcpp as well.
>>
>> Richard.
>>
>

Re: 'recording' program execution.

[Edward Peschko]

Richard,

Thanks for the info... I'll try it out - I'm assuming that what you
get out of this is very similar to what you get out of dtrace when you
instrument a pid on entry and return.. Having a full trace is very
helpful in tracking things down.

I'd like to go further in c code even than what I have right now,
something I really can't do without a 'true' solution..

 In perl, I've implemented reverse watch points - such that you give
the environment a certain data sequence/ascii string, and it monitors
all assignments and prints out the point in the code where they were
done, the variable that was set, and the values it was set to.

It does this by parsing the code for assignments, and then comparing
the variable to the  value(s) given by the user.

I suppose I could do the same thing with my hack that does tracing, by
realizing that an assignment is occuring, keeping track of the
variable types of the code that I'm instrumenting, and defining a
different macro for each type of assignment, but I'm coming awful
close to writing a parser for c/c++ at that point and I don't think
the structure I've built would support it..

Which is too bad, because that is doubly helpful (above and beyond a
simple trace) for programs that you do not know.

You see the behavior of the program in the form of strings being
output, but don't know the structure, etc. so you poke and prod it by
setting the reverse watchpoint to a string you know is going to be
output, run it, get the variable name you should be looking at, and
trace the stack back to the point where you are interested...

How easy this would be to do even with the support of gcc/g++ is
questionable, but it would be a killer function for debugging
programs. With reverse tracepoints, I can typically get to perl
problems 10 times faster than I can without them, especially with more
complicated structures with huge object hierarchies..

Ed



On Fri, Oct 31, 2008 at 3:57 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Fri, Oct 31, 2008 at 10:18 AM, wuxi <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>>
>>> have a look at the flag -finstrument-functions for gcc.
>>
>> as far as I know, this could only record at function entry and return ?
>>
>> but sometimes recording all the "trace" of how program behaves is useful for
>> debugging purpose.
>>
>> further, using a binary instrumentation tool like PIN could only record the
>> low level instruction trace
>
> I would suggest to do the instrumentation in the frontends as there
> you still know
> the original statement boundaries.  Note that the original program text may be
> not readily available there, so you might need to hack libcpp as well.
>
> Richard.
>

'recording' program execution.

[Edward Peschko]

All,

dbx has a feature called 'trace' where it outputs your program
execution, a line at a time, and I've found it very useful for
debugging/figuring out programs (you run it once, make a change, run
it again, and do a diff to see exactly how your change affects the
programming run).

However, it is exceedingly slow - as is the analogue in gdb - so I've
written a very ugly hack in perl that basically does the same thing by
instrumenting the source code with macros to print out each step. So:

int main()
{
fprintf(stderr, "HERE");
}

becomes:

int main()
__pl1({)
__pf1(fprintf(stderr, "HERE"););
__pf1(})

where each macro calls a hook to print out the text inside of it,
after mirroring it for the compiler, (ie: the above expands to:):

int main()
{
   fprintf(log, "{\n");
   fprintf(stderr, "HERE");
   fprintf(log, "fprintf(stderr, \"HERE\");\n");
   fprintf(log, "}\n");
}


This works - it is incredibly fast, and you can basically debug any
size application this way - but it is horrendously ugly, doesn't work
seamlessly and requires a lot of elbow grease (macros in particular
are a real pain).

What I'd prefer is a compiler flag that does basically the same thing,
ie: puts hooks in the code such that after each step, a special, user
defined function is called which takes as an argument the relevant
source code that is to be executed (and whether or not a subroutine is
being exited or entered), and lets the user do whatever they want with
it.

Would this be possible to do with changes to gcc? If so, what would be
involved? I'm assuming the file and line information are already
stored inside the executable when '-g' is run, how easy would it be to
make gcc create an  executable that runs a user specified function on
each step given this input?

Thanks,

Ed

Re: thread build on solaris

[Edward Peschko]

thanks.. mea culpa, I assumed that 'testing fixes' solely meant making
the fixincludes ready for release..

Ed

On Tue, Oct 21, 2008 at 9:49 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>> Yes, I got that from the README. What I was looking for was a
>> *shortcut*,
>
> "5. Testing fixes" precisely documents a shortcut.
>
> --
> Eric Botcazou
>

Re: thread build on solaris

[Edward Peschko]

Eric,

Yes, I got that from the README. What I was looking for was a
*shortcut*, ie: I compile ~1000 packages, so when one doesn't work, I
trace down the reason, compose a entry in the 'live' fixincludes.def,
and after I'm done with the 1000-or-so packages take all the bugs in
one step back to the build directory and release them formally.

This would save lots of time - as it stands, the time to iterate
through these issues is going to be very expensive.

Ed

On Tue, Oct 21, 2008 at 12:13 PM, Eric Botcazou
<[EMAIL PROTECTED]> wrote:
>> Is there any way to do this work with an already installed compiler,
>> ie: change the fixincludes.def on the fly and have the installed
>> compiler immediately pick up on the changes from the text file?
>
> You need to work in a build tree, modify fixincludes.def and follow the
> instructions given in section 5. Testing fixes (which may or may not work
> with the new toplevel bootstrap).  Then do 'make install' in the dir.
>
> --
> Eric Botcazou
>

Re: thread build on solaris

[Edward Peschko]

Eric,

I'm looking at it, and that's one hell of an amount of work to do for
the code that I would maintain. As far as I can see, it requires me to
recompile/reinstall the compiler for every issue that I find..
Suppose I find fifty such issues?

Is there any way to do this work with an already installed compiler,
ie: change the fixincludes.def on the fly and have the installed
compiler immediately pick up on the changes from the text file? That
would save tons of time..

Ed



On Tue, Oct 21, 2008 at 7:48 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>> I'm not sure what you are trying to say here - that it should be fixed
>> locally on my side at the level of the header file? Or something else?
>
> That it should be fix-included, see fixincludes/README in the source tree.
>
> --
> Eric Botcazou
>

Re: thread build on solaris

[Edward Peschko]

Eric,

I'm not sure what you are trying to say here - that it should be fixed
locally on my side at the level of the header file? Or something else?
Fixing locally really isn't feasible as I'm working with a large
amount of code (a whole code distribution, in fact) and who knows how
many anachronisms are in the solaris headers.

Ed

On Sun, Oct 19, 2008 at 1:16 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>> This is having the unfortunate side effect that a lot of packages that
>> used to compile perfectly fine with gcc-3 are no longer doing so with
>> gcc-4.
>
> The major Linux distributions use GCC 4.x so this should be doable.
>
>> Here's another example I'm finding:
>>
>> Constructs of the form
>>
>> extern enum vtype iftovt_tab[];
>>
>> are now failing with forgiving
>>
>> error: array type has incomplete element type
>>
>> This would be fine if it was code that I controlled - but the matter
>> of fact is that this code is in /usr/include/sys/mode.h, which comes
>> bundled with solaris 10, and the upshot is that I'm going to have to
>> somehow hack solaris headers in order to make gcc-4.3.2 be able to
>> compile perl-5.10.0.
>
> This should be fix-included if it's really a bug in the Solaris headers.
>
> --
> Eric Botcazou
>

Re: thread build on solaris

[Edward Peschko]

Eric,

I don't want to be a hair-splitter, but I do think this message does
belong in gcc - it's a question of functionality, and how easy to use
gcc is.

I am trying to move to gcc-4 for its technical improvements, but I'm
finding that it seems to be far less forgiving than gcc-3.

This is having the unfortunate side effect that a lot of packages that
used to compile perfectly fine with gcc-3 are no longer doing so with
gcc-4.

IMO it should be flexible enough to 'do the right thing' when it can.
>From the point of the user, it makes it far more user friendly than
otherwise. Is there a flag,  environmental variable, or some switch
that I can use to make gcc-4 have the older, looser behaviour? (ie: to
be backwards compatible with the large volume of code I compile and
maintain).

Here's another example I'm finding:

Constructs of the form

extern enum vtype iftovt_tab[];

are now failing with forgiving

error: array type has incomplete element type

This would be fine if it was code that I controlled - but the matter
of fact is that this code is in /usr/include/sys/mode.h, which comes
bundled with solaris 10, and the upshot is that I'm going to have to
somehow hack solaris headers in order to make gcc-4.3.2 be able to
compile perl-5.10.0.

Which is just plain wrong.

Ed

On Sun, Oct 19, 2008 at 2:06 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> [This is not appropriate for gcc@, please use [EMAIL PROTECTED]
>
>> That worked (thanks) but exactly why did it work? Shouldn't gcc be
>> smart enough to realize that it is working either with a c++ file or
>> linking to a c++ library?
>
> gcc is the C compiler, use g++ when you're compiling C++, gfortran when you're
> compiling Fortran and so on.
>
> --
> Eric Botcazou
>

Re: thread build on solaris

[Edward Peschko]

H.J -

hmm.

That worked (thanks) but exactly why did it work? Shouldn't gcc be
smart enough to realize that it is working either with a c++ file or
linking to a c++ library?

Ed

It's part of a configure test as part of

On Fri, Oct 17, 2008 at 9:24 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2008 at 11:13 AM, Edward Peschko <[EMAIL PROTECTED]> wrote:
>> All,
>>
>> I'm trying to compile a thread with the boost, threading libraries,
>> and am getting errors like these.
>>
>>gcc -o conftest -g -O2
>> -I/GAAL/pesced_release/install/fuego/include/boost-1_36
>> -L/GAAL/pesced_release/install/fuego/lib /tmp/aa.c
>> -lboost_thread-gcc43-mt
>>
>> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
>> undefined reference to [EMAIL PROTECTED]'
>> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
>> undefined reference to `std::basic_string> std::char_traits, std::allocator
>>>::_Rep::_M_destroy(std::allocator const&)@GLIBCXX_3.4'
>> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
>> undefined reference to `std::bad_alloc::~bad_alloc()@GLIBCXX_3.4'
>> /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
>> undefined reference to [EMAIL PROTECTED]'
>>
>> This is on solaris 2.10, using gnu ld (version 2.18..)
>>
>> Any ideas on how to get around this?
>>
>
> Please use g++ instead of gcc.
>
>
> --
> H.J.
>

thread build on solaris

[Edward Peschko]

All,

I'm trying to compile a thread with the boost, threading libraries,
and am getting errors like these.

gcc -o conftest -g -O2
-I/GAAL/pesced_release/install/fuego/include/boost-1_36
-L/GAAL/pesced_release/install/fuego/lib /tmp/aa.c
-lboost_thread-gcc43-mt

/GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
undefined reference to [EMAIL PROTECTED]'
/GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
undefined reference to `std::basic_string, std::allocator
>::_Rep::_M_destroy(std::allocator const&)@GLIBCXX_3.4'
/GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
undefined reference to `std::bad_alloc::~bad_alloc()@GLIBCXX_3.4'
/GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so:
undefined reference to [EMAIL PROTECTED]'

This is on solaris 2.10, using gnu ld (version 2.18..)

Any ideas on how to get around this?

Ed