the struggle to create a 64-bit gcc on Solaris 10
I have been trying repeatedly and in incrementally more rewarding stages towards building a purely 64-bit GCC compiler on Solaris 10 sparc. I have no need for the 32-bit libs at all and my entire toolchain is 64-bit only. There are no 32-bit libs in /usr/local/lib nor do there need to be. Thus far things have gone well with this approach but I have been using the Oraccle Studio compilers to get to this point. Now I need to get to GCC and then never look back. This has been a struggle as I have needed to hand edit Makefiles over and over and regardless of what I do I end up stopping within stage one of the 3-stage bootstrap with a problem dealing with GMP libs. I have the sources to gmp, mpfr and mpc extracted in the gcc-4.7.2 source directory. No problem there. I have hand edited Makefiles after configure to ensure that ABI=64 in every Makefile that needs it. Thus : $ find . -type f -name Makefile | xargs grep "^ABI" ./gmp/mpq/Makefile:ABI = 64 ./gmp/tune/Makefile:ABI = 64 ./gmp/scanf/Makefile:ABI = 64 ./gmp/mpf/Makefile:ABI = 64 ./gmp/printf/Makefile:ABI = 64 ./gmp/mpn/Makefile:ABI = 64 ./gmp/mpz/Makefile:ABI = 64 ./gmp/cxx/Makefile:ABI = 64 ./gmp/Makefile:ABI = 64 ./gmp/tests/devel/Makefile:ABI = 64 ./gmp/tests/Makefile:ABI = 64 ./gmp/tests/misc/Makefile:ABI = 64 ./gmp/tests/rand/Makefile:ABI = 64 ./gmp/tests/cxx/Makefile:ABI = 64 ./gmp/tests/mpn/Makefile:ABI = 64 ./gmp/tests/mpz/Makefile:ABI = 64 ./gmp/tests/mpf/Makefile:ABI = 64 ./gmp/tests/mpq/Makefile:ABI = 64 ./gmp/tests/mpbsd/Makefile:ABI = 64 ./gmp/mpbsd/Makefile:ABI = 64 ./gmp/demos/calc/Makefile:ABI = 64 ./gmp/demos/Makefile:ABI = 64 ./gmp/demos/expr/Makefile:ABI = 64 ./gmp/doc/Makefile:ABI = 64 After doing this and running gmake I eventually get stopped and see these guys : $ find . -type f | xargs file | grep ELF | grep -v 64 ./gmp/gen-bases: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-psqr: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-fac_ui: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-fib: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped ./gmp/gen-trialdivtab: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped All of which were somehow compiled as 32-bit binaries. No idea where they are coming from and why they did not respect the CFLAGS of "-m64 -mptr64 " which I have hand edited into Makefiles everywhere. As an example : $ diff ./Makefile.backup Makefile 414c414 < STAGE_CFLAGS = $(BOOT_CFLAGS) --- > STAGE_CFLAGS = -m64 -mptr64 -I/usr/local/include:/opt/csw/gcc4/include > $(BOOT_CFLAGS) 417c417 < POSTSTAGE1_CONFIGURE_FLAGS = --enable-build-with-cxx --- > POSTSTAGE1_CONFIGURE_FLAGS = -m64 -mptr64 --enable-build-with-cxx 421,422c421,422 < STAGE1_CFLAGS = $(STAGE_CFLAGS) < STAGE1_CXXFLAGS = $(CXXFLAGS) --- > STAGE1_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE1_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 424,425c424,425 < STAGE1_CXXFLAGS = $(STAGE1_CFLAGS) < STAGE1_TFLAGS = $(STAGE_TFLAGS) --- > STAGE1_CXXFLAGS = -m64 -mptr64 $(STAGE1_CFLAGS) > STAGE1_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 432,433c432,433 < STAGE2_CFLAGS = $(STAGE_CFLAGS) < STAGE2_CXXFLAGS = $(CXXFLAGS) --- > STAGE2_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE2_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 435c435 < STAGE2_CXXFLAGS = $(STAGE2_CFLAGS) --- > STAGE2_CXXFLAGS = -m64 -mptr64 $(STAGE2_CFLAGS) 443,444c443,444 < STAGE3_CFLAGS = $(STAGE_CFLAGS) < STAGE3_CXXFLAGS = $(CXXFLAGS) --- > STAGE3_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE3_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 446,447c446,447 < STAGE3_CXXFLAGS = $(STAGE3_CFLAGS) < STAGE3_TFLAGS = $(STAGE_TFLAGS) --- > STAGE3_CXXFLAGS = -m64 -mptr64 $(STAGE3_CFLAGS) > STAGE3_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 454,455c454,455 < STAGE4_CFLAGS = $(STAGE_CFLAGS) < STAGE4_CXXFLAGS = $(CXXFLAGS) --- > STAGE4_CFLAGS = -m64 -mptr64 $(STAGE_CFLAGS) > STAGE4_CXXFLAGS = -m64 -mptr64 $(CXXFLAGS) 457,458c457,458 < STAGE4_CXXFLAGS = $(STAGE4_CFLAGS) < STAGE4_TFLAGS = $(STAGE_TFLAGS) --- > STAGE4_CXXFLAGS = -m64 -mptr64 $(STAGE4_CFLAGS) > STAGE4_TFLAGS = -m64 -mptr64 $(STAGE_TFLAGS) 493c493 < STAGE1_CFLAGS = -g -fkeep-inline-functions --- > STAGE1_CFLAGS = -m64 -mptr64 -g -fkeep-inline-functions A bit messy I know. However this is pass 1 with hopes that by the third time I do this it will be a fine art. Any pointers at all as to the error of my ways ? Dennis ps: I am using gcc 4.5.1 to perform the bootstrap and this release has been very well tested : $ which gcc /opt/csw/gcc4/bin/gcc $ $ $CC --version gcc (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
Howdy,
The following piece of code:
=== snip ===
#include
struct warnme
{
bool member_;
warnme(bool member) : member_(member_) {}
};
int main()
{
warnme wm(true);
std::cout << wm.member_ << std::endl;
return 0;
}
=== end snip ===
when compiled with g++ 4.7, gives me no warnings - even with
-Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
report a bug, but:
- I need to login to report a bug, and I have to create an account. Is
this a way to reduce the number of bugs GCC gets?
- I searched for uninitialized and got 156 bugs. How easy would it be
for one to check if a bug is a duplicate? Shouldn't we have some kind
of code search for bug-related snippets?
best,
--
Bruno Nery
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
GCC has the -Winit-self warning.
David
On Fri, Nov 9, 2012 at 12:18 PM, Bruno Nery wrote:
> Howdy,
>
> The following piece of code:
>
> === snip ===
> #include
>
> struct warnme
> {
> bool member_;
> warnme(bool member) : member_(member_) {}
> };
>
> int main()
> {
> warnme wm(true);
> std::cout << wm.member_ << std::endl;
> return 0;
> }
> === end snip ===
>
> when compiled with g++ 4.7, gives me no warnings - even with
> -Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
> report a bug, but:
>
> - I need to login to report a bug, and I have to create an account. Is
> this a way to reduce the number of bugs GCC gets?
> - I searched for uninitialized and got 156 bugs. How easy would it be
> for one to check if a bug is a duplicate? Shouldn't we have some kind
> of code search for bug-related snippets?
>
> best,
>
> --
> Bruno Nery
What is wrong in this code?
Dear All,
I have found a build problem with an application which I have reduced to the
following test case:
$ cat foomain.cc
//
// g++ foomain.cc foo01.cc foo02.cc -o foo.out
//
// g++ -c foomain.cc
// g++ -c foo01.cc
// g++ -c foo02.cc
//
// g++ foomain.o foo01.o foo02.o -o foo.out
//
int main()
{
return 0;
}
$ cat foo01.cc
#include "foo.hh"
MYCLASS_INSTANTIATE_TYPES
$ cat foo02.cc
#include "foo.hh"
MYCLASS_INSTANTIATE_TYPES
$ cat foo.hh
#ifndef ONCE_FOO_H_
#define ONCE_FOO_H_
template
class MyClassBase
{
public:
class ClassWrapper;
MyClassBase();
~MyClassBase();
};
template
class MyClassBase::ClassWrapper
{
friend class MyClassBase;
public:
ClassWrapper() {}
};
#define MYCLASS_INSTANTIATE(g) g(int)
#define MYCLASS_INSTANTIATE_BASE(type) \
template class MyClassBase;
#define MYCLASS_INSTANTIATE_TYPES \
MYCLASS_INSTANTIATE(MYCLASS_INSTANTIATE_BASE)
#endif
This test should be build as
g++ foomain.cc foo01.cc foo02.cc -o foo.out
or
g++ -c foomain.cc
g++ -c foo01.cc
g++ -c foo02.cc
g++ foomain.o foo01.o foo02.o -o foo.out
Now what happens is this:
Building on *** MAC OSX *** with gcc45, gcc46, gcc47 installed by means of
MacPorts, fails as
$ g++ foomain.o foo01.o foo02.o -o foo.out
duplicate symbol MyClassBase::ClassWrapper::ClassWrapper() in:
foo01.o
foo02.o
duplicate symbol MyClassBase::ClassWrapper::ClassWrapper() in:
foo01.o
foo02.o
ld: 2 duplicate symbols for architecture x86_64
collect2: error: ld returned 1 exit status
instead it builds (on MAC OSX) using clang++,
$ clang++ foomain.o foo01.o foo02.o -o foo.out
$
It also builds on Cygwin with gcc-4.5.3 and gcc-4.8 snapshot.
It builds on GNU/Linux (K)Ubuntu with gcc-4.6.3
So the question is: does the above code violate some C++ standard?
Maybe is it wrong the way as the inline (the class ClassWrapper constructor in
the above code) functions are used?
TIA,
Angelo.
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
Bruno Nery writes:
| Howdy,
>
| The following piece of code:
>
| === snip ===
| #include
>
| struct warnme
| {
| bool member_;
| warnme(bool member) : member_(member_) {}
| };
>
| int main()
| {
| warnme wm(true);
| std::cout << wm.member_ << std::endl;
| return 0;
| }
| === end snip ===
>
| when compiled with g++ 4.7, gives me no warnings - even with
| -Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
| report a bug, but:
g++ -Wall -Wextra -O uninit.cpp
uninit.cpp:6:5: warning: unused parameter ‘member’ [-Wunused-parameter]
uninit.cpp: In function ‘int main()’:
uninit.cpp:12:21: warning: ‘wm.warnme::member_’ is used uninitialized in
this function [-Wuninitialized]
Some checking is only done if optimization is on.
g++ --version
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
--
Lgb
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
Hello,
On Fri, 2012-11-09 at 12:18 -0800, Bruno Nery wrote:
> Howdy,
>
> The following piece of code:
>
> === snip ===
> #include
>
> struct warnme
> {
> bool member_;
> warnme(bool member) : member_(member_) {}
> };
>
> int main()
> {
> warnme wm(true);
> std::cout << wm.member_ << std::endl;
> return 0;
> }
> === end snip ===
>
> when compiled with g++ 4.7, gives me no warnings - even with
> -Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
> report a bug, but:
>
> - I need to login to report a bug, and I have to create an account. Is
> this a way to reduce the number of bugs GCC gets?
This issue has been raised just recently on the gcc-help mailing list.
See the thread:
http://gcc.gnu.org/ml/gcc-help/2012-10/threads.html#00061
> - I searched for uninitialized and got 156 bugs. How easy would it be
> for one to check if a bug is a duplicate? Shouldn't we have some kind
> of code search for bug-related snippets?
I've just searched for "uninitialized missing" and got 22 bugs, some of
them seem to look related to yours, although I haven't checked/compared
the details. In the worst case you can just file the bug and it will be
marked as duplicate eventually (if it is one).
Cheers,
Oleg
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
-Winit-self doesn't report it either (at least in g++ 4.7).
--
Bruno Nery
On Fri, Nov 9, 2012 at 12:32 PM, Xinliang David Li wrote:
> GCC has the -Winit-self warning.
>
> David
>
> On Fri, Nov 9, 2012 at 12:18 PM, Bruno Nery wrote:
>> Howdy,
>>
>> The following piece of code:
>>
>> === snip ===
>> #include
>>
>> struct warnme
>> {
>> bool member_;
>> warnme(bool member) : member_(member_) {}
>> };
>>
>> int main()
>> {
>> warnme wm(true);
>> std::cout << wm.member_ << std::endl;
>> return 0;
>> }
>> === end snip ===
>>
>> when compiled with g++ 4.7, gives me no warnings - even with
>> -Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
>> report a bug, but:
>>
>> - I need to login to report a bug, and I have to create an account. Is
>> this a way to reduce the number of bugs GCC gets?
>> - I searched for uninitialized and got 156 bugs. How easy would it be
>> for one to check if a bug is a duplicate? Shouldn't we have some kind
>> of code search for bug-related snippets?
>>
>> best,
>>
>> --
>> Bruno Nery
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
Twenty two might be a more manageable number, but still... why do we
need an account to report a bug?
--
Bruno Nery
On Fri, Nov 9, 2012 at 12:36 PM, Oleg Endo wrote:
> Hello,
>
> On Fri, 2012-11-09 at 12:18 -0800, Bruno Nery wrote:
>> Howdy,
>>
>> The following piece of code:
>>
>> === snip ===
>> #include
>>
>> struct warnme
>> {
>> bool member_;
>> warnme(bool member) : member_(member_) {}
>> };
>>
>> int main()
>> {
>> warnme wm(true);
>> std::cout << wm.member_ << std::endl;
>> return 0;
>> }
>> === end snip ===
>>
>> when compiled with g++ 4.7, gives me no warnings - even with
>> -Wuninitialized (clang++ 3.1 is fine, by the way). I then decided to
>> report a bug, but:
>>
>> - I need to login to report a bug, and I have to create an account. Is
>> this a way to reduce the number of bugs GCC gets?
>
> This issue has been raised just recently on the gcc-help mailing list.
> See the thread:
> http://gcc.gnu.org/ml/gcc-help/2012-10/threads.html#00061
>
>> - I searched for uninitialized and got 156 bugs. How easy would it be
>> for one to check if a bug is a duplicate? Shouldn't we have some kind
>> of code search for bug-related snippets?
>
> I've just searched for "uninitialized missing" and got 22 bugs, some of
> them seem to look related to yours, although I haven't checked/compared
> the details. In the worst case you can just file the bug and it will be
> marked as duplicate eventually (if it is one).
>
> Cheers,
> Oleg
>
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
On Fri, 2012-11-09 at 13:22 -0800, Bruno Nery wrote: > Twenty two might be a more manageable number, but still... why do we > need an account to report a bug? This issue has been raised just recently on the gcc-help mailing list. See the thread: http://gcc.gnu.org/ml/gcc-help/2012-10/threads.html#00061 The answer to your question is in the first reply by Ian Lance Taylor. Cheers, Oleg
Re: [rant?] g++ bug (missing uninitialized warning), bug reporting, bug searching
A good reason, stopping spammers - but why not allow a generic (e.g. Google/Facebook/StackOverflow)/OpenID login? As the original poster of that thread, I don't like to have to keep track of accounts (and passwords) only for posting one bug. Also, CAPTCHAs might be an option - or changing to a bug tracking system without the pitfalls of Bugzilla. best, -- Bruno Nery On Fri, Nov 9, 2012 at 1:27 PM, Oleg Endo wrote: > On Fri, 2012-11-09 at 13:22 -0800, Bruno Nery wrote: >> Twenty two might be a more manageable number, but still... why do we >> need an account to report a bug? > > This issue has been raised just recently on the gcc-help mailing list. > See the thread: > http://gcc.gnu.org/ml/gcc-help/2012-10/threads.html#00061 > > The answer to your question is in the first reply by Ian Lance Taylor. > > Cheers, > Oleg >
Re: the struggle to create a 64-bit gcc on Solaris 10
> Any pointers at all as to the error of my ways ? http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 -- Eric Botcazou
Re: the struggle to create a 64-bit gcc on Solaris 10
> > Any pointers at all as to the error of my ways ? > > http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 nope. Been there .. done that and that fails badly .. in fact worse than before : Configure .. look good but lies : $ ../gcc-4.7.2/configure --build=sparc64-sun-solaris2.10 --target=sparc64-sun-solaris2.10 \ > --with-as=/usr/ccs/bin/as --without-gnu-ld \ > --with-ld=/usr/ccs/bin/ld --disable-multilib --enable-nls \ > --enable-threads=posix --prefix=/usr/local/gcc4 --enable-shared \ > --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \ > --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \ > --libexecdir=/usr/local/gcc4/lib > --with-gxx-include-dir=/usr/local/gcc4/include \ > --with-pkgversion=Blastwave.org\ Inc.\ Fri\ Nov\ \ 9\ 21\:55\:41\ UTC\ 2012 \ > --with-bugurl=http\:\/\/www.blastwave.org\/support \ > --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap checking build system type... sparc64-sun-solaris2.10 checking host system type... sparc64-sun-solaris2.10 checking target system type... sparc64-sun-solaris2.10 checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /usr/local/bin/gsed checking for gawk... gawk checking for libitm support... yes checking for gcc... /opt/csw/gcc4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/csw/gcc4/bin/gcc accepts -g... yes checking for /opt/csw/gcc4/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /opt/csw/gcc4/bin/g++ accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no The following languages will be built: c,ada,c++,fortran,lto,objc *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... checking for bison... bison -y checking for bison... bison checking for gm4... /usr/local/bin/gm4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... (cached) /usr/ccs/bin/ar checking for as... (cached) /usr/ccs/bin/as checking for dlltool... no checking for ld... (cached) /usr/ccs/bin/ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... no checking for objdump... no checking for readelf... no checking for sparc64-sun-solaris2.10-cc... no checking for cc... cc checking for sparc64-sun-solaris2.10-c++... no checking for c++... c++ checking for sparc64-sun-solaris2.10-gcc... no checking for gcc... gcc checking for sparc64-sun-solaris2.10-gcj... no checking for gcj... no checking for sparc64-sun-solaris2.10-gfortran... no checking for gfortran... gfortran checking for sparc64-sun-solaris2.10-gccgo... no checking for gccgo... no checking for ar... no checking for sparc64-sun-solaris2.10-ar... no checking for ar... ar checking for as... no checking for sparc64-sun-solaris2.10-as... no checking for as... as checking for dlltool... no checking for sparc64-sun-solaris2.10-dlltool... no checking for dlltool... no checking for ld... no checking for sparc64-sun-solaris2.10-ld... no checking for ld... ld checking for lipo... no checking for sparc64-sun-solaris2.10-lipo... no checking for lipo... no checking for nm... no checking for sparc64-sun-solaris2.10-nm... no checking for nm... nm checking for objdump... no checking for sparc64-sun-solaris2.10-objdump... no checking for objdump... no checking for ranlib... no checking for sparc64-sun-solaris2.10-ranlib... no checking for ranlib... ranlib checking for readelf... no checking for sparc64-sun-solaris2.10-readelf... no checking for readelf... no checking for strip... no checking for sparc64-sun-solaris2.10-strip... no checking for strip... strip checking for windres... no checking for sparc64-sun-solaris2.10-windres... no checking for windres... no checking for windmc... no checking for sparc64-sun-solaris2.10-windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... j
gcc-4.6-20121109 is now available
Snapshot gcc-4.6-20121109 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121109/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 193380 You'll find: gcc-4.6-20121109.tar.bz2 Complete GCC MD5=b4ca7e0e22e386494350cd355db0b1ac SHA1=40239afe7363621017078df27bbf0da771964b78 Diffs from 4.6-20121102 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: the struggle to create a 64-bit gcc on Solaris 10
> nope. Been there .. done that and that fails badly .. in fact worse than > before : Yet this is the standard way and works flawlessly if done correctly... > However I am way way open to suggestion here. You need to configure everything with --build=sparc64-sun-solaris2.10 and compile everything with a 64-bit compiler, i.e. all compilers ever invoked must generate 64-bit code *by default*. This can mean setting CC and CXX to appropriate values, e.g. "gcc -m64" and "g++ -m64" or the Sun equivalent. -- Eric Botcazou
Re: the struggle to create a 64-bit gcc on Solaris 10
> > nope. Been there .. done that and that fails badly .. in fact worse > than > > before : > > Yet this is the standard way and works flawlessly if done correctly... I can not see my error here and am wondering what the issue is. > > However I am way way open to suggestion here. > > You need to configure everything with --build=sparc64-sun-solaris2.10 > and > compile everything with a 64-bit compiler, i.e. all compilers ever > invoked > must generate 64-bit code *by default*. This can mean setting CC and > CXX to > appropriate values, e.g. "gcc -m64" and "g++ -m64" or the Sun equivalent. I am using gcc and g++ here. So, in any case .. looks like I am back to square zero. Thanks for the input. dc
Re: Time for GCC 5.0? (TIC)
Il 06/11/2012 03:43, DJ Delorie ha scritto: > Ian Lance Taylor writes: >> > Also the fact that GCC is now written in C++ seems to me to be >> > deserving of a bump to 5.0. > I see no reason why an internal design change that has no user visible > effects should have any impact on the version number. Technically, requiring a C++ compiler to bootstrap is a user visible effect. Paolo
Re: What is wrong in this code?
On Fri, Nov 9, 2012 at 12:34 PM, Angelo Graziosi wrote: > > $ cat foo01.cc > #include "foo.hh" > > MYCLASS_INSTANTIATE_TYPES > > $ cat foo02.cc > #include "foo.hh" > > MYCLASS_INSTANTIATE_TYPES > > $ cat foo.hh > > #define MYCLASS_INSTANTIATE(g) g(int) > > #define MYCLASS_INSTANTIATE_BASE(type) \ > template class MyClassBase; > > #define MYCLASS_INSTANTIATE_TYPES \ > MYCLASS_INSTANTIATE(MYCLASS_INSTANTIATE_BASE) > > Now what happens is this: > > Building on *** MAC OSX *** with gcc45, gcc46, gcc47 installed by means of > MacPorts, fails as > > $ g++ foomain.o foo01.o foo02.o -o foo.out > duplicate symbol MyClassBase::ClassWrapper::ClassWrapper() in: > foo01.o > foo02.o > duplicate symbol MyClassBase::ClassWrapper::ClassWrapper() in: > foo01.o > foo02.o > ld: 2 duplicate symbols for architecture x86_64 > collect2: error: ld returned 1 exit status > > instead it builds (on MAC OSX) using clang++, This question is not appropriate for the mailing list gcc@gcc.gnu.org. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. Instantiating a template creates all the instantiations in that compilation unit. There is no reason to instantiate a template in more than one compilation unit. The implementation that GCC uses does not permit you to do that. I don't know what LLVM does. Ian
Re: Time for GCC 5.0? (TIC)
On Mon, Nov 5, 2012 at 11:21 PM, Jonathan Wakely wrote: > On 6 November 2012 09:16, Florian Weimer wrote: > > On 11/06/2012 07:06 AM, Jeff Law wrote: > > > >> I tend to agree that major version number bumps ought to be tied to > >> major user-visible changes. > > Or a new ABI for libstdc++, I guess. > Which is not on the cards for the foreseeable future. The suggested > attributes to allow old and new libstdc++ ABIs to coexist, and > dropping the "experimental" rider from C++11 mode would warrant a > major version bump IMHO. Making c99 the default for gcc would be a great candidate for this. IIUC, gcc without -std=c99 will compile for c89. And if I read the manual correctly, it's because c99 isn't finished yet. gcc 5.0 should have a complete c99.
