| lenovo 回复于：2004-04-27 20:01:53
|
呵呵，给你加原创精华，
以后多多发表原创文章。
|
| whyglinux 回复于：2004-04-27 20:11:35
|
谢谢！一起努力吧。
|
| THEBEST 回复于：2004-04-27 20:19:11
|
只可惜GCC还不支持模板的分离编译模式.
把GCC3.4的新特性也帖上来就好了.:)
佩服whyglinux 兄.:)
|
| THEBEST 回复于：2004-04-27 20:23:21
|
稳定吗?
|
| whyglinux 回复于：2004-04-27 20:47:26
|
应该是吧。因为它是正式发行的版本（Released Version）。
|
| li2002 回复于：2004-04-28 08:15:48
|
蛮细的，不错
|
| kofd 回复于：2004-04-28 10:07:09
|
多谢了！
|
| mirnshi 回复于：2004-04-28 12:31:50
|
[quote:a7c69254b2="whyglinux"]]
例如，如果想将GCC 3.4.0安装到/usr/local/gcc-3.4.0目录下，则${destdir}就表示这个路径。
在我的机器上，我是这样配置的：
% ../gcc-3.4.0/configure --prefix=/usr/local/gcc-3.4.0 --enable-threads=..........[/quote:a7c69254b2]
how about this:
[url]http://www.freecode.com.cn/forum/viewtopic.php?t=16[/url]
|
| mirnshi 回复于：2004-04-28 12:33:05
|
用gcc编译时，建议使用静态连接，这样就不用跟着gcc的动态库了
|
| daixi 回复于：2004-04-28 12:36:06
|
支持一下。。。s
回去我也试试。
|
| qinjian1981 回复于：2004-04-28 14:17:06
|
是不是安装的时间太长了哦
|
| quil 回复于：2004-04-28 20:26:27
|
好像记得从哪个版本开始gcc不支持sco了。是不是这样啊
|
| THEBEST 回复于：2004-04-28 22:37:51
|
有没有rpm包?
我编译时出错了.
我是LINUX AS3
我参数和你的一样的有关系吗?
|
| dragondk 回复于：2004-04-29 00:50:04
|
编译GCC/G++ 好象是用make bootstrap吧。
|
| THEBEST 回复于：2004-04-29 07:52:56
|
有谁做一个RPM包出来然后可以指定安装位置就好了....:)
|
| wangyb 回复于：2004-04-29 16:17:21
|
太好了
以前都使用编译好的 现在可以使用源码安装了
|
| swingcoder 回复于：2004-04-29 18:16:27
|
能不能跟其它类型的编译器比较下呢???
如intel的
|
| whyglinux 回复于：2004-04-29 18:35:59
|
已经有人对 Intel C++ 和 GNU g++ 做了比较，有兴趣的话看这儿：
http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
|
| knightwolf 回复于：2004-05-02 13:35:55
|
# make bootstrap
cc -c -g -DHAVE_CONFIG_H -I. -I../../intl ../../intl/localealias.c
"../../intl/localealias.c", line 164: error: undefined symbol: LOCALE_ALIAS_PATH
"../../intl/localealias.c", line 164: warning: improper pointer/integer co
mbination: op "="
*** Error code 1 (bu21)
*** Error code 1 (bu21)
这怎么解决，LOCALE_ALIAS_PATH怎声明？？？？？？
|
| whyglinux 回复于：2004-05-02 14:25:18
|
不知道你的 os、你使用的cc以及你在安装GCC的过程中是怎样做的等任何信息，所以我想很难有人能够帮助你。以后要注意提供足够详细的信息，这才有助于问题的解决。
我只在Linux下用gcc编译器安装过 GCC 2.3.0。对于其它OS和使用其它的编译器，我没有这样的环境和经验，有问题的话也不知道如何解决。如果是这样，你可以用 google 等搜索，看网上有没有相关的解决方案。
|
| hsgzr 回复于：2004-05-02 18:38:46
|
谢谢
|
| honker 回复于：2004-05-08 17:41:56
|
很详细，谢谢。
|
| LX20010 回复于：2004-05-10 17:25:48
|
respecting......
|
| THEBEST 回复于：2004-05-10 23:20:28
|
[code:1:4e31c16ba4]GCC 3.4 Release Series
Changes, New Features, and Fixes[/code:1:4e31c16ba4]
[quote:4e31c16ba4]http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus[/quote:4e31c16ba4]
[code:1:4e31c16ba4]C/Objective-C/C++
* Precompiled headers are now supported. Precompiled headers can dramatically speed up compilation of some projects. There are some known defects in the current precompiled header implementation that will result in compiler crashes in relatively rare situations. Therefore, precompiled headers should be considered a "technology preview" in this release. Read the manual for details about how to use precompiled headers.
* File handling in the preprocessor has been rewritten. GCC no longer gets confused by symlinks and hardlinks, and now has a correct implementation of #import and #pragma once. These two directives have therefore been un-deprecated.
* The undocumented extension that allowed C programs to have a label at the end of a compound statement, which has been deprecated since GCC 3.0, has been removed.
* The cast-as-lvalue extension has been removed for C++ and deprecated for C and Objective-C. In particular, code like this:
int i;
(char) i = 5;
or this:
char *p;
((int *) p)++;
is no longer accepted for C++ and will not be accepted for C and Objective-C in a future version.
* The conditional-expression-as-lvalue extension has been deprecated for C and Objective-C. In particular, code like this:
int a, b, c;
(a ? b : c) = 2;
will not be accepted for C and Objective-C in a future version.
* The compound-expression-as-lvalue extension has been deprecated for C and Objective-C. In particular, code like this:
int a, b;
(a, b) = 2;
will not be accepted for C and Objective-C in a future version. A possible non-intrusive workaround is the following:
(*(a, &b)) = 2;
* Several built-in functions such as __builtin_popcount for counting bits, finding the highest and lowest bit in a word, and parity have been added.
* The -fwritable-strings option has been deprecated and will be removed.
* Many C math library functions are now recognized as built-ins and optimized.
* The C, C++, and Objective-C compilers can now handle source files written in any character encoding supported by the host C library. The default input character set is taken from the current locale, and may be overridden with the -finput-charset command line option. In the future we will add support for inline encoding markers.
C++
* G++ is now much closer to full conformance to the ISO/ANSI C++ standard. This means, among other things, that a lot of invalid constructs which used to be accepted in previous versions will now be rejected. It is very likely that existing C++ code will need to be fixed. This document lists some of the most common issues.
* A hand-written recursive-descent C++ parser has replaced the YACC-derived C++ parser from previous GCC releases. The new parser contains much improved infrastructure needed for better parsing of C++ source codes, handling of extensions, and clean separation (where possible) between proper semantics analysis and parsing. The new parser fixes many bugs that were found in the old parser.
* You must now use the typename and template keywords to disambiguate dependent names, as required by the C++ standard.
struct K {
typedef int mytype_t;
};
template <class T1> struct A {
template <class T2> struct B {
void callme(void);
};
template <int N> void bar(void)
{
// Use 'typename' to tell the parser that T1::mytype_t names
// a type. This is needed because the name is dependent (in
// this case, on template parameter T1).
typename T1::mytype_t x;
x = 0;
}
};
template <class T> void template_func(void)
{
// Use 'template' to prefix member templates within
// dependent types (a has type A<T>, which depends on
// the template parameter T).
A<T> a;
a.template bar<0>();
// Use 'template' to tell the parser that B is a nested
// template class (dependent on template parameter T), and
// 'typename' because the whole A<T>::B<int> is
// the name of a type (again, dependent).
typename A<T>::template B<int> b;
b.callme();
}
void non_template_func(void)
{
// Outside of any template class or function, no names can be
// dependent, so the use of the keyword 'typename' and 'template'
// is not needed (and actually forbidden).
A<K> a;
a.bar<0>();
A<K>::B<float> b;
b.callme();
}
* In a template definition, unqualified names will no longer find members of a dependent base. For example,
template <typename T> struct B {
int m;
int n;
int f ();
int g ();
};
int n;
int g ();
template <typename T> struct C : B<T> {
void g ()
{
m = 0; // error
f (); // error
n = 0; // ::n is modified
g (); // ::g is called
}
};
You must make the names dependent by prefixing them with this->. Here is the corrected definition of C<T>::g,
template <typename T> void C<T>::g ()
{
this->m = 0;
this->f ();
this->n = 0
this->g ();
}
* In templates, all non-dependent names are now looked up and bound at definition time (while parsing the code), instead of later when the template is instantiated. For instance:
void foo(int);
template <int> struct A {
static void bar(void){
foo('a');
}
};
void foo(char);
int main()
{
A<0>::bar(); // Calls foo(int), used to call foo(char).
}
* In an explicit instantiation of a class template, you must use class or struct before the template-id:
template <int N>
class A {};
template A<0>; // error, not accepted anymore
template class A<0>; // OK
* The "named return value" and "implicit typename" extensions have been removed.
* Default arguments in function types have been deprecated and will be removed.
* ARM-style name-injection of friend declarations has been deprecated and will be removed. For example: struct S { friend void f(); }; void g() { f(); } will not be accepted by future versions of G++; instead a declaration of "f" will need to be present outside of the scope of "S".
* Covariant returns are implemented for all but varadic functions that require an adjustment.
* When -pedantic is used, G++ now issues errors about spurious semicolons. For example,
namespace N {}; // Invalid semicolon.
void f() {}; // Invalid semicolon.
* G++ no longer accepts attributes for a declarator after the initializer associated with that declarator. For example,
X x(1) __attribute__((...));
is no longer accepted. Instead, use:
X x __attribute__((...)) (1);
* Inside the scope of a template class, the name of the class itself can be treated as either a class or a template. So GCC used to accept the class name as argument of type template, and template template parameter. However this is not C++ standard compliant. Now the name is not treated as a valid template template argument unless you qualify the name by its scope. For example, the code below no longer compiles.
template <template <class> class TT> class X {};
template <class T> class Y {
X<Y> x; // Invalid, Y is always a type template parameter.
};
The valid code for the above example is
X< ::Y> x; // Valid.
(Notice the space between < and : to prevent GCC to interpret this as a digraph for [.)
* Friend declarations that refer to template specializations are rejected if the template has not already been declared. For example,
template <typename T>
class C {
friend void f<> (C&);
};
is rejected. You must first declare f as a template,
template <typename T>
void f(T);
* In case of friend declarations, every name used in the friend declaration must be accessible at the point of that declaration. Previous versions of G++ used to be less strict about this and allowed friend declarations for private class members, for example. See the ISO C++ Standard Committee's defect report #209 for details.
* Declaration of member functions of class templates as friends are supported. For example,
template <typename T> struct A {
void f();
};
class C {
template <typename T> friend void A<T>::f();
};
* You must use template <> to introduce template specializations, as required by the standard. For example,
template <typename T>
struct S;
struct S<int> { };
is rejected. You must write,
template <> struct S<int> {};
* G++ used to accept code like this,
struct S {
int h();
void f(int i = g());
int g(int i = h());
};
This behavior is not mandated by the standard. Now G++ issues an error about this code. To avoid the error, you must move the declaration of g before the declaration of f. The default arguments for g must be visible at the point where it is called.
* The C++ ABI Section 3.3.3 specifications for the array construction routines __cxa_vec_new2 and __cxa_vec_new3 were changed to return NULL when the allocator argument returns NULL. These changes are incorporated into the libstdc++ runtime library.
* Using a name introduced by a typedef in a friend declaration or in an explicit instantiation is now rejected, as specified by the ISO C++ standard.
class A;
typedef A B;
class C {
friend class B; // error, no typedef name here
friend B; // error, friend always needs class/struct/enum
friend class A; // OK
};
template <int> class Q {};
typedef Q<0> R;
template class R; // error, no typedef name here
template class Q<0>; // OK
* When allocating an array with a new expression, GCC used to allow parentheses around the type name. This is actually ill-formed and it is now rejected:
int* a = new (int)[10]; // error, not accepted anymore
int* a = new int[10]; // OK
* When binding an rvalue of class type to a reference, the copy constructor of the class must be accessible. For instance, consider the following code:
class A
{
public:
A();
private:
A(const A&); // private copy ctor
};
A makeA(void);
void foo(const A&);
void bar(void)
{
foo(A()); // error, copy ctor is not accessible
foo(makeA()); // error, copy ctor is not accessible
A a1;
foo(a1); // OK, a1 is a lvalue
}
This might be surprising at first sight, especially since most popular compilers do not correctly implement this rule (further details).
Runtime Library (libstdc++)
* Optimization work:
o Streamlined streambuf, filebuf, separate synched with C Standard I/O streambuf.
o All formatted I/O now uses cached locale information.
o STL optimizations (memory/speed for list, red-black trees as used by sets and maps).
o More use of GCC builtins.
o String optimizations (avoid contention on increment/decrement-and-test of the reference count in the empty-string object, constructor from input_iterators speedup).
* Static linkage size reductions.
* Large File Support (files larger than 2 GB on 32-bit systems).
* Wide character and variable encoding filebuf work (UTF-8, Unicode).
* Generic character traits.
* Also support wchar_t specializations on Mac OS 10.3.x, FreeBSD 5.x, Solaris 2.7 and above, AIX 5.x, Irix 6.5.
* The allocator class is now standard-conformant, and two additional extension allocators have been added, mt_alloc and bitmap_allocator.
* PCH support: -include bits/stdc++.h (2x compile speedup).
* Rewrote __cxa_demangle with support for C++ style allocators.
* New debug modes for STL containers and iterators.
* Testsuite rewrite: five times as many tests, plus increasingly sophisticated tests, including I/O, MT, multi-locale, wide and narrow characters.
* Use current versions of GNU "autotools" for build/configuration.
Objective-C
* The Objective-C front end has been updated to include the numerous bug fixes and enhancements previously available only in Apple's version of GCC. These include:
o Structured exception (@try... @catch... @finally, @throw) and synchronization (@synchronized) support. These are accessible via the -fobjc-exceptions switch; as of this writing, they may only be used in conjunction with -fnext-runtime on Mac OS X 10.3 and later. See Options Controlling Objective-C Dialect for more information.
o An overhaul of @encode logic. The C99 _Bool and C++ bool type may now be encoded as 'B'. In addition, the back-end/codegen dependencies have been removed.
o An overhaul of message dispatch construction, ensuring that the various receiver types (and casts thereof) are handled properly, and that correct diagnostics are issued.
o Support for "Zero-Link" (-fzero-link) and "Fix-and-Continue" (-freplace-objc-classes) debugging modes, currently available on Mac OS X 10.3 and later. See Options Controlling Objective-C Dialect for more information.
o Access to optimized runtime entry points (-fno-nil-receivers ) on the assumption that message receivers are never nil. This is currently available on Mac OS X 10.3 and later. See Options Controlling Objective-C Dialect for more information.
[/code:1:4e31c16ba4]
|
| tonggl150 回复于：2004-05-12 13:35:00
|
GCC高手：
现有SDW原程序，因为我没有GCC软件，敬请哪位高手帮忙编译一下，以便本人读懂SDW类文件。先谢谢了。
|
| mxin 回复于：2004-05-25 13:45:48
|
p690,AIX 5.2,V C++6.0,安装 gcc-3.3.2时
make bootstrap报错如下
cc -c -DIN_GCC -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../../../gcc/intl -I../../../gcc -I../../../gcc/config -I../../../gcc/../include -g ../../../gcc/intl/plural.c -o plural.o
"plural.y", line 264.1: 1506-343 (S) Redeclaration of __gettextlex differs from previous declaration on line 73 of "plural.y".
"plural.y", line 264.1: 1506-381 (I) The type "const unsigned char**" of parameter 2 in the prototype declaration is not compatible with the corresponding parameter type "unsigned char**" in the nonprototype declaration.
cc: 1501-230 Internal compiler error; please contact your Service Representative
make: 1254-004 The error code from the last command is 41.
Stop.
make: 1254-004 The error code from the last command is 2.
|
| whyglinux 回复于：2004-05-25 14:48:19
|
从网上搜到有两种解决方式，可以试试。
1. 安装编译时用 GCC编译器而不用 cc
或者
2. 用 cc 编译，但是 configure 的时候加 --disable-nls
|
