Severn ships gcc32 packages but no matching g++ packages.
This causes problems with packages that dont compile with 3.3 (eg: gst-plugins), and deps if they also use c++ code, because they have a mismatch with libstdc
Will bugzilla when bugzilla is working
__________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
On Wed, Jul 30, 2003 at 09:47:17AM +0100, Mike Martin wrote:
Severn ships gcc32 packages but no matching g++ packages.
This causes problems with packages that dont compile with 3.3 (eg: gst-plugins), and deps if they also use c++ code, because they have a mismatch with libstdc
It's not intended to be an entire duplicate compiler set; it's only intended for the kernel.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
--- Elliot Lee sopwith@redhat.com wrote: > On Wed, 30 Jul 2003, Mike Martin wrote:
This causes problems with packages that dont compile with 3.3
Those packages need to be fixed.
yes - I know these packages should be fixed.
BUT - it does put the user trying to compile software in a frustrating position especially when it relates to fairly important packages like gstreamer.
-- Elliot Humpty Dumpty was pushed.
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
__________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
On Thu, Jul 31, 2003 at 09:43:57AM +0100, Mike Martin wrote:
--- Elliot Lee sopwith@redhat.com wrote: > On Wed, 30 Jul 2003, Mike Martin wrote:
This causes problems with packages that dont compile with 3.3
Those packages need to be fixed.
yes - I know these packages should be fixed.
BUT - it does put the user trying to compile software in a frustrating position especially when it relates to fairly important packages like gstreamer.
The distribution has gcc32 package so you are free to use older compiler (that possibly works).
Anyway - the maintainer of gstreamer shoud fix his package and this is the only way to force him to do it.
We need better compiler all the time. We need to be able to use it in Enterprise environment (like glibc with NTPL etc). This is not possible to use 5 years old compiler with bilions of documented bugs and workarounds included to our source code.
On Thu, Jul 31, 2003 at 10:54:39AM +0200, Milan Kerslager wrote:
The distribution has gcc32 package so you are free to use older compiler (that possibly works).
Anyway - the maintainer of gstreamer shoud fix his package and this is the only way to force him to do it.
We need better compiler all the time. We need to be able to use it in Enterprise environment (like glibc with NTPL etc). This is not possible to use 5 years old compiler with bilions of documented bugs and workarounds included to our source code.
Sorry I miss the point (libstdc for gcc32).
--- Milan Kerslager milan.kerslager@pslib.cz wrote: > On Thu, Jul 31, 2003 at 09:43:57AM +0100, Mike Martin wrote:
--- Elliot Lee sopwith@redhat.com wrote: > On Wed, 30 Jul
2003,
Mike Martin wrote:
This causes problems with packages that dont compile with 3.3
Those packages need to be fixed.
yes - I know these packages should be fixed.
BUT - it does put the user trying to compile software in a frustrating position especially when it relates to fairly
important
packages like gstreamer.
The distribution has gcc32 package so you are free to use older compiler (that possibly works).
you missed what I said about c++ code being referenced - for pure c code gcc32 works
Anyway - the maintainer of gstreamer shoud fix his package and this is the only way to force him to do it.
its not only gstreamer
We need better compiler all the time. We need to be able to use it in Enterprise environment (like glibc with NTPL etc). This is not possible to use 5 years old compiler with bilions of documented bugs and workarounds included to our source code.
not talking about 5 years old compiler - I am referring to a previous point release.
previously, when RH has included a new compiler, compat packages have been included for previous version
-- Milan Kerslager E-mail: milan.kerslager@pslib.cz WWW: http://www.pslib.cz/~kerslage/
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
__________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
On Thu, Jul 31, 2003 at 10:01:20AM +0100, Mike Martin wrote:
previously, when RH has included a new compiler, compat packages have been included for previous version
But gcc 3.2.x is compatible with gcc 3.3.x (there are some corner cases but I believe gcc 3.2.x would simply ICE on them rather than generating ABI incompatible code with gcc 3.3.x).
Jakub
On Thu, 2003-07-31 at 10:43, Mike Martin wrote:
--- Elliot Lee sopwith@redhat.com wrote: > On Wed, 30 Jul 2003, Mike Martin wrote:
This causes problems with packages that dont compile with 3.3
Those packages need to be fixed.
yes - I know these packages should be fixed.
BUT - it does put the user trying to compile software in a frustrating position especially when it relates to fairly important packages like gstreamer.
Then it's the responsibility of the package maintainers to fix the software, or even it's the freedom of the user to debug the package and submit a fix for it. Or would you rather maintain two complete toolchains only not to have to fix some packages? Because it'd work like that: package A doesn't compile with gcc-3.3, so users compile it with 3.2.x which in turn leads to package A not getting fixed, ...
I know it can be frustrating for the end user/builder, even more so if package maintainers don't cooperate (e.g. mplayer vs. gcc-2.96), but I would want more convincing reasons for maintaining a second toolchain (not that I'm directly involved).
Nils
On Thu, Jul 31, 2003 at 05:10:45AM -0400, Jakub Jelinek wrote:
On Thu, Jul 31, 2003 at 10:01:20AM +0100, Mike Martin wrote:
previously, when RH has included a new compiler, compat packages have been included for previous version
But gcc 3.2.x is compatible with gcc 3.3.x (there are some corner cases but I believe gcc 3.2.x would simply ICE on them rather than generating ABI incompatible code with gcc 3.3.x).
So there is the last question: Do we need compat-libstdc++ from RH 9?
I (think) that we do not but I could be wrong as I do not use C++.
On Thu, Jul 31, 2003 at 04:45:43PM +0200, Milan Kerslager wrote:
On Thu, Jul 31, 2003 at 05:10:45AM -0400, Jakub Jelinek wrote:
On Thu, Jul 31, 2003 at 10:01:20AM +0100, Mike Martin wrote:
previously, when RH has included a new compiler, compat packages have been included for previous version
But gcc 3.2.x is compatible with gcc 3.3.x (there are some corner cases but I believe gcc 3.2.x would simply ICE on them rather than generating ABI incompatible code with gcc 3.3.x).
So there is the last question: Do we need compat-libstdc++ from RH 9?
Depends if you need that compatibility or not. compat-libstdc++ in Cambridge provides 2.96-RH, egcs 1.1.2 and some earlier libstdc++'s. If you have something still compiled against them, you need them, otherwise you don't.
Jakub
--- Jakub Jelinek jakub@redhat.com wrote: > On Thu, Jul 31, 2003 at 04:45:43PM +0200, Milan Kerslager wrote:
On Thu, Jul 31, 2003 at 05:10:45AM -0400, Jakub Jelinek wrote:
On Thu, Jul 31, 2003 at 10:01:20AM +0100, Mike Martin wrote:
previously, when RH has included a new compiler, compat
packages have
been included for previous version
But gcc 3.2.x is compatible with gcc 3.3.x (there are some
corner cases
but I believe gcc 3.2.x would simply ICE on them rather than
generating
ABI incompatible code with gcc 3.3.x).
So there is the last question: Do we need compat-libstdc++ from
RH 9?
Depends if you need that compatibility or not. compat-libstdc++ in Cambridge provides 2.96-RH, egcs 1.1.2 and some earlier libstdc++'s. If you have something still compiled against them, you need them, otherwise you don't.
Jakub
Ok lets see if I can persuade you
Imagine this scenario
You are trying to compile a program that uses/links against c and c++ code (eg:gstreamer, abiword)
The program fails to compile with an error message suggesting strict checking is making the build fail.
So to confirm you would like to test compiling with gcc32 and g++32
If it builds you can then confirm that gcc3.3 strictness is the problem.
Therefore you can write a more considered bug report so the problem gets fixed in the package
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
__________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html
There was an error in the abi for g++3.2x . By default the fixed abi isn't used in g++3.3 to ensure the advertised abi compatibility across g++ 2.2 and 2.3, but the fixed abi can be selected with -fabi-version=0 . This fixes some issues with ublas in boost.
Since gcc 3.3 is being used exclusively in redhat severn, could this compiler flag be used by default to ensure a (more) correct ABI is used for C++?
Joel
On Thu, Jul 31, 2003 at 05:10:45AM -0400, Jakub Jelinek (???) wrote:
But gcc 3.2.x is compatible with gcc 3.3.x (there are some corner cases but I believe gcc 3.2.x would simply ICE on them rather than generating ABI incompatible code with gcc 3.3.x).
On Thu, Jul 31, 2003 at 01:13:03PM -0400, Joel Young wrote:
There was an error in the abi for g++3.2x . By default the fixed abi isn't used in g++3.3 to ensure the advertised abi compatibility across g++ 2.2 and 2.3, but the fixed abi can be selected with -fabi-version=0 . This fixes some issues with ublas in boost.
Since gcc 3.3 is being used exclusively in redhat severn, could this compiler flag be used by default to ensure a (more) correct ABI is used for C++?
No, it cannot. We want to be: a) binary compatible with other 3.3.x compilers b) binary compatible with 3.2.x In addition to this -fabi-version=0 is a moving target, it changes quite often and there are several thing which are still going to change (and not just things which happen rarely, but things which will matter in almost every single C++ object file).
Jakub
-
Elliot Lee -
Jakub Jelinek -
Joel -
Michael K. Johnson -
Mike Martin -
Milan Kerslager -
Nils Philippsen