Compile failure with fairly simple use of multi-index / hashing on Solaris with CC 5.8 (boost 1.34.0)
I've a relatively basic example of using the multi-index capability that fails to compile on Studio 11 (CC 5.8) on Sparc. I submitted it to the tracker before spotting the injunction to talk to the mailing list first. Can anyone offer any relief here?
Hello Benson,
----- Mensaje original -----
De: Benson Margulies
I've a relatively basic example of using the multi-index capability that fails to compile on Studio 11 (CC 5.8) on Sparc.
It's weird, because Sun C++ 5.8 is a supported compiler, and poses few problems AFAIK. Can you verify if you've got the same patch level as used in the regression tests? (Sun C++ 5.8 Patch 121017-03 2006/07/19) http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/OSL4- V2.html I've tried your snippet in GCC 3.4.4 and everything works fine, so the issue seems to be related to the compiler. Looks like the problem has to do with the retrieval of indices by tag, so as a workaround you can try retrieving by number, but I'd ask you to first verify the patch level thing.
I submitted it to the tracker before spotting the injunction to talk to the mailing list first [...]
In the particular case of Boost.MultiIndex, I'd rather you posted your request here and only issued a ticket if we can't solve the problem on the spot. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I am not up to date.
CC: Sun C++ 5.8 2005/10/13
I'll go figure out how to get patched. Thanks.
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z"
Sent: Wednesday, June 20, 2007 4:57 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Compile failure with fairly simple use of multi-index/hashing on Solaris with CC 5.8 (boost 1.34.0)
Hello Benson,
----- Mensaje original -----
De: Benson Margulies
I've a relatively basic example of using the multi-index capability that fails to compile on Studio 11 (CC 5.8) on Sparc.
It's weird, because Sun C++ 5.8 is a supported compiler, and poses few problems AFAIK. Can you verify if you've got the same patch level as used in the regression tests? (Sun C++ 5.8 Patch 121017-03 2006/07/19) http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/OSL4- V2.html I've tried your snippet in GCC 3.4.4 and everything works fine, so the issue seems to be related to the compiler. Looks like the problem has to do with the retrieval of indices by tag, so as a workaround you can try retrieving by number, but I'd ask you to first verify the patch level thing.
I submitted it to the tracker before spotting the injunction to talk to the mailing list first [...]
In the particular case of Boost.MultiIndex, I'd rather you posted your request here and only issued a ticket if we can't solve the problem on the spot. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
----- Mensaje original -----
De: Benson Margulies
I am not up to date.
CC: Sun C++ 5.8 2005/10/13
I'll go figure out how to get patched. Thanks.
You're welcome. Thanks for using Boost.MultiIndex. Please report back when you get the proper patch level so that I can confidently close the ticket. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Now I've got: CC: Sun C++ 5.8 Patch 121017-11 2007/05/02
And I get the same errors.
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z"
Sent: Wednesday, June 20, 2007 5:08 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Compile failure with fairly simple use ofmulti-index/hashing on Solaris with CC 5.8 (boost 1.34.0)
----- Mensaje original -----
De: Benson Margulies
I am not up to date.
CC: Sun C++ 5.8 2005/10/13
I'll go figure out how to get patched. Thanks.
You're welcome. Thanks for using Boost.MultiIndex. Please report back when you get the proper patch level so that I can confidently close the ticket. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I decided to try to run the regression suite. Unfortunately, the regression suite isn't working with --toolsets=sunpro.
# Building "process_jam_log" ("/sunblade1/benson/boost/boost/tools/jam/src/bin.solaris/bjam" --v2 "-sBOOST_BUILD_PATH=/sunblade1/benson/boost" "-sBOOST_ROOT=/sunblade1/benson/boost/boost" sunpro)...
[1] + exit 1 nohup python regression.py --runner=BensonMarguliesBasis --toolsets=sunpro
Building Boost.Regex with the optional Unicode/ICU support disabled.
Please refer to the Boost.Regex documentation for more information
(don't panic: this is a strictly optional feature).
warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, you may not be able to build C++ programs.
warning: Use the "--toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
notice: could not find main target sunpro
notice: assuming it's a name of file to create
don't know how to make <e>sunpro
...found 1 target...
...can't find 1 target...
# Searching for "process_jam_log" in "/sunblade1/benson/boost/boost/dist/bin"...
Traceback (most recent call last):
File "regression.py", line 1013, in ?
commands[ command ]( **accept_args( args ) )
File "regression.py", line 808, in regression
v2, [] )
File "regression.py", line 465, in setup
build_if_needed( process_jam_log, pjl_toolset, toolsets, v2 )
File "regression.py", line 411, in build_if_needed
tool[ 'build_path' ] = tool_path( tool, v2 )
File "regression.py", line 372, in tool_path
raise Exception( 'Cannot find "%s" in any of the following locations:\n%s' % (
Exception: Cannot find "process_jam_log" in any of the following locations:
/sunblade1/benson/boost/process_jam_log
/sunblade1/benson/boost/boost/dist/bin
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z"
Sent: Wednesday, June 20, 2007 5:08 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Compile failure with fairly simple use ofmulti-index/hashing on Solaris with CC 5.8 (boost 1.34.0)
----- Mensaje original -----
De: Benson Margulies
I am not up to date.
CC: Sun C++ 5.8 2005/10/13
I'll go figure out how to get patched. Thanks.
You're welcome. Thanks for using Boost.MultiIndex. Please report back when you get the proper patch level so that I can confidently close the ticket. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Jun 20, 2007, at 6:39 PM, Benson Margulies wrote:
I decided to try to run the regression suite. Unfortunately, the regression suite isn't working with --toolsets=sunpro.
# Building "process_jam_log" ("/sunblade1/benson/boost/boost/tools/ jam/src/bin.solaris/bjam" --v2 "-sBOOST_BUILD_PATH=/sunblade1/ benson/boost" "-sBOOST_ROOT=/sunblade1/benson/boost/boost" sunpro)...
I have the same problem, both the sun-5.7 and sun-5.8 (Studio 10 and 11) compilers seg fault when compiling process_jam_log.cpp. Here's what I get: sun.compile.c++ ../../../bin.v2/tools/regression/build/sun-5.7/ release/link-static/process_jam_log.o
Signal 11: while processing ../process_jam_log.cpp at line 378.
"/opt/SUNWspro/bin/CC" -xtarget=ultra4 -xarch=v9b -xcode=pic32 - fast -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"../../.." -c -o "../../../ bin.v2/tools/regression/build/sun-5.7/release/link-static/ process_jam_log.o" "../process_jam_log.cpp" While I can build bjam with the Sun compilers okay, I have to use gcc to build process jam log. You may want to try building your own process_jam_log executable by hand, even though it's only really necessary if you plan on running regression tests. Here's what I do: cd boost/tools/regression/build "/sierra/Dev/kbelco/boost/boost/tools/jam/src/bin.solaris/bjam" --v2 "-sBOOST_BUILD_PATH=/sierra/Dev/kbelco/boost" "-sBOOST_ROOT=/sierra/ Dev/kbelco/boost/boost" sun -- Noel
Unfortunately, I can't get it to build with gcc. Bjam insists on trying to use linker options that aren't valid. I haven't determined if it is expecting the GNU linker and I've got GCC configured for the Sun linker, or the other way around. What are you using? On one machine of mine, bjam leaves out the compile command altogether when I give it -toolset gcc. -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of K. Noel Belcourt Sent: Wednesday, June 20, 2007 11:38 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compile failure with fairly simple use ofmulti-index/hashing on Solaris with CC 5.8 (boost 1.34.0) On Jun 20, 2007, at 6:39 PM, Benson Margulies wrote:
I decided to try to run the regression suite. Unfortunately, the regression suite isn't working with --toolsets=sunpro.
# Building "process_jam_log" ("/sunblade1/benson/boost/boost/tools/ jam/src/bin.solaris/bjam" --v2 "-sBOOST_BUILD_PATH=/sunblade1/ benson/boost" "-sBOOST_ROOT=/sunblade1/benson/boost/boost" sunpro)...
I have the same problem, both the sun-5.7 and sun-5.8 (Studio 10 and 11) compilers seg fault when compiling process_jam_log.cpp. Here's what I get: sun.compile.c++ ../../../bin.v2/tools/regression/build/sun-5.7/ release/link-static/process_jam_log.o
Signal 11: while processing ../process_jam_log.cpp at line 378.
"/opt/SUNWspro/bin/CC" -xtarget=ultra4 -xarch=v9b -xcode=pic32 - fast -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"../../.." -c -o "../../../ bin.v2/tools/regression/build/sun-5.7/release/link-static/ process_jam_log.o" "../process_jam_log.cpp" While I can build bjam with the Sun compilers okay, I have to use gcc to build process jam log. You may want to try building your own process_jam_log executable by hand, even though it's only really necessary if you plan on running regression tests. Here's what I do: cd boost/tools/regression/build "/sierra/Dev/kbelco/boost/boost/tools/jam/src/bin.solaris/bjam" --v2 "-sBOOST_BUILD_PATH=/sierra/Dev/kbelco/boost" "-sBOOST_ROOT=/sierra/ Dev/kbelco/boost/boost" sun -- Noel _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Jun 21, 2007, at 5:50 AM, Benson Margulies wrote:
Unfortunately, I can't get it to build with gcc.
Let's back up a second. You only need to build process_jam_log if you're planning on running the Boost regression tests. If you're not going to run the regression tests, then I suggest you not waste your time trying to build it. If you're going to run tests, then you should post your questions to the boost-testing mailing list.
Bjam insists on trying to use linker options that aren't valid.
It would help if you could send (1) the bjam command line and (2) send the link line and error message.
I haven't determined if it is expecting the GNU linker and I've got GCC configured for the Sun linker, or the other way around. What are you using?
gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/ usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 And please don't top post when you reply, it makes it very hard to follow the discussion. -- Noel
On Jun 21, 2007, at 5:50 AM, Benson Margulies wrote:
Unfortunately, I can't get it to build with gcc.
Let's back up a second. You only need to build process_jam_log if you're planning on running the Boost regression tests. If you're not going to run the regression tests, then I suggest you not waste your time trying to build it. If you're going to run tests, then you should post your questions to the boost-testing mailing list.
[BIM] I thought that I could contribute to the resolution of my overall problem by joining the regressing platoon. I will happily take my specific issues with that process to the testing list.
Bjam insists on trying to use linker options that aren't valid.
It would help if you could send (1) the bjam command line and (2) send the link line and error message.
[BIM] I will now go get some more clarity on the bjam boostrap issue with gcc. The 'sun' versus 'sunpro' issue, however, seems to be purely a defect in the configure script.
I changed the subject line to create a clean thread. I'm trying to follow the basic instructions to build the libs on Solaris 10 with gcc 3.4.2. I get similar results for a variety of gcc versions that I have on this system. The gcc -v output is at the bottom. Script started on Thu Jun 21 12:18:28 2007 configure --without-icu --with-toolset=gcc -n Building Boost.Jam with toolset gcc... tools/jam/src/bin.solaris/bjam -n Detecting Python version... 2.2 -n Detecting Python root... /opt/sfw -n Unicode/ICU support for Boost.Regex?... disabled. Generating Boost.Build configuration in user-config.jam... Generating Makefile... make ./tools/jam/src/bin.solaris/bjam --user-config=user-config.jam Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...patience... ...found 4733 targets... ...updating 1478 targets... MkDir1 bin.v2/libs/signals MkDir1 bin.v2/libs/signals/build MkDir1 bin.v2/libs/signals/build/gcc-3.4.2 MkDir1 bin.v2/libs/signals/build/gcc-3.4.2/debug MkDir1 bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi gcc.compile.c++ bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/trackable.o gcc.compile.c++ bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/connection.o gcc.compile.c++ bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/named_slot_map .o gcc.compile.c++ bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/signal_base.o gcc.compile.c++ bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/slot.o gcc.link.dll bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/libboost_signa ls-gcc34-mt-d-1_34.so.1.34.0 /usr/ccs/bin/ld: illegal option -- start-group /usr/ccs/bin/ld: illegal option -- end-group usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit [-a] create an absolute file [-b] do not do special PIC relocations in a.out [-B direct | nodirect] establish direct bindings, or inhibit direct binding to, the object being created [-B dynamic | static] search for shared libraries|archives [-B eliminate] eliminate unqualified global symbols from the symbol table [-B group] relocate object from within group [-B local] reduce unqualified global symbols to local [-B reduce] process symbol reductions [-B symbolic] bind external references to definitions when creating shared objects [-c name] record configuration file `name' [-C] demangle C++ symbol name diagnostics [-d y | n] operate in dynamic|static mode [-D token,...] print diagnostic messages [-e epsym] use `epsym' as entry point address [-f name] specify library for which this file is an auxiliary filter [-F name] specify library for which this file is a filter [-G] create a shared object [-h name] use `name' as internal shared object identifier [-i] ignore LD_LIBRARY_PATH setting [-I name] use `name' as path of interpreter [-l x] search for libx.so or libx.a [-L path] search for libraries in directory `path' [-m] print memory map [-M mapfile] use processing directives contained in `mapfile' [-N string] create a dynamic dependency for `string' [-o outfile] name the output file `outfile' [-p auditlib] identify audit library to accompany this object [-P auditlib] identify audit library for processing the dependencies of this object [-Q y | n] do|do not place version information in output file [-r] create a relocatable object [-R path] specify a library search path to be used at run time [-s] strip any symbol and debugging information [-S supportlib] specify a link-edit support library [-t] do not warn of multiply-defined symbols that have different sizes or alignments [-u symname] create an undefined symbol `symname' [-V] print version information [-Y P,dirlist] use `dirlist' as a default path when searching for libraries [-z absexec] when building an executable absolute symbols referenced in dynamic objects are promoted to the executable [-z allextract | defaultextract | weakextract] extract all member files, only members that resolve undefined tor tentative symbols, or allow extraction of archive members to resolvetweak references from archive files [-z combreloc] combine multiple relocation sections [-z nocompstrtab] disable compression of string tables [-z defs] disallow undefined symbol references [-z direct | nodirect] enable|disable direct binding to shared object dependencies [-z endfiltee] marks a filtee such that it will terminate a filters search [-z finiarray=function] name of function to be appended to the .finiarray [-z groupperm | nogroupperm] enable|disable setting of group permissions on dynamic dependencies [-z help ] print this usage message [-z ignore | record] ignore|record unused dynamic dependencies [-z initarray=function] name of function to be appended to the .initarray [-z initfirst] mark object to indicate that its .init section should be executed before the .init section of any other objects [-z interpose] dynamic object is to be an `interposer' on direct bindings [-z lazyload | nolazyload] enable|disable delayed loading of shared object dependencies [-z ld32=arg1,arg2,...] define arguments applicable to the 32-bit class of ld(1) [-z ld64=arg1,arg2,...] define arguments applicable to the 64-bit class of ld(1) [-z loadfltr] mark filter as requiring immediate loading of its filtees at runtime [-z muldefs] allow multiply-defined symbols [-z nodefs] allow undefined symbol references [-z nodefaultlib] mark object to ignore any default library search path [-z nodelete] mark object as non-deletable [-z nodlopen] mark object as non-dlopen()'able [-z nodump] mark object as non-dldump()'able [-z nopartial] expand any partially initialized symbols [-z noversion] don't record any version sections [-z now] mark object as requiring non-lazy binding [-z origin] mark object as requiring $ORIGIN processing [-z preinitarray=function] name of function to be appended to the .preinitarray [-z redlocsym] reduce local syms in .symtab to a minimum [-z rescan] rescan archive list until no further member extraction occurs [-z text] disallow output relocations against text [-z textoff] allow output relocations against text [-z textwarn] warn if there are relocations against text [-z verbose] generate warnings for suspicious processings collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/libboost_sign als-gcc34-mt-d-1_34.so.1.34.0" -Wl,-h -Wl,libboost_signals-gcc34-mt-d-1_34.so.1.34.0 -shared -Wl,--start-group "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/trackable.o" "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/connection.o" "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/named_slot_ma p.o" "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/signal_base.o " "bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/slot.o" -lrt -Wl,--end-group -g -pthreads ...failed gcc.link.dll bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/libboost_signa ls-gcc34-mt-d-1_34.so.1.34.0... MkDir1 bin.v2/libs/test MkDir1 bin.v2/libs/test/build MkDir1 bin.v2/libs/test/build/gcc-3.4.2 MkDir1 bin.v2/libs/test/build/gcc-3.4.2/debug MkDir1 bin.v2/libs/test/build/gcc-3.4.2/debug/threading-multi gcc.compile.c++ bin.v2/libs/test/build/gcc-3.4.2/debug/threading-multi/execution_monitor .o gcc.compile.c++ bin.v2/libs/test/build/gcc-3.4.2/debug/threading-multi/cpp_main.o ^C...interrupted ...failed updating 1 target... ...updated 16 targets... script done on Thu Jun 21 12:20:30 2007 Reading specs from /opt/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.2/specs Configured with: ../gcc-3.4.2/configure --prefix=/opt/sfw --with-ld=/usr/ccs/bin/ld --with-gnu-as --with-as=/opt/sfw/bin/gas --enable-shared --disable-libgcj Thread model: posix gcc version 3.4.2
On Jun 21, 2007, at 10:29 AM, Benson Margulies wrote:
I get similar results for a variety of gcc versions that I have on this system. The gcc -v output is at the bottom.
bin.v2/libs/signals/build/gcc-3.4.2/debug/threading-multi/ libboost_signa ls-gcc34-mt-d-1_34.so.1.34.0 /usr/ccs/bin/ld: illegal option -- start-group /usr/ccs/bin/ld: illegal option -- end-group
Reading specs from /opt/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.2/specs Configured with: ../gcc-3.4.2/configure --prefix=/opt/sfw --with-ld=/usr/ccs/bin/ld --with-gnu-as --with-as=/opt/sfw/bin/gas --enable-shared --disable-libgcj Thread model: posix gcc version 3.4.2
Since your gcc compiler was configured to use Sun's ld, try adding <linker-type>sun to the using gcc options in user-config.jam. Mine looks like this. using gcc : 3.4.6 : /usr/local/bin/g++ : <cflags>"-mcpu=v9 -m64" <cxxflags>"-mcpu=v9 -m64" <linkflags>"-mcpu=v9 -m64" <linker-type>sun ; -- Noel
Oh, I tried to modify to retrieve by number, and I got a different bag of explosions.
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z"
Sent: Wednesday, June 20, 2007 4:57 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Compile failure with fairly simple use of multi-index/hashing on Solaris with CC 5.8 (boost 1.34.0)
Hello Benson,
----- Mensaje original -----
De: Benson Margulies
I've a relatively basic example of using the multi-index capability that fails to compile on Studio 11 (CC 5.8) on Sparc.
It's weird, because Sun C++ 5.8 is a supported compiler, and poses few problems AFAIK. Can you verify if you've got the same patch level as used in the regression tests? (Sun C++ 5.8 Patch 121017-03 2006/07/19) http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/OSL4- V2.html I've tried your snippet in GCC 3.4.4 and everything works fine, so the issue seems to be related to the compiler. Looks like the problem has to do with the retrieval of indices by tag, so as a workaround you can try retrieving by number, but I'd ask you to first verify the patch level thing.
I submitted it to the tracker before spotting the injunction to talk to the mailing list first [...]
In the particular case of Boost.MultiIndex, I'd rather you posted your request here and only issued a ticket if we can't solve the problem on the spot. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello Joaquin,
After a reboot and some dinner, I find that all is well with my small test case once the compiler is up to current patch level. Sadly, the original program from which I abstracted it still won't compile, but this is almost certainly a problem on my end.
The issues with the regression suite and the library/bjam build process, however, don't go away no matter what I drink.
Thanks,
Benson
-----Original Message-----
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of "JOAQUIN LOPEZ MU?Z"
Sent: Wednesday, June 20, 2007 4:57 PM
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Compile failure with fairly simple use of multi-index/hashing on Solaris with CC 5.8 (boost 1.34.0)
Hello Benson,
----- Mensaje original -----
De: Benson Margulies
I've a relatively basic example of using the multi-index capability that fails to compile on Studio 11 (CC 5.8) on Sparc.
It's weird, because Sun C++ 5.8 is a supported compiler, and poses few problems AFAIK. Can you verify if you've got the same patch level as used in the regression tests? (Sun C++ 5.8 Patch 121017-03 2006/07/19) http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/OSL4- V2.html I've tried your snippet in GCC 3.4.4 and everything works fine, so the issue seems to be related to the compiler. Looks like the problem has to do with the retrieval of indices by tag, so as a workaround you can try retrieving by number, but I'd ask you to first verify the patch level thing.
I submitted it to the tracker before spotting the injunction to talk to the mailing list first [...]
In the particular case of Boost.MultiIndex, I'd rather you posted your request here and only issued a ticket if we can't solve the problem on the spot. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Benson Margulies ha escrito:
Hello Joaquin,
After a reboot and some dinner, I find that all is well with my small test case once the compiler is up to current patch level. Sadly, the original program from which I abstracted it still won't compile, but this is almost certainly a problem on my end.
OK, glad to hear things are on their way to be solved. I'm closing the Trac ticket. Don't hesitate to come back here if the remaining problem resists.
The issues with the regression suite and the library/bjam build process, however, don't go away no matter what I drink.
I'm sorry I can't be of any help with bjam-related issues. I'd suggest you initiate a separate thread with a sensible subject line so as to attract bjam gurus' attention. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I now have my story straight with respect to the compiler versions.
With the latest compiler, I still cannot get a multi-index case to work.
The error is considerably smaller than with the old compiler. (Not much
joy there.)
I was fooled because, if I instantiate the indexed object inside a class
method, the compiler doesn't actually get around to finishing the
compilation process until link time. So I had the appearance of a
successful compile.
I'm willing to spend some time trying to find a way to work around
whatever it is in boost if the whomever last wrestled with this compiler
would give me something to start from. It would also be reassuring if
the bjam configuration problem I reported were to be patched.
+ /studio11/SUNWspro/bin/CC -c -DDEBUG -D_STL=std
-I./../rlp/utilities/include -I./../third-party-tools/boost -KPIC -mt -w
-g bloop1.cpp
"./../third-party-tools/boost/boost/multi_index/hashed_index.hpp", line
539: Error: Could not find
boost::multi_index::detail::index_base
Benson Margulies ha escrito:
I now have my story straight with respect to the compiler versions.
With the latest compiler, I still cannot get a multi-index case to work.
The error is considerably smaller than with the old compiler. (Not much joy there.)
I was fooled because, if I instantiate the indexed object inside a class method, the compiler doesn't actually get around to finishing the compilation process until link time. So I had the appearance of a successful compile.
I'm willing to spend some time trying to find a way to work around whatever it is in boost if the whomever last wrestled with this compiler would give me something to start from. It would also be reassuring if the bjam configuration problem I reported were to be patched.
+ /studio11/SUNWspro/bin/CC -c -DDEBUG -D_STL=std -I./../rlp/utilities/include -I./../third-party-tools/boost -KPIC -mt -w -g bloop1.cpp "./../third-party-tools/boost/boost/multi_index/hashed_index.hpp", line 539: Error: Could not find boost::multi_index::detail::index_base<...>::index_base(const boost::tuples::null_type, const int) to initialize base class.
[...] Just a shot in the dark: maybe using -template=no%extdef will do? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Just a shot in the dark: maybe using -template=no%extdef will do?
That looks like it just forces the error out into the open more quickly in the member function case, based on my experiment.
Benson Margulies ha escrito:
Just a shot in the dark: maybe using -template=no%extdef will do?
That looks like it just forces the error out into the open more quickly in the member function case, based on my experiment.
Have you considered the suggestion by Zeljko Vrba on another post? "Why are you using -D_STL=std ? Try to compile with -library=stlport4 instead." Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Benson Margulies ha escrito:
Just a shot in the dark: maybe using -template=no%extdef will do?
That looks like it just forces the error out into the open more quickly in the member function case, based on my experiment.
Have you considered the suggestion by Zeljko Vrba on another post?
"Why are you using -D_STL=std ? Try to compile with -library=stlport4 instead."
I missed that. The -D_STL=std has to do with our use of STLPort on other platforms than Sun CC. We prefer STLport 5 as our stock STL, but we can't have it on Solaris. I can remove it from the command line with no effect. I will try the -library=stlport4, but I fear that it will blow up some of our other code that depends on a more complete STL than STLport4.
Have you considered the suggestion by Zeljko Vrba on another post?
"Why are you using -D_STL=std ? Try to compile with -library=stlport4 instead."
[BIM] -library=stlport4 eliminates the error. Sadly, we are trying to add boost to a very large body of code that is not compiled with -library=stlport4, and we cannot make that change quickly or perhaps at all. Removing the -D_STL=std has no effect, as I expected, one way or the other. I don't know about you, but the error I'm seeing ('Could not find <some complex multi_index PT>') doesn't make a lot of intuitive sense as being sensitive to the question of which STL we are using. [BIM] Zeljko, do you know anything about this that might suggest a line of patching of the boost code to compensate for what's different between the two?
On Thu, Jun 21, 2007 at 12:49:27PM -0400, Benson Margulies wrote:
Have you considered the suggestion by Zeljko Vrba on another post?
"Why are you using -D_STL=std ? Try to compile with -library=stlport4 instead."
[BIM] -library=stlport4 eliminates the error. Sadly, we are trying to add boost to a very large body of code that is not compiled with -library=stlport4, and we cannot make that change quickly or perhaps at all. Removing the -D_STL=std has no effect, as I expected, one way or the other. I don't know about you, but the error I'm seeing ('Could not find <some complex multi_index PT>') doesn't make a lot of intuitive sense as being sensitive to the question of which STL we are using.
[BIM] Zeljko, do you know anything about this that might suggest a line of patching of the boost code to compensate for what's different between the two?
As far as I remember from Sun's manuals, I'm afraid that there is no line of patching. Sun's default STL (without -library=stlport4 switch) is incomplete. Sun will not and cannot make it complete because it would break backward compatibility with existing (object and source) code. Mixing code compiled with different STL versions (Sun's and STLport) will most likely have disastrous consequences. If you have the source to all existing code, your best bet would be to try to recompile it with stlport4 and see what happens. I can only give you further pointers where you might be able to dig out something by yourself: http://developers.sun.com/sunstudio/compilers_index.html (Chapters 12 and 13 in Part III "Libraries") http://blogs.sun.com/sga/ http://blogs.sun.com/x86be/
On Thu, Jun 21, 2007 at 08:26:28AM -0400, Benson Margulies wrote:
+ /studio11/SUNWspro/bin/CC -c -DDEBUG -D_STL=std -I./../rlp/utilities/include -I./../third-party-tools/boost -KPIC -mt -w -g bloop1.cpp
Why are you using -D_STL=std ? Try to compile with -library=stlport4 instead.
participants (5)
-
"JOAQUIN LOPEZ MU?Z"
-
Benson Margulies
-
Joaquín Mª López Muñoz
-
K. Noel Belcourt
-
Zeljko Vrba