Hi,
Currently in rawhide the gcc is gcc-3.4 while the kernel (kernel-2.6.6-1.435) was compiled with gcc-3.3. As a consequnce, when I try to insmod a module I build myself (ADSL modem), I get in dmesg:
eagle_usb: version magic '2.6.6-1.435 686 REGPARM 4KSTACKS gcc-3.4' should be '2.6.6-1.435 686 REGPARM 4KSTACKS gcc-3.3'
and a insmod -v leads to 'Invalid module format'.
It maybe a good think to provide (keep) 'automatically' a compatible gcc, just like how different kernels may coexist (I use yum). Or there could be another solution...
Of course this is not a serious issue as it should disappear soon (and it seems to be in compat-gcc).
Pat
On Fri, 18 Jun 2004 13:43:25 +0200, Patrice Dumas pertusus@free.fr wrote:
It maybe a good think to provide (keep) 'automatically' a compatible gcc, just like how different kernels may coexist (I use yum). Or there could be another solution...
Of course this is not a serious issue as it should disappear soon (and it seems to be in compat-gcc).
There are several short messages about inconsistences in rawhide showing up in the lists. So I'll just pick on yours to make a larger point. The development tree goes through cyclic changes. Between official release and the opening up of the next release's testing process, the development tree can become very inconsistent becuase this is the time when major updates to subsystems will occur. The development tree isn't meant to always be self-consistent, and that is especially true outside of the pre-release testing phase.
For example right now, according to Katz ( http://www.livejournal.com/users/katzj/ ) the whole tree is being recompiled with gcc 3.4. That takes finite time, and there are definitely going to be post rebuild problems, small fires, regarding packages that did not build with gcc 3.4 and will have to be tweaked to work with the new compiler. I fully expect to see tree inconsitencies and package dependancy problems in the tree until the fires are put out. And I don't think its constructive use of anyone's time to point out inconsistency until the first pass of the gcc 3.4 build process has stopped.
But to pick on you a little bit..... I don't think you understand the point of the development tree. If your eating out of the development tree right now, and you aren't expecting problems more serious than a simple gcc mismatch, you aren't approaching the situation wisely. If test releases eat babies... the barren radioactive wasteland of the development tree post-release/pre-test-release will eat your babies and sterilize you so you can't have anymore.
-jef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 18 June 2004 06:21, Jeff Spaleta wrote:
But to pick on you a little bit..... I don't think you understand the point of the development tree. If your eating out of the development tree right now, and you aren't expecting problems more serious than a simple gcc mismatch, you aren't approaching the situation wisely. If test releases eat babies... the barren radioactive wasteland of the development tree post-release/pre-test-release will eat your babies and sterilize you so you can't have anymore.
BRAAAAAAANE!!!
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
until the fires are put out. And I don't think its constructive use of anyone's time to point out inconsistency until the first pass of the gcc 3.4 build process has stopped.
I couldn't know whether it was intentional or not, and I don't know how the build process works. I found a bug and I report it.
If your eating out of the development tree right now, and you aren't expecting problems more serious than a simple gcc mismatch, you aren't approaching the situation wisely.
I use the development tree to test stuff and report bugs. I don't expect anything to work. I think that you misunderstood my position. I am not complaining that something don't work. I am reporting it. I agree that maybe I shouldn't have reported, but knowing which issue should be reported and which shouldn't seems far from easy to me. I also reported before that it wasn't possible to build external modules as user, I thought that this was the same kind of issue. And a gcc mismatch is a serious problem. All the problems are serious. Still I don't expect any problem to be fixed, it's up to the developers.
And about the development repository being more broken at some times and less at others, I don't think it helps. I, personnally, consider that the development tree is always to be considered as broken.
Pat