Is this with the alternative code in visit_each_type()?

Yes.

How about libsigc++ 2.10.11? Is this only a problem with this new version (5.7)
of the compiler?

Could you also please show the error without the alternative code?

Oops, disregard comment #2. The original error is without using the alternative
code in visit_each_type(). With the alternative code, I get the following error:
CC  -I. -I. -I.. -I.. -I..    -xO2 -xtarget=generic -xarch=v8 -c -o
test_trackable.o test_trackable.cc
"../sigc++/visit_each.h", line 72: Error: Ambiguous partial specialization for
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>::with_type<0,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>,
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>::with_type and
sigc::internal::limit_derived_target<sigc::internal::T_target,
sigc::internal::T_action>::with_type.
"../sigc++/visit_each.h", line 130:     Where: While instantiating
"sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&)".
"../sigc++/visit_each.h", line 130:     Where: Instantiated from
sigc::visit_each_type<sigc::trackable*, sigc::internal::slot_do_unbind,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>(const
sigc::internal::slot_do_unbind&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&).
"../sigc++/functors/slot.h", line 60:     Where: Instantiated from non-template
code.
"../sigc++/visit_each.h", line 72: Error: execute_ is not a member of
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>::with_type<0,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>.
"../sigc++/visit_each.h", line 130:     Where: While instantiating
"sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&)".
"../sigc++/visit_each.h", line 130:     Where: Instantiated from
sigc::visit_each_type<sigc::trackable*, sigc::internal::slot_do_unbind,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>(const
sigc::internal::slot_do_unbind&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&).
"../sigc++/functors/slot.h", line 60:     Where: Instantiated from non-template
code.
2 Error(s) detected.
gmake[2]: *** [test_trackable.o] Error 2

I haven't got past this yet. For reference, the latest version of the error,
with updated line numbers from cvs is:

CC  -I. -I. -I.. -I.. -I..    -g -c -o test_trackable.o test_trackable.cc
"../sigc++/visit_each.h", line 93: Error: Ambiguous partial specialization for
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>::with_type<1, sigc::trackable>,
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>::with_type and
sigc::internal::limit_derived_target<sigc::internal::T_target,
sigc::internal::T_action>::with_type.
"../sigc++/limit_reference.h", line 121:     Where: While instantiating
"sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>, sigc::trackable>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const sigc::trackable&)".
"../sigc++/limit_reference.h", line 121:     Where: Instantiated from
sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>, my_class, 1>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const sigc::limit_reference<my_class, 1>&).
"../sigc++/functors/mem_fun.h", line 1806:     Where: Instantiated from
sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>, void, my_class>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const sigc::bound_mem_functor0<void, my_class>&).
"../sigc++/adaptors/adaptor_trait.h", line 267:     Where: Instantiated from
sigc::visit_each<sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>, sigc::bound_mem_functor0<void, my_class>>(const
sigc::internal::limit_derived_target<sigc::trackable*,
sigc::internal::slot_do_unbind>&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&).
"../sigc++/visit_each.h", line 163:     Where: Instantiated from
sigc::visit_each_type<sigc::trackable*, sigc::internal::slot_do_unbind,
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>>(const
sigc::internal::slot_do_unbind&, const
sigc::adaptor_functor<sigc::bound_mem_functor0<void, my_class>>&).
"../sigc++/functors/slot.h", line 60:     Where: Instantiated from non-template
code.

Is it possible to create a small test case that reproduces the error that can be
submitted to Sun?

Probably, if I don't make progress on it. It could take a while though. I'm
doing some other easier stuff in the meantime.

Note that 2.0.9 has the same problem. No previous libsigc++ version is likely to
work either.

Created attachment 47546 [details]
ambiguous_specialization_of_inner_class.cc

Here is a test case, though it's still relatively large. It looks like one or
maybe two compiler bugs. But I should be able to work around it. This test case
gives this error:

bash-2.05b$ CC test.cc
"test.cc", line 25: Error: Ambiguous partial specialization for
limit_derived_target<someclass2>::with_type<int, 1>,
limit_derived_target<someclass2>::with_type and
limit_derived_target<T_action>::with_type.
"test.cc", line 41:	Where: While instantiating
"limit_derived_target<someclass2>::some_method() const".
"test.cc", line 41:	Where: Instantiated from
visit_each<limit_derived_target<someclass2>, functor_base>(const
limit_derived_target<someclass2>&, const functor_base&).
"test.cc", line 54:	Where: Instantiated from
visit_each_type<someclass2>(const someclass2&).
"test.cc", line 109:	 Where: Instantiated from non-template code.
1 Error(s) detected.

Are you sure about this comment:
    //SUN CC 5.7 says that this is an ambiguous partial specialization:
    typedef with_type<int, true> type_problem;

    //If I do this, to specify with_type as an inner class, SUN CC 5.5 says
    //"expected init-declarator before "type_problem"
    //typedef type_self::with_type<int, true> type_problem;

I commented the first typedef and uncommented the second. Sun CC 5.5 didn't
complain. Sun CC 5.7 complains with both typedefs.

Sorry, I meant 5.7.

That's fixed with this commit: 

2005-06-10  Murray Cumming  <murrayc@murrayc.com>

	* sigc++/visit_each.h: Make the 
        limit_derived_target::with_type inner class an outer class, 
	to satisfy the SUN CC 5.7 compiler, though I think it is a 
	compiler bug. Bug #302098 has the test case.

The next error is:

CC  -I. -I. -I.. -I.. -I..    -g -c -o test_signal.o test_signal.cc
"../sigc++/signal.h", line 1784: Error: Redefining sigc::slot_list<sigc::T_slot>
after use in sigc::signal1<int, int, sigc::nil>.
"../sigc++/signal.h", line 2701:     Where: While specializing
"sigc::signal1<int, int, sigc::nil>".
"../sigc++/signal.h", line 2701:     Where: Specialized in sigc::signal<int,
int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.
"test_signal.cc", line 29:     Where: Specialized in non-template code.
"../sigc++/signal.h", line 1772: Error: Too many arguments for template
sigc::slot<int, int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil,
sigc::nil>.
"../sigc++/signal.h", line 2711:     Where: While specializing
"sigc::signal1<int, int, sigc::signal<int, int, sigc::nil, sigc::nil, sigc::nil,
sigc::nil, sigc::nil, sigc::nil>::T_accumulator>".
"../sigc++/signal.h", line 2711:     Where: Specialized in sigc::signal<int,
int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.

Created attachment 47552 [details] [review]
sigc_sun57.patch

This patch (sigc_sun57.patch) fixes/works-around those last 2 issues, but I'm
not ready to commit it cvs yet.

2005-06-10  Murray Cumming  <murrayc@murrayc.com>

	* sigc++/macros/signal.h.m4: Comment out 
	SIGC_TYPEDEF_REDEFINE_ALLOWED because the correlation between 
	that compiler characteristic and the other one no longer 
	exists in SUN CC 5.7, and I can not yet find a simple test for 
	SIGC_TYPEDEF_REDEFINE_ALLOWED. This change should not be 
	committed.
	class signalN: Use slotN instead of slot<> because SUN CC 5.7 
	complains, bizarrely, that we are providing too many template 
	parameters. I need to investigate whether this changes binary 
	ABI before committing.

I've file case #64618843 for comment #10. We should get confirmation soon if
it's a compiler bug. I'd rather not have you implement a workaround if it's a
compiler bug. Sun should fix the problem.

Can you create a small test case for comment #13?

Note that glibmm needs a similar fix (slotN instead of slot), seen when building
gtkmm.

Received initial feedback from Sun:
  I am also getting errors when I use the latest publicly available patch
but I also have a binary fix for another issue which appears to also fix this
issue. I will attempt to track down which bug it is and update you on monday
but I suspect that the next patch will fix this issue.

Created attachment 47576 [details]
too_many_arguments.cc

This patch (too_many_arguments.cc) shows the slotN/slot problem. It seems to be
triggered by the use of a template specialization (as a base type of an inner
class) from a template specialization. It's probably simpler than that, but I
haven't figured out how so far.

I've filed case #64619743 on comment #17.

Latest news from Sun is that the next C++ patch, available 2nd or 3rd week of
August, should fix both of these issues.

The test case in comment #10 is fixed by the latest Sun 117830-03 test patch.
The test case in comment #17 is not fixed by this test patch.

Sun has released the 117830-03 patch. I've confirmed both test cases above are
fixed. However, I'm now getting the following error:
CC  -I. -I. -I.. -I.. -I..    -xO2 -xtarget=generic -xarch=v8 -c -o
test_signal.o test_signal.cc
"../sigc++/signal.h", line 1784: Error: Redefining sigc::slot_list<sigc::T_slot>
after use in sigc::signal1<int, int, sigc::nil>.
"../sigc++/signal.h", line 2701:     Where: While specializing
"sigc::signal1<int, int, sigc::nil>".
"../sigc++/signal.h", line 2701:     Where: Specialized in sigc::signal<int,
int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.
"test_signal.cc", line 29:     Where: Specialized in non-template code.
"../sigc++/signal.h", line 1784: Error: Redefining sigc::slot_list<sigc::T_slot>
after use in sigc::signal1<void, std::string &, sigc::nil>.
"../sigc++/signal.h", line 2701:     Where: While specializing
"sigc::signal1<void, std::string &, sigc::nil>".
"../sigc++/signal.h", line 2701:     Where: Specialized in sigc::signal<void,
std::string &, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.
"test_signal.cc", line 49:     Where: Specialized in non-template code.
2 Error(s) detected.
gmake[2]: *** [test_signal.o] Error 2
gmake[2]: Leaving directory `/opt/build/libsigc++-2.0.15/tests'

I'm building the same as I do with the Sun C v5.5 compiler.

Ok, from comment #13, this patch resolves the issue:
2005-06-10  Murray Cumming  <murrayc@murrayc.com>

	* sigc++/macros/signal.h.m4: Comment out 
	SIGC_TYPEDEF_REDEFINE_ALLOWED because the correlation between 
	that compiler characteristic and the other one no longer 
	exists in SUN CC 5.7, and I can not yet find a simple test for 
	SIGC_TYPEDEF_REDEFINE_ALLOWED. This change should not be 
	committed.

Looks like the compiler is wrong. We'll need to come up with a test case to send
to Sun to get the bug fixed though.

For now, I'm just going to remove use of SIGC_TYPEDEF_REDEFINE_ALLOWED. Because
slot_list_type is marked as @deprecated, I'll just hope noone is using it :)

According to Laszlo Peter, the new Sun Studio 11 doesn't need this patch, and
builds gtkmm too without changes.

Albert's comment #21 still applies, though.  I'm building 2.0.17 with Sun Workshop 11 and the latest patch to the C++ compiler, and I get the exact same error building test_signal.cc that Albert mentions in comment #21.

Any suggestions for what to do about the problem Albert mentioned in comment #21?  I'm using the Sun C++ compiler that's part of the Workshop 11 bundle with the latest patches applied:

  CC: Sun C++ 5.8 Patch 121018-07 2006/11/01

If I just remove test_signal from the noinst_PROGRAMS in the tests directory and continue with the "make check", there are very similar compile errors for

  test_disconnect
  test_compatibility

and slightly different errors (though still similar) for

  test_disconnect_during_emit
  test_size

Here's the example for test_size.cc:

CC  -I. -I. -I.. -I.. -I..    -xO3 -xtarget=native -xarch=amd64 -c -o test_size.o test_size.cc
"../sigc++/signal.h", line 1675: Error: Redefining sigc::slot_list<sigc::T_slot> after use in sigc::signal0<void, sigc::nil>.
"../sigc++/signal.h", line 2670:     Where: While specializing "sigc::signal0<void, sigc::nil>".
"../sigc++/signal.h", line 2670:     Where: Specialized in sigc::signal<void, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.
"test_size.cc", line 23:     Where: Specialized in non-template code.
1 Error(s) detected.
gmake: *** [test_size.o] Error 1


The remaining 18 tests pass, BTW.

> ../sigc++/signal.h", line 1784: Error: Redefining sigc::slot_list<sigc::T_slot>
> after use in sigc::signal1<int, int, sigc::nil>.

Is this line:

#ifdef SIGC_TYPEDEF_REDEFINE_ALLOWED
  /** This typedef is only for backwards-compatibility.
   * It is not available when using the SUN Forte compiler.
   * @deprecated slot_list_type;
   */
  typedef slot_list_type slot_list;
#endif

So you could try comment-ing that out.

I'd like to know whether SIGC_TYPEDEF_REDEFINE_ALLOWED is defined for you. Maybe the configure test has started giving different results.

> "../sigc++/signal.h", line 2701:     Where: While specializing
> "sigc::signal1<int, int, sigc::nil>".
> "../sigc++/signal.h", line 2701:     Where: Specialized in sigc::signal<int,
> int, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>.
> "test_signal.cc", line 29:     Where: Specialized in non-template code.

is this line:
  sigc::signal<int,int> sig;
Which shouldn't be anything complicated.

Sorry for the delay in responding.

SIGC_TYPEDEF_REDEFINE_ALLOWED is not defined in sigc++config.h (it's commented out), but sigc++/signal.h defines it if SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD is defined (which is defined
in sigc++config.h).  sigc++/signal.h even has a comment that says the define should be commented out for Workshop 10 (and it looks like Workshop 11, too).

If I comment out that one line in sigc++/signal.h and do a make clean followed by make check, everything builds and all tests pass.

Looking at configure.ac and config.status, SIGC_TYPEDEF_REDEFINE_ALLOWED is not being substituted into any files, so if there's a configure test that should be setting it, it might not be getting called.

If you can devise a configure test for it I'll be happy to test your test.  If it's hard to create one, the easy hack would be to wrap the section of sigc++/signal.h that is forcing SIGC_TYPEDEF_REDEFINE_ALLOWED to 1, so that it's not seen with recent versions of the Workshop cpp.  I can submit a patch for that, if you like.

> SIGC_TYPEDEF_REDEFINE_ALLOWED is not defined in sigc++config.h (it's commented
out)

It's normal for these macros to be commented out when they should not be set. Note that sigc++config.h is generated from sigc++config.h.in. But yet, this macro is never set, because no test is run from configure.in to set it.


> If you can devise a configure test for it I'll be happy to test your test.  If
> it's hard to create one, the easy hack would be to wrap the section of
> sigc++/signal.h that is forcing SIGC_TYPEDEF_REDEFINE_ALLOWED to 1, so that
> it's not seen with recent versions of the Workshop cpp.  I can submit a patch
> for that, if you like.

The comment in signal.h suggests that I couldn't do that last time I tried:

#ifdef SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD
  //Compilers, such as older versions of SUN Forte C++, that do not allow this also often
  //do not allow a typedef to have the same name as a class in the typedef's definition.
  //For Sun Forte CC 5.7 (SUN Workshop 10), comment this out to fix the build.
  #define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
#endif

I'd appreciate it if you tried again. Failing that, any patch would be useful.

_If_ we assume that everybody has at least version 10 of SUN Workshop, maybe we could just comment it out, to make it work for everybody.

(In reply to comment #29)
> > If you can devise a configure test for it I'll be happy to test your test.  If
> > it's hard to create one, the easy hack would be to wrap the section of
> > sigc++/signal.h that is forcing SIGC_TYPEDEF_REDEFINE_ALLOWED to 1, so that
> > it's not seen with recent versions of the Workshop cpp.  I can submit a patch
> > for that, if you like.
> 
> The comment in signal.h suggests that I couldn't do that last time I tried:
> 
> #ifdef SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD
>   //Compilers, such as older versions of SUN Forte C++, that do not allow this
> also often
>   //do not allow a typedef to have the same name as a class in the typedef's
> definition.
>   //For Sun Forte CC 5.7 (SUN Workshop 10), comment this out to fix the build.
>   #define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
> #endif
> 
> I'd appreciate it if you tried again. Failing that, any patch would be useful.
> 
> _If_ we assume that everybody has at least version 10 of SUN Workshop, maybe we
> could just comment it out, to make it work for everybody.

I think it's safe to assume Studio 10 and above. Studio 10 requires at least Solaris 8 which is a bit old.

Albert, isn't there a chance that this section of code would be used on other platforms too?

I was thinking the easiest thing to do would be to wrap that test like this:

#if defined(__sun) && defined(__SUNPRO_CC)
# if __SUNPRO_CC < 0x570
#  define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
# elif /* Not Solaris or Solaris and not Workshop */
#  define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
# endif
#endif

I'll attach that as a patch.  It seems to solve the problem for me.

Created attachment 83868 [details] [review]
wrap define for SIGC_TYPEDEF_REDEFINE_ALLOWED

wrap SIGC_TYPEDEF_REDEFINE_ALLOWED so that if on Solaris and using the Workshop compiler, SIGC_TYPEDEF_REDEFINE_ALLOWED is only defined if the compiler version is less than 5.7.

(In reply to comment #31)
> Albert, isn't there a chance that this section of code would be used on other
> platforms too?

Dunno. I haven't looked at libsigc++ in awhile.

> I was thinking the easiest thing to do would be to wrap that test like this:
> 
> #if defined(__sun) && defined(__SUNPRO_CC)
> # if __SUNPRO_CC < 0x570
> #  define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
> # elif /* Not Solaris or Solaris and not Workshop */
> #  define SIGC_TYPEDEF_REDEFINE_ALLOWED 1
> # endif
> #endif

I'd much rather see an autoconf test.

However, g++ 4.3 apparently also has a problem at the same place, so I might just remove this deprecated API in libsigc++ 2.2 if we don't manage to improve the configure test.

See http://bugzilla.gnome.org/show_bug.cgi?id=454882 for the g++ 4.3 libsigc++ bug.

I have just released libsigc++ 2.1.1, with the deprecated API removed. I would like you to test it, please. It should appear here soon:
http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.1/

I downloaded it to test, and it doesn't build.  I'm still using Solaris 10 on x86_64 with the Sun Workshop 11 compilers.  The error is

gmake[3]: Entering directory `/local/src/RPM/BUILD/libsigc++-2.1.1/sigc++'
source='signal.cc' object='signal.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CXX   --mode=compile CC -DHAVE_CONFIG_H   -I.. -I..  
 -xO3 -xtarget=native -xarch=amd64 -c -o signal.lo signal.cc
source='signal_base.cc' object='signal_base.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CXX   --mode=compile CC -DHAVE_CONFIG_H   -I.. -I..  
 -xO3 -xtarget=native -xarch=amd64 -c -o signal_base.lo signal_base.cc
mkdir .libs
 CC -DHAVE_CONFIG_H -I.. -I.. -xO3 -xtarget=native -xarch=amd64 -c signal_base.c
c  -KPIC -DPIC -o .libs/signal_base.o
 CC -DHAVE_CONFIG_H -I.. -I.. -xO3 -xtarget=native -xarch=amd64 -c signal.cc  -K
PIC -DPIC -o .libs/signal.o
"../sigc++/signal.h", line 780: Error: Too few arguments for template std::rever
se_iterator.
"/opt/SUNWspro/prod/include/CC/Cstd/rw/iterator", line 432: Error: "friend" decl
aration is incompatible with function template.
"../sigc++/signal.h", line 781:     Where: While specializing "std::reverse_iter
ator<std::list<sigc::slot_base>::iterator>".
"../sigc++/signal.h", line 781:     Where: Specialized in non-template code.
"../sigc++/signal.h", line 781: Error: The operation "std::reverse_iterator<std:
:list<sigc::slot_base>::iterator> != std::reverse_iterator<std::list<sigc::slot_
base>::iterator>" is illegal.
"../sigc++/signal.h", line 783: Error: Pointer type needed instead of std::Point
er.
"../sigc++/signal.h", line 783: Error: Pointer type needed instead of std::Point
er.
"../sigc++/signal.h", line 785: Error: Pointer type needed instead of std::Point
er.
"../sigc++/signal.h", line 785: Error: Pointer type needed instead of std::Point
er.
7 Error(s) detected.


line 780 of signal.h looks like


      typedef std::reverse_iterator<signal_impl::iterator_type> reverse_iterator_type;

Hi,

I tried to compile 2.1.1, and I succeeded using this:

CC=CC CXX=CC LDFLAGS="-library=stlport4" CXXFLAGS="-library=stlport4" ./configure --enable-static --disable-shared

--enable-static --disable-shared
 * not necessary probably, but I use it in my environment

LDFLAGS="-library=stlport4" CXXFLAGS="-library=stlport4"
 * CC by default uses old-weak-but-binary-compatible stl implementation
 * Use -libary=stlport4 for compiling and linking (more in man page)

CC=CC CXX=CC
 * If you compile with c++ compiler, you have to link with c++ compiler. You use by default c compiler for linking. So my hack is to set CC as c compiler.

test_copy_invalid_slot.cc is missing <stdlib.h> and <string.h> include files (I'll file for it new bug shortly)

Manual does build only using gnu make, because of

docs/manual/Makefile:341
...
DOCBOOK_STYLESHEET ?= http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl
...

I'm not filing bug for this, we all use gnu make anyway :)

Thanks

-- 
	Vlad

Thanks Vladimir!  By adding "-library=stlport4" to CXXFLAGS, I was able to get it to build.  I didn't need to set CC=CC, because libtool was already using CC for linking -- maybe that's because I have libtool 1.5.24 installed and I rebuilt configure to use the libtool I have.  I also didn't need to augment LDFLAGS, since CC was used for linking.

The only bad part about using -library=stlport4 is that because libsigc is a library that other programs will link against, I'm guessing that any program that wants to use libsigc will now also need to be compiled with -library=stlport4.

I ran into the same problem with test_copy_invalid_slot.cc.  I see you've opened bug #469872 for this -- Thanks.

Note to self: We need to fix this properly. Using stlport is not a satisfactory build fix.

Hi Tim,

That's a very good observation. This is described in detail at http://docs.sun.com/app/docs/doc/819-5267/6n7c46dss?l=en&a=view&q=stlport

Snip:
      * STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4. This means, for example, that you cannot use the STLport implementation and the C++ interval math library libCsunimath together. The reason for this is that libCsunimath was compiled with the default library headers, not with STLport.

However I'm afraid that the default Cstd might not be able to cope with all the language complexness that C++ program might want to use.

-- 
  Vlad

So, let's try to deal with the first error:
> "../sigc++/signal.h", line 780: Error: Too few arguments for template
std::reverse_iterator.
> "/opt/SUNWspro/prod/include/CC/Cstd/rw/iterator", line 432: Error: "friend"
declaration is incompatible with function template.
> "../sigc++/signal.h", line 781:     Where: While specializing "std::reverse_iterator<std::list<sigc::slot_base>::iterator>".
> "../sigc++/signal.h", line 781:     Where: Specialized in non-template code.
> "../sigc++/signal.h", line 781: Error: The operation "std::reverse_iterator<std::list<sigc::slot_base>::iterator> != 
> std::reverse_iterator<std::list<sigc::slot_base>::iterator>" is illegal.

This is probably affected by the SIGC_HAVE_SUN_REVERSE_ITERATOR define, which is defined by a configure test. With the normal (non StlPort) STL, is this defined in your sigc++config.h?

Maybe CC's reverse_iterator has become more standards-compliant and our test is somehow not correct. This is the test in scripts/cxx_std.m4.

## SIGC_CXX_HAS_SUN_REVERSE_ITERATOR()
##
## Check for Sun libCstd style std::reverse_iterator, which demands more than just one template parameter.
## and #define SIGC_HAVE_SUN_REVERSE_ITERATOR if found.
##
AC_DEFUN([SIGC_CXX_HAS_SUN_REVERSE_ITERATOR],
[
  AC_REQUIRE([SIGC_CXX_HAS_NAMESPACE_STD])

  AC_CACHE_CHECK(
    [for non-standard Sun libCstd reverse_iterator],
    [sigc_cv_cxx_has_sun_reverse_iterator],
  [
    AC_TRY_COMPILE(
    [
      #include <iterator>
      #ifdef SIGC_HAVE_NAMESPACE_STD
      using namespace std;
      #endif
    ],[
      typedef reverse_iterator<char*,random_access_iterator_tag,char,char&,char*,int> ReverseIter;
    ],
      [sigc_cv_cxx_has_sun_reverse_iterator="yes"],
      [sigc_cv_cxx_has_sun_reverse_iterator="no"]
    )
  ])

  if test "x${sigc_cv_cxx_has_sun_reverse_iterator}" = "xyes"; then
  {
    AC_DEFINE([SIGC_HAVE_SUN_REVERSE_ITERATOR],[1])
  }
  fi
])

Yes it is defined in sigc++config.h.

When I compile that test by hand, it compiles just fine.

Looking at signal.h, I notice that the error message complains about line 780,
but the exact same code exists on line 716 and it doesn't complain about that.

Could you please give me the compiler errors with 
http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.0/libsigc++-2.0.17.tar.gz
(should be online any moment now)
and
http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.1/libsigc++-2.1.1.tar.gz
so that I have up-to-date line numbers.


> Looking at signal.h, I notice that the error message complains about line 780,
> but the exact same code exists on line 716 and it doesn't complain about that.

Maybe one uses a reverse_iterator and one uses a regular iterator.

Sorry for the delay, I didn't realize the ball was back in my court.

I've since upgraded to the Workshop 12 compiler suite from Sun, which has been out for several months.  I see the same issue with Workshop 12 as I did with 11.

Compiling libsigc++-2.1.1 WITHOUT using -library=stlport4, the C++ configure tests output:

checking dependency style of CC... (cached) none
checking if C++ compiler supports the use of a particular specialization when calling operator() template methods.... no
checking if C++ compiler supports the use of a particular specialization when calling operator() template methods omitting the template keyword.... yes
checking if C++ compiler allows usage of member function in initialization of static member field.... yes
checking whether C++ library symbols are declared in namespace std... yes
checking for non-standard Sun libCstd reverse_iterator... yes

The build errors out here:

gmake[3]: Entering directory `/local/src/RPM/BUILD/libsigc++-2.1.1/sigc++'
source='signal.cc' object='signal.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CXX   --mode=compile CC -DHAVE_CONFIG_H   -I.. -I..   -xO3 -xtarget=native -m64 -xarch=native -c -o signal.lo signal.cc
mkdir .libs
 CC -DHAVE_CONFIG_H -I.. -I.. -xO3 -xtarget=native -m64 -xarch=native -c signal.cc  -KPIC -DPIC -o .libs/signal.o
"../sigc++/signal.h", line 780: Error: Too few arguments for template std::reverse_iterator.
"/opt/SUNWspro/prod/include/CC/Cstd/rw/iterator", line 432: Error: "friend" declaration is incompatible with function template.
"../sigc++/signal.h", line 781:     Where: While specializing "std::reverse_iterator<std::list<sigc::slot_base>::iterator>".
"../sigc++/signal.h", line 781:     Where: Specialized in non-template code.
"../sigc++/signal.h", line 781: Error: The operation "std::reverse_iterator<std::list<sigc::slot_base>::iterator> != std::reverse_iterator<std::list<sigc::slot_base>::iterator>" is illegal.
"../sigc++/signal.h", line 783: Error: Pointer type needed instead of std::Pointer.
"../sigc++/signal.h", line 783: Error: Pointer type needed instead of std::Pointer.
"../sigc++/signal.h", line 785: Error: Pointer type needed instead of std::Pointer.
"../sigc++/signal.h", line 785: Error: Pointer type needed instead of std::Pointer.
7 Error(s) detected.
gmake[3]: *** [signal.lo] Error 1
gmake[3]: Leaving directory `/local/src/RPM/BUILD/libsigc++-2.1.1/sigc++'


If I build using the -library=stlport4 argument that Vladimir mentioned in comment #38, the build succeeds.  As Vladimir and I noted in subsequent comments, that's suboptimal, though, because -library=stlport4 is essentially "viral" -- if you build any of your libraries with it, then everything that links with that library must also be built with that option.

This seems to be the issue:
"../sigc++/signal.h", line 780: Error: Too few arguments for template
std::reverse_iterator.


It's difficult for me to investigate this without access to the compiler, but hopefully this is fairly simple. Could you take a look? 

Thanks for keeping on this Murray.  Your attention to detail on sigc++ and the other gtkmm components is appreciated.

I've built a number of other C++ packages in the last few months, including other prereqs for gtkmm and gtkmm itself and external packages (e.g. taglib, exempi).  Several of them have required -library=stlport4 to build -- not for the same reasons that sigc++ does, but it boils down to the same thing: modern open source projects have a better chance of building against stlport4 than they do against libCstd.

I'm definitely willing to spend some time looking at trying to get sigc++ to build without -library=stlport4 if you're interested in that, but I think it may be a moot point.  Even if we find a workaround that allows sigc++ to build without stlport4, not all authors are as willing to "humor" people that are on a non-Linux, non-g++ platform as you are, so other software packages aren't as likely to incorporate these types of workarounds.

I'm tempted to just say "sigc++ requires -library=stlport4 and Sun Workshop 10 or greater on Solaris" and be done with it.

What do you think?

BTW, if we do go that route, please update libsigc++ so that it uses the latest libtool (either 1.5.26 or the 2.2 release, if that comes out before you release the next libsigc++).  libtool >= 1.5.24 handles the -library= argument better on Solaris than earlier versions.

I would much rather just fix it, but I need someone to do a little investigation, or provide me access to a suitable system.

I will try to get the latest libtool into jhbuild.

Created attachment 106156 [details] [review]
This patch fixes the build failure of libsigc++2.2.0 using SUN compiler CC 5.9

I came across the build failure of libsigc++2.2.0 using SUN C++ compiler(CC 5.9) with libCstd by defalut. I wrote a patch to make the build get through and tested all the examples successfully. But I'm not sure about the patch, please help me review it.

Thanks.

Tim, does this fix it for you?

Yes it does, and all tests pass.  I'm using the same version of the compiler that Elaine is.

Excellent.

The patch made changes to a generated file so I made the same change at the relevant place in the .m4 macro and checked it in. I have also uploaded a libsigc++ 2.2.1 tarball with the correction.

Thanks again, Elaine.