public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Critical behavioral change between g++-4.4/g++-4.5 and g++-4.6 ?
@ 2011-08-21  9:52 Emmanuel Fleury
  2011-08-21 10:49 ` Marc Glisse
  0 siblings, 1 reply; 3+ messages in thread
From: Emmanuel Fleury @ 2011-08-21  9:52 UTC (permalink / raw)
  To: gcc

Hi,

I was trying to compile a project called kyua with g++-4.6 and I did hit 
a linking error. It seems that a method was missing.

After some discussions with the main developer of the project, it 
appeared that depending on the version of g++ we were using the build 
was going nicely (g++-4.4/g++-4.5) or was hitting a linking error (g++-4.6).

Here is the error:

g++ -I/usr/include/lua5.1   -I/usr/include/lua5.1 
-I/usr/include/lua5.1   -I/usr/include/lua5.1   -I/usr/include/lua5.1 
-I/usr/local/include   -g -O2  -D_FORTIFY_SOURCE=2 -Wall -Wcast-qual 
-Wextra -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow 
-Wsign-compare -Wswitch -Wwrite-strings -DNDEBUG -Wabi 
-Wctor-dtor-privacy -Wno-deprecated -Wno-non-template-friend 
-Wno-pmf-conversions -Wnon-virtual-dtor -Woverloaded-virtual -Wreorder 
-Wsign-promo -Wsynth   -o cli/cmd_about_test 
cli/cli_cmd_about_test-cmd_about_test.o libcli.a libengine.a libutils.a 
-llua5.1   libutils.a -llua5.1   libengine.a libutils.a -llua5.1 
libutils_test.a libutils.a -llua5.1   libutils.a -llua5.1 
-L/usr/local/lib -latf-c++ -latf-c
cli/cmd_about_test.cpp:106: error: undefined reference to 
'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
std::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
engine::user_files::config const&)'
cli/cmd_about_test.cpp:106: error: undefined reference to 
'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
std::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
engine::user_files::config const&)'
cli/cmd_about_test.cpp:87: error: undefined reference to 
'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
std::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
engine::user_files::config const&)'
cli/cmd_about_test.cpp:87: error: undefined reference to 
'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
std::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
engine::user_files::config const&)'
collect2: ld returned 1 exit status


And, indeed, when getting the symbols from the static libraries built 
with g++-4.4 (I had it on my system, but I can install g++-4.5 if 
needed) and g++-4.6, I got the following output (you will see that the 
method requested by the linker is missing in libcli.a):

===========
= g++-4.4 =
===========

$myshell> for lib in *.a; do echo; echo "Scanning lib ${lib}: "; echo 
"======================="; nm ${lib} | grep main; done

Scanning lib libcli.a:
=======================
libcli_a-main.o:
000003a0 t 
_ZN12_GLOBAL__N_1L9safe_mainEPN5utils7cmdline2uiEiPKPKcSt8auto_ptrINS1_12base_commandIN6engine10user_files6configEEEE
00001510 T 
_ZN3cli4mainEPN5utils7cmdline2uiEiPKPKcSt8auto_ptrINS1_12base_commandIN6engine10user_files6configEEEE
00001b00 T _ZN3cli4mainEiPKPKc
00000000 W 
_ZN5utils7cmdline12base_commandIN6engine10user_files6configEE4mainEPNS0_2uiERKSt6vectorISsSaISsEERKS4_

Scanning lib libengine.a:
=======================

Scanning lib libutils.a:
=======================
000008a0 T 
_ZN5utils7cmdline20base_command_no_data4mainEPNS0_2uiERKSt6vectorISsSaISsEE

Scanning lib libutils_test.a:
=======================

===========
= g++-4.6 =
===========

$myshell> for lib in *.a; do echo; echo "Scanning lib ${lib}: "; echo 
"======================="; nm ${lib} | grep main; done

Scanning lib libcli.a:
=======================
libcli_a-main.o:
00000000 T 
_ZN3cli4mainEPN5utils7cmdline2uiEiPKPKcSt8auto_ptrINS1_12base_commandIN6engine10user_files6configEEEE
00001180 T _ZN3cli4mainEiPKPKc

Scanning lib libengine.a:
=======================

Scanning lib libutils.a:
=======================
00000000 T 
_ZN5utils7cmdline20base_command_no_data4mainEPNS0_2uiERKSt6vectorISsSaISsEE

Scanning lib libutils_test.a:
=======================




So, now, I am looking for help to know if the problem is coming from the 
code or from g++-4.6.

Does this problem ring a bell to anyone ?


If you want to get the code that produce this problem (sorry I didn't 
manage to circumvent the problem to a small piece of code), here are the 
instructions (which are quite long I'm afraid).

1) Install atf (make, make install):
http://www.netbsd.org/~jmmv/atf/releases/0.14/

2) Get the source code of kyua:
svn co http://kyua.googlecode.com/svn/trunk/kyua-cli

3) cd kyua-cli

4) autoreconf -i -s -I /usr/local/share/aclocal

5) ./configure && make


Thanks in advance !

Regards
-- 
Emmanuel Fleury

The most important thing in the programming language is the name.
A language will not succeed without a good name. I have recently
invented a very good name and now I am looking for a suitable language.
   -- Donald Knuth

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Critical behavioral change between g++-4.4/g++-4.5 and g++-4.6 ?
  2011-08-21  9:52 Critical behavioral change between g++-4.4/g++-4.5 and g++-4.6 ? Emmanuel Fleury
@ 2011-08-21 10:49 ` Marc Glisse
  2011-08-21 12:09   ` Emmanuel Fleury
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Glisse @ 2011-08-21 10:49 UTC (permalink / raw)
  To: Emmanuel Fleury; +Cc: gcc

Wrong mailing list, you are looking for gcc-help.

On Sun, 21 Aug 2011, Emmanuel Fleury wrote:

> I was trying to compile a project called kyua with g++-4.6 and I did hit a 
> linking error. It seems that a method was missing.
>
> After some discussions with the main developer of the project, it appeared 
> that depending on the version of g++ we were using the build was going nicely 
> (g++-4.4/g++-4.5) or was hitting a linking error (g++-4.6).
>
> Here is the error:
>
> cli/cmd_about_test.cpp:106: error: undefined reference to 
> 'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
> std::vector<std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::allocator<std::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > > > const&, 
> engine::user_files::config const&)'
> cli/cmd_about_test.cpp:106: error: undefined reference to 
> 'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
> std::vector<std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::allocator<std::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > > > const&, 
> engine::user_files::config const&)'
> cli/cmd_about_test.cpp:87: error: undefined reference to 
> 'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
> std::vector<std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::allocator<std::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > > > const&, 
> engine::user_files::config const&)'
> cli/cmd_about_test.cpp:87: error: undefined reference to 
> 'utils::cmdline::base_command<engine::user_files::config>::main(utils::cmdline::ui*, 
> std::vector<std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >, std::allocator<std::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > > > const&, 
> engine::user_files::config const&)'
> collect2: ld returned 1 exit status
>
> And, indeed, when getting the symbols from the static libraries built with 
> g++-4.4 (I had it on my system, but I can install g++-4.5 if needed) and 
> g++-4.6, I got the following output (you will see that the method requested 
> by the linker is missing in libcli.a):
[...]
> So, now, I am looking for help to know if the problem is coming from the code 
> or from g++-4.6.

From the code. The definition (not just declaration) of templates should 
be available everywhere they are used (or you can manually force 
instantiation in one translation unit and inhibit it in the others).

> (sorry I didn't manage to circumvent the problem to a small piece of 
> code),

Er, what did you try?

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Critical behavioral change between g++-4.4/g++-4.5 and g++-4.6 ?
  2011-08-21 10:49 ` Marc Glisse
@ 2011-08-21 12:09   ` Emmanuel Fleury
  0 siblings, 0 replies; 3+ messages in thread
From: Emmanuel Fleury @ 2011-08-21 12:09 UTC (permalink / raw)
  To: gcc-help; +Cc: gcc

Hi,

On 08/21/2011 12:48 PM, Marc Glisse wrote:
> Wrong mailing list, you are looking for gcc-help.

Ok, sorry for that.

But, I looked thoroughly to the kyua code and I didn't see anything 
wrong (even if I might have missed something, I admit it. I'm not a C++ 
god).

In fact, after a quick look at the g++-4.6 changelog, I found the 
following item:

« * When an extern declaration within a function does not match a 
declaration in the enclosing context, G++ now properly declares the name 
within the namespace of the function rather than the namespace which was 
open just before the function definition (c++/43145). »

See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43145

My work hypothesis for now is that the fix of this issue has changed 
something in the way namespaces are handled

I think this issue is related to this change and that a bug has been 
introduced in the compiler when c++/43145 has been fixed.

But, this is only an hypothesis.

>  From the code. The definition (not just declaration) of templates
> should be available everywhere they are used (or you can manually force
> instantiation in one translation unit and inhibit it in the others).

And, could you spot the change that occurred in g++ between g++-4.5 and 
g++-4.6 that changed its behavior ?

Why was it possible before and not anymore now ?

>> (sorry I didn't manage to circumvent the problem to a small piece of
>> code),
>
> Er, what did you try?

I am currently trying to do so and I didn't succeed to better understand 
the problem by now.

My guess is that it is related to the namespace handling and I am 
working in this direction. But, I have no more to say (except my 
intuition that it might be related) and the code of kyua is new to me, 
so it does take some time.

Regards
-- 
Emmanuel Fleury

If you can not measure it, you can not improve it.
   -- Lord Kelvin

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-08-21 12:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-21  9:52 Critical behavioral change between g++-4.4/g++-4.5 and g++-4.6 ? Emmanuel Fleury
2011-08-21 10:49 ` Marc Glisse
2011-08-21 12:09   ` Emmanuel Fleury

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).