Opened 15 years ago

Closed 14 years ago

#403 closed defect (fixed)

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

Reported by: Dagobert Michelsen Owned by: Olly Betts
Priority: normal Milestone: 1.0.17
Component: Other Version: 1.0.12
Severity: blocker Keywords:
Cc: dam@… Blocked By:
Blocking: Operating System: Solaris

Description

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.

Change History (14)

comment:1 by Olly Betts, 15 years ago

Milestone: 1.1.3

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?

comment:2 by Dagobert Michelsen, 15 years ago

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.

comment:3 by Dagobert Michelsen, 15 years ago

Cc: dam@… added

comment:4 by Olly Betts, 15 years ago

Status: newassigned

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.

comment:5 by Dagobert Michelsen, 15 years ago

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.

comment:6 by Olly Betts, 15 years ago

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?

comment:7 by Olly Betts, 15 years ago

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

comment:8 by Dagobert Michelsen, 15 years ago

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.

in reply to:  6 comment:9 by Dagobert Michelsen, 15 years ago

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.

comment:10 by Olly Betts, 14 years ago

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).

comment:11 by Olly Betts, 14 years ago

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.

comment:12 by Dagobert Michelsen, 14 years ago

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

comment:13 by Olly Betts, 14 years ago

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.

comment:14 by Olly Betts, 14 years ago

Milestone: 1.1.31.0.17
Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.