We saw a similar problem with gtkmm. I will investigate.

Hmm, no I don't have this problem on linux with the 1.2.5 tarball.

My suggestions:
1. Try an earler version.
2. Try to run autogen.sh. - from cvs if necessary.
3. Mention it on the mailing list.
and please tell us the results.

I checked 1.2.3 with(same done earlier with 1.2.5):

$ ./configure --prefix=/software/@sys/usr --host=alphaev67-dec-osf5.1
[...]
checking dependency style of cxx... tru64
checking whether we are using SUN CC compiler... no
checking if linker supports global constructors... yes
rmdir: `.libs': File exists
checking if C++ compiler uses std namespace ... yes
checking if C++ compiler supports bool (required)... yes
[...]

The above happens also with 1.2.4(no idea about 1.2.5)

make
[...]
cxx -DHAVE_CONFIG_H  -I.. -I.. -I../sigc++/config 
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  -O2 -arch ev56 -c -o method_slot_test.o
`test -f 'method_slot_test.cc' || echo './'`method_slot_test.cc
cxx: Error: ../sigc++/method_slot.h, line 87: mangled name collision for
          template function instantiations with types
          "void (SigC::Slot1<void, Foo &> *, __ptr_mem)" and
          "void (SigC::Slot1<void, const Foo &> *, __ptr_mem)"
  slot(R (Obj::*method)() const)
--^
cxx: Info: 1 error detected in the compilation of "method_slot_test.cc".
make[1]: *** [method_slot_test.o] Error 1
make[1]: Leaving directory
`/afs/gsf.de/sources/ev56/libsigc++-1.2.3/tests'


The above also happens with 1.2.4.

The *-1.2.4/REAAME says:

Contact info:
   Maintainer:  mailto: kenelson@ece.ucdavis.edu
   Maillist: mailto: libsigc-main@lists.sourceforge.net
   Homepage: http://libsigc.sourceforge.net
   Ftp: ftp://download.sourceforge.net/pub/sourceforge/libsigc/
   CVS:


So what's the cvs source? Seems

cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome -z6 co libsigc++

was the right guess.

Then, when I investigate the autogen.sh steps manually, I see:

$ autoheader
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:   AC_DEFINE([NEED_MAIN], 1,
WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
configure.in:94: warning: AC_CANONICAL_HOST invoked multiple times
configure.in:95: warning: AC_CANONICAL_HOST invoked multiple times
$ ./configure --prefix=/software/@sys/usr 
checking for a BSD-compatible install... /software/@sys/usr/bin/install -c
checking whether build environment is sane... yes
/afs/gsf.de/sources/ev56/libsigc++-1.2.4/libsigc++/scripts/missing:
Unknown `--run' option
Try`/afs/gsf.de/sources/ev56/libsigc++-1.2.4/libsigc++/scripts/missing
--help' for more information
configure: WARNING: `missing' script is too old or missing
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... cc
[...]
checking if C++ compiler uses template copy ctor... no
checking if C++ compiler allows void returns... yes
checking if C++ compiler allows specialization of references... yes
checking if C++ environment provides all required features... yes
checking pthread.h usability... no
checking pthread.h presence... no
checking for pthread.h... no
checking if should compile with pthreads... no
configure: error: conditional "SIGCRC" was never defined.
Usually this means the macro was only invoked conditionally.
$


Hmm, as usual for many GNOME projects, thread detection for Tru64Unix
is broken. I have to specify -pthread in CFLAGS and CXXFLAGS to avoid
this in config.log:

configure:19796: checking pthread.h usability
configure:19808: cxx -c -O2 -arch ev56 -I/software/@sys/usr/include
-I/usr/local/include -I/usr/
local/openssl/include conftest.cc >&5
cxx: Error: /usr/include/pthread.h, line 312: #error directive: "Please
          compile the module including pthread.h with -pthread"
#  error "Please compile the module including pthread.h with -pthread"
---^
cxx: Info: 1 error detected in the compilation of "conftest.cc".
configure:19811: $? = 1


No, for libsigc++ I have to set -pthread under CC and CXX variables. :(
BTW: 
pthread_keycreate and pthread_self are not resolved during linking
step although pthread.h was found(but maybe that's expected).


Anyway, the real obstacle is:

configure:20405: error: conditional "SIGCRC" was never defined.
Usually this means the macro was only invoked conditionally.

and then configure exits.

So, does that mean that no earlier version works either?

> what's the cvs source? Seems
>
> cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome -z6 co > 
libsigc++

No, it's libsigc++-1.2:
http://libsigc.sourceforge.net/devel.shtml#cvs


 

I cannot get 2.2.3 nor 2.2.4 to compile. Please update the README so
that user know where to get cvs sources.

The current 1.2 branch works for me:

checking if C++ compiler allows specialization of references... yes
checking if C++ compiler allows default template types (required)... yes
checking if C++ environment provides all required features... yes
configure: creating ./config.status


There are no checks for threads at all in configure in this cvs
branch! But, at least I don't get the error above("error: conditional
"SIGCRC" "):


However, I see during "make":

cxx -DHAVE_CONFIG_H  -I.. -I.. -I../sigc++/config 
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  -O2 -arch ev56 -c -o method_slot_test.o
method_slot_test.cc
cxx: Error: ../sigc++/method_slot.h, line 107: mangled name collision for
          template function instantiations with types
          "void (SigC::Slot1<void, Foo &> *, __ptr_mem)" and
          "void (SigC::Slot1<void, const Foo &> *, __ptr_mem)"
  slot(R (Obj::*method)() const)
--^
cxx: Info: 1 error detected in the compilation of "method_slot_test.cc".
make[1]: *** [method_slot_test.o] Error 1
make[1]: Leaving directory `/afs/gsf.de/sources/ev56/libsigc++-1.2/tests'

Are you maybe using a different compiler this time? There should be 
zero code differences between the 1.2.5 tarball and libsigc++-1.2 in 
cvs. You could do a diff to check that.

If you think that there should be some thread check thing, then 
please do submit a patch.

Has any version of libsigc++ ever worked on Tru64Unixfor you?

No, I never used that before. Even to compile tests/ gives me an error
for libsigc++-1.1.9:

cxx -pthread -DHAVE_CONFIG_H -I.. -I.. -I../sigc++/config 
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  -O2 -arch ev56 -c method_slot_test.cc
cxx: Error: ../sigc++/method_slot.h, line 87: mangled name collision for
          template function instantiations with types
          "void (SigC::Slot1<void, Foo &> *, __ptr_mem)" and
          "void (SigC::Slot1<void, const Foo &> *, __ptr_mem)"
  slot(R (Obj::*method)() const)
--^
cxx: Info: 1 error detected in the compilation of "method_slot_test.cc".
make[1]: *** [method_slot_test.o] Error 1
make[1]: Leaving directory `/mnt/libsigc++-1.1.9/tests'


That code can be compiled with g++, I I cannot link successfully
afterwards. When I decide not yto compile tests/ subdir, make finishes
the rest.

I don't think I've changed compiler since May 22.

To summarize, I can compile the library except the
tests/method_slot_test.cc.
When I installed 1.1.9 and current cvs -1.2, I got:

ls -la /software/@sys/usr/lib/libsig*
-rw-r--r--    1 cron     daemon      47098 Jun  2 17:23
/software/@sys/usr/lib/libsigc-1.1.a
-rwxr-xr-x    1 cron     daemon        815 Jun  2 17:23
/software/@sys/usr/lib/libsigc-1.1.la
lrwxr-xr-x    1 cron     daemon         20 Jun  2 17:23
/software/@sys/usr/lib/libsigc-1.1.so -> libsigc-1.1.so.3.0.0
-rwxr-xr-x    1 cron     daemon      67600 Jun  2 17:23
/software/@sys/usr/lib/libsigc-1.1.so.3.0.0
-rw-r--r--    1 cron     daemon      42916 Jun  2 17:28
/software/@sys/usr/lib/libsigc-1.2.a
-rwxr-xr-x    1 cron     daemon        898 Jun  2 17:28
/software/@sys/usr/lib/libsigc-1.2.la
lrwxr-xr-x    1 cron     daemon         20 Jun  2 17:28
/software/@sys/usr/lib/libsigc-1.2.so -> libsigc-1.2.so.5.0.6
lrwxr-xr-x    1 cron     daemon         20 Jun  2 17:28
/software/@sys/usr/lib/libsigc-1.2.so.5 -> libsigc-1.2.so.5.0.6
-rwxr-xr-x    1 cron     daemon      67152 Jun  2 17:28
/software/@sys/usr/lib/libsigc-1.2.so.5.0.6


Please fix the method_slot_test.cc in cvs. Otherwise close this
bugreport. I cannot reproduce the original problem. Thanks!

> To summarize, I can compile the library except the
> tests/method_slot_test.cc.

So we should completely forget about the original problem?

re. the problem in tests/method_slot_test.cc. I don't understand why 
this builds for you with libsigc++ 1.2.5 but not with the libsigc++-
1.2 cvs. They should be almost exactly the same - if there are 
differences then please show us.

I am very confused, but I want to help.

I retried to compile 1.2.5 and I get the same error with
tests/method_slot_test.cc. It might be I used gcc/g++ to compile and
link(i.e. configured to use gcc/g++ instead of cc/cxx).

Actually, I now really successfully built with gcc/g++, all "make
check" tests also succeeded(tested 1.2.5 release).

So, the original problem that the installed libs were somewhat wrongly
softlinked to each other isn't reproducible. There're several bugs in
libtool on this platform. It seems now I have working version.

The problem with tests/method_slot_test.cc is therefore cxx specific
for this platform.

You are confusing the hell out of me. I don't know if your various 
success/failure reports are with gcc or this cc/gxx compiler.

I will assume that the only remaining problem is:

With Tru64Unix's cc/gxx compiler,
tests/method_slot_test.cc does not compile, giving this error:

cxx -pthread -DHAVE_CONFIG_H -I.. -I.. -I../sigc++/config 
-I/software/@sys/usr/include -I/usr/local/include
-I/usr/local/openssl/include  -O2 -arch ev56 -c method_slot_test.cc
cxx: Error: ../sigc++/method_slot.h, line 87: mangled name collision 
for
          template function instantiations with types
          "void (SigC::Slot1<void, Foo &> *, __ptr_mem)" and
          "void (SigC::Slot1<void, const Foo &> *, __ptr_mem)"
  slot(R (Obj::*method)() const)

Unfortunately, because you are the only one who can reproduce this, 
because the platform is rare, you will probably have to try patch it 
yourself. It doesn't look obvious to me.

I'm hoping for a "Yes, that's right" here.

Yes, that's the only problem I have. And reading once more the
original report - libtool-1.5 was terribly buggy. I'm willing to test
the patch for tests/method_slot_test.cc , but cannot write it myself.
Sorry for all that confusion. I had hard time to get working several
GNU tools on this platform and really cannot keep track of everything
anymore.

If you need test machine, look at http://www.testdrive.hp.com/ and
make an account on Tru64Unix box for free.

libsigc++ is fairly simple (compared to gtkmm) so somebody might like
to try this just for fun.

Is this bug still relevant?

Well, it's still useful to know that libsigc++ does not build on this compiler,
and that anyone is welcome to try to port it.

The problem is that (like many commercial vendors) the Tru64 cxx works very hard
to be backward compatible.  Sometimes it goes to ridiculous lengths, and this is
one of those cases.

The compiler's *default* name mangling method hasn't changed since the ARM days.
It does support other name mangling methods, including the ISO/ANSI C++
specified method.  See the

  -model ansi

in the cxx(1) man page.  There are some important caveats (everything that links
against a library that was built with `-model ansi' must also be compiled with
`-model ansi') and notes, but if you use that option, everything will build and
link, and all 13 tests passed.

FYI, I used

  CXXFLAGS='-std strict_ansi -model ansi -O2 -g3 -readonly_strings'

with cxx (cxx -V):
Compaq C++ V6.5-042 for Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-042 (cxx) cxx Driver

And did it then work?

If libsigc++ will only build with a certain option on that platform then we must
obviously use that option (or put it in the documentation), regardless of how
inconvienient it is.

Sorry for the late response.

When building 1.2.x, using the flags I show above allowed libsigc++ to compile
out of the box.  In addition, all 13 tests passed.

However, I just tried libsigc++-2.0.6 tonight with the same compiler flags, and
it fails to compile (in adaptors/lambda/lambda.cc) because of an issue in the
type_traits.h file.

I'll log a new bug against 2.0.6, since the problem is a different one.

This bug (whatever it was) seems to have been fixed. I'm not sure what other bug
was opened for 2.0.6.