Could not find a match for std::vector<unsigned>::assign since 1.0.12

[Dagobert Michelsen]

Hi,

since 1.0.12 I can't compile xapian any more:

gmake[4]: Entering directory `/home/dam/mgar/pkg/xapian/trunk/work/build-isa-sparcv8/xapian-core-1.0.12'
source='api/omdatabase.cc' object='api/omdatabase.lo' libtool=yes \
        DEPDIR=.deps depmode=none /bin/bash ./depcomp \
        /bin/bash ./libtool  --tag=CXX   --mode=compile /opt/studio/SOS11/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I./common -I./include   -I/opt/csw/include  -xO3 -xarch=v8 -I/opt/csw/include -c -o api/omdatabase.lo api/omdatabase.cc
 /opt/studio/SOS11/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I./common -I./include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include -c api/omdatabase.cc  -KPIC -DPIC -o api/.libs/omdatabase.o
"api/omdatabase.cc", line 453: Error: Could not find a match for std::vector<unsigned>::assign(Xapian::Utf8Iterator, Xapian::Utf8Iterator) needed in Xapian::Database::get_spelling_suggestion(const std::string &, unsigned) const.
1 Error(s) detected.
gmake[4]: *** [api/omdatabase.lo] Error 1

Platform is Solaris. I tried Solaris 8, 10 with Sun Studio 11, 12 and GCC 4.

[Olly Betts]

There are two things that puzzle me about this:

• That this fails with GCC which has its own STL implementation - Sun's C++ compiler doesn't seem to support templates fully, and we've had issues like this before, so that's not so surprising. What error message does GCC give?

• That this started with 1.0.12 - there was an (untested as I don't have access) fix for a Sun C++ compatibility issue in 1.0.12, but further down the file. Or are you just saying 1.0.12 is the earliest you tried which failed? If so what was the last version you successfully built?

[Dagobert Michelsen]

Regarding your questions:

• Compilation with GCC4 results in this error:

  gmake[4]: Entering directory `/home/dam/mgar/pkg/xapian/trunk/work/build-isa-sparcv8/xapian-core-1.0.12'
  /bin/bash ./libtool  --tag=CXX   --mode=link /opt/csw/gcc4/bin/g++ -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wformat-security -fno-gnu-keywords -Wundef -Wshadow -Winit-self -Wstrict-overflow=1 -fvisibility=hidden -O2 -pipe -mcpu=v8 -I/opt/csw/include  -L/opt/csw/gcc4/lib/. -mcpu=v8 -lm -L/opt/csw/lib -o bin/quartzcheck bin/bin_quartzcheck-quartzcheck.o  libquartzcheck.la libxapian.la 
  /opt/csw/gcc4/bin/g++ -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wformat-security -fno-gnu-keywords -Wundef -Wshadow -Winit-self -Wstrict-overflow=1 -fvisibility=hidden -O2 -pipe -mcpu=v8 -I/opt/csw/include -mcpu=v8 -o bin/.libs/quartzcheck bin/bin_quartzcheck-quartzcheck.o  -L/opt/csw/gcc4/lib/. -L/opt/csw/lib ./.libs/libquartzcheck.a -lm ./.libs/libxapian.so -lrt -lz -lnsl -lsocket /opt/csw/gcc4/lib/libstdc++.so  -Wl,-R -Wl,/opt/csw/lib -Wl,-R -Wl,/opt/csw/gcc4/lib
  ld: warning: file /opt/csw/gcc4/lib/./libstdc++.so: linked to /opt/csw/gcc4/lib/libstdc++.so: attempted multiple inclusion of file
  Undefined                       first referenced
   symbol                             in file
  __sync_fetch_and_add_4              bin/bin_quartzcheck-quartzcheck.o
  ld: fatal: Symbol referencing errors. No output written to bin/.libs/quartzcheck
  

  The compilation is done with

  CSWgcc4g++      gcc4g++ - GNU C++ Compiler
                  (sparc) 4.3.3,REV=2009.05.07
  

• Yes, 1.0.12 is the earliest failed. 1.0.11 compiles fine with Sun Studio 11. And 1.0.16 has the same behaviour as 1.0.12.

[Olly Betts]

OK, the issue with Sun's compiler looks to be a change to configure which accidentally ignores the flags needed to switch it to ANSI C++ mode. After configuring, this should result in a successful build:

make clean
make AM_CXXFLAGS="-library=stlport4 -features=tmplife"

Can you try that and confirm?

The GCC problem doesn't look to be related. Google finds a few hits for failures with similar messages. Nothing very helpful, but it might be related to multilibbing.

[Dagobert Michelsen]

The previous error is solved by the defined, however I now get a different error:

        /opt/studio/SOS11/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. -I../common -I../include -I../include -I./harness -I../backends/quartz  -I/opt/csw/include  -xO3 -xarch=v8 -I/opt/csw/include -c -o harness/backendmanager_remotetcp.o harness/backendmanager_remotetcp.cc
/bin/bash ../libtool  --tag=CXX   --mode=link /opt/studio/SOS11/SUNWspro/bin/CC  -xO3 -xarch=v8 -I/opt/csw/include -no-install  -xarch=v8 -lm -L/opt/csw/lib -o btreetest btreetest.o harness/backendmanager.o harness/backendmanager_multi.o harness/index_utils.o harness/testsuite.o harness/testutils.o harness/unixcmds.o harness/backendmanager_flint.o harness/backendmanager_inmemory.o harness/backendmanager_quartz.o harness/backendmanager_remoteprog.o harness/backendmanager_remotetcp.o ../libgetopt.la ../libquartzcheck.la ../libxapian.la 
mkdir .libs
/opt/studio/SOS11/SUNWspro/bin/CC -xO3 -xarch=v8 -I/opt/csw/include -xarch=v8 -o btreetest btreetest.o harness/backendmanager.o harness/backendmanager_multi.o harness/index_utils.o harness/testsuite.o harness/testutils.o harness/unixcmds.o harness/backendmanager_flint.o harness/backendmanager_inmemory.o harness/backendmanager_quartz.o harness/backendmanager_remoteprog.o harness/backendmanager_remotetcp.o  -L/opt/csw/lib ../.libs/libgetopt.a ../.libs/libquartzcheck.a ../.libs/libxapian.so -library=stlport4 -lz -lnsl -lsocket -lm  -R/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12/.libs -R/opt/csw/lib
Undefined                       first referenced
 symbol                             in file
__rwstd::rwse_eofbit_set       harness/index_utils.o
[Hint: static member __rwstd::rwse_eofbit_set must be defined in the program]

std::string::basic_string(const char*,const char*,const std::allocator<char>&) harness/index_utils.o
char*__rwstd::__rw_basis<char*,std::allocator<char> >::data()const harness/backendmanager.o
void std::string::__clone(unsigned) harness/unixcmds.o
__rwstd::except_msg_string::except_msg_string(unsigned,...) harness/index_utils.o
std::string &std::string::__sun_append(const std::string &) harness/backendmanager.o
__rwstd::__rwse_StringIndexOutOfRange harness/testsuite.o
[Hint: static member __rwstd::__rwse_StringIndexOutOfRange must be defined in the program]

__rwstd::__rwse_InvalidSizeParam harness/unixcmds.o
[Hint: static member __rwstd::__rwse_InvalidSizeParam must be defined in the program]

std::string::__nullref btreetest.o
[Hint: static member std::string::__nullref must be defined in the program]

void std::string::__initn(unsigned,char) btreetest.o
std::ostream &std::operator<<(std::ostream &,const char*) btreetest.o
__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::string::__getRep(unsigned,unsigned) btreetest.o
const char*__rwstd::rw_traits<char,std::char_traits<char> >::rfind(const char*,char,unsigned) harness/testsuite.o
std::basic_string<__type_0,__type_1,__type_2>std::operator+<char,std::char_traits<char>,std::allocator<char> >(const std::basic_string<__type_0,__type_1,__type_2>&,__type_0) harness/testsuite.o
__rwstd::facet_imp*std::locale::__make_explicit(const std::locale::id&,bool,int,__rwstd::facet_imp*(*)(int,const char*,unsigned))const btreetest.o
__rwstd::__rw_basis<char*,std::allocator<char> >__rwstd::__rw_basis<char*,std::allocator<char> >::operator=(char*const&) harness/backendmanager.o
void __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::__addReference() harness/backendmanager.o
__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >*std::string::__pref()const harness/backendmanager.o
std::ostream &std::operator<<(std::ostream &,char) btreetest.o
std::string std::string::__sun_concat(const std::string &)const btreetest.o
char*__rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::data()const harness/backendmanager.o
std::string std::string::__sun_concat(const char*)const btreetest.o
void std::string::__clone() btreetest.o
std::string &std::string::__sun_append(const char*) harness/backendmanager.o
char*std::string::replace(unsigned,unsigned,const char*,unsigned,unsigned,unsigned) harness/testsuite.o
void std::ifstream::open(const char*,int,long) harness/index_utils.o
void std::string::__unLink() btreetest.o
long __rwstd::__string_ref<char,std::char_traits<char>,std::allocator<char> >::__references()const harness/backendmanager.o
char*std::char_traits<char>::copy(char*,const char*,unsigned) harness/backendmanager.o
__rwstd::facet_imp*__rwstd::facet_maker<std::ctype<char> >::maker_func(int,const char*,unsigned) btreetest.o
__rwstd::rwse_badbit_set       harness/index_utils.o
[Hint: static member __rwstd::rwse_badbit_set must be defined in the program]

__rwstd::rwse_failbit_set      harness/index_utils.o
[Hint: static member __rwstd::rwse_failbit_set must be defined in the program]

ld: fatal: Symbol referencing errors. No output written to btreetest
gmake[6]: *** [btreetest] Error 1
gmake[6]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12/tests'
gmake[5]: *** [check-am] Error 2
gmake[5]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12/tests'
gmake[4]: *** [check] Error 2
gmake[4]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12/tests'
gmake[3]: *** [check-recursive] Error 1
gmake[3]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12'
gmake[2]: *** [check] Error 2
gmake[2]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk/work/build-isa-sparcv8/xapian-core-1.0.12'
gmake[1]: *** [test-work/build-isa-sparcv8/xapian-core-1.0.12/Makefile] Error 2
gmake[1]: Leaving directory `/home/dam/mgar/pkg/xapian-core/trunk'
gmake: *** [merge-isa-sparcv8] Error 2

BTW, I am packaging up Xapian for OpenCSW and the project offers accounts on the buildfarm for upstream maintainers who don't directly work on releasable packages to enhance Solaris support. If you are interested you can get an account on the farm equipped with Solaris 8-10 both Sparc and x86.

[Olly Betts]

OK, the first build failure for Sun's C++ is fixed in trunk r13533 and backported for 1.0.17 as r13534.

I still don't really have any ideas about the GCC error.

The new Sun C++ error makes me wonder if you did the "make clean" first?

[Olly Betts]

Oh, and an account would certainly be useful. I'm not likely to be able to do much for the next month though.

[Dagobert Michelsen]

I tested 1.0.16, but I think it is best to continue testing with the latest version 1.1.2. There are still some other issues with 1.1.2 for which I'll open another bug for cleanliness.

To access the farm you can mail me your intended username and ssh public key to dam [at] opencsw.org.

[Dagobert Michelsen]

Replying to olly:

The new Sun C++ error makes me wonder if you did the "make clean" first?

Yes, I just reproduced it with a clean build.

[Olly Betts]

trunk builds OK with GCC on Solaris, so I guess that problem is specific to something in the quartz-related code (which is gone in trunk).

[Olly Betts]

Hmm, the opencsw buildfarm machine I now have an account on doesn't seem to have Sun's compiler on (/opt/studio doesn't exist, and there's no CC under /opt according to find), so I'm going to struggle to debug that one.

Moving the milestone to 1.0.17 to remind me to check the quartz-related issue with GCC there.

[Dagobert Michelsen]

Please take a look at /etc/SETUP from "login":

  Software      | Path                  | login |  b8s |  b9s | b10s |  b8x |  b9x | b10x
  --------------+-----------------------+-------+------+------+------+------+------+------
  SunStudio 11  | /opt/studio/SOS11     |  No   | Yes  | Yes  | Yes  | Yes  | Yes  | Yes  
  SunStudio 12  | /opt/studio/SOS12     |  No   |  No  | Yes  | Yes  |  No  | Yes  | Yes  
  SunStudio 12u1| /opt/studio/sunstudio12.1 No  |  No  |  No  | Yes  |  No  |  No  | Yes  
  GCCFSS 4.2.0  | /opt/SUNWgccfss/4.2.0 |  No   | Yes  | Yes  | Yes  |  No  |  No  |  No
  GCCFSS 4.2.1  | /opt/SUNWgccfss/4.2.1 |  No   | Yes  | Yes  | Yes  |  No  |  No  |  No
  GCC 3         | /opt/csw/gcc3         |  No   | Yes  | Yes  | Yes  | Yes  | Yes  | Yes
  GCC 4         | /opt/csw/gcc3         |  No   | Yes  | Yes  | Yes  | Yes  | Yes  | Yes

[Olly Betts]

Aha, thanks.

BTW, the "Path" for GCC 4 looks wrong there...

I would set the milestone back to 1.1.3, but it looks like I failed to change it before.

[Olly Betts]

OK, the 1.0 branch builds fine for me on build8s with CXX=/opt/studio/SOS11/SUNWspro/bin/CC which I assume is version 11 from the pathname, though CC -V reports "CC: Sun C++ 5.8 Patch 121017-20 2009/04/22".

CXX=/opt/csw/gcc4/bin/g++ on build8s fails at configure time because built binaries don't run due to library search path issues (which sounds like an installation issue to me):

-bash-4.0$ cat hellow.cc
#include <iostream>
using namespace std;
int main() {
    cout << "Hello World" << endl;
}
-bash-4.0$ /opt/csw/gcc4/bin/g++ -O2 -o hellow hellow.cc
-bash-4.0$ ./hellow
ld.so.1: hellow: fatal: libstdc++.so.6: open failed: No such file or directory
Killed
-bash-4.0$ 

Anyway, I think this bug has become much too confused - we have several different and unrelated issues with different compilers in here, many of which are fixed, and the only commonality is really that they happen on Solaris. The problem actually described in the title and description is now fixed, and I've also fixed a number of other issues on Solaris, so I'm going to close this ticket.

I'm working towards being able to run scripted builds on the opencsw farm, so I should pick up any other issues eventually, but meanwhile if you run into further problems, please do open tickets for them, but please keep them as separate tickets unless the errors clearly have a common cause, so that we can sanely track them separately.