[gentoo-user] downgrading gcc, stage 2
Hi,
while trying to get a clean system after downgrading gcc to
gcc-4.4.5. I encountered a field of black magick...more black
than magic at all:
To find broken libs I did these two commands:
sudo find /usr/lib/. /lib/. /usr/bin/. -type f -name 'lib*[^a]' -exec ldd
{} \; ! /tmp/librebuild.txt 21
cat /tmp/librebuild.txt | grep GLIB
and got a list like this one:
/usr/lib/./firefox/libxpcom.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./firefox/components/libdbusservice.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./firefox/components/libbrowsercomps.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./firefox/components/libmozgnome.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./libwpd-stream-0.9.so.9.0.4:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./libwpd-stream-0.9.so.9.0.4)
/usr/lib/./xulrunner-devel-2.0/sdk/lib/libxpcom.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./xulrunner-devel-2.0/sdk/lib/libxul.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./xulrunner-devel-2.0/sdk/lib/libxul.so)
/usr/lib/./ardour2/libpbd.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/libpbd.so)
/usr/lib/./ardour2/libgtkmm2ext.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/libgtkmm2ext.so)
/usr/lib/./ardour2/surfaces/libardour_powermate.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/surfaces/libardour_powermate.so)
/usr/lib/./ardour2/surfaces/libardour_genericmidi.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/surfaces/libardour_genericmidi.so)
/usr/lib/./ardour2/surfaces/libardour_tranzport.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/surfaces/libardour_tranzport.so)
/usr/lib/./ardour2/surfaces/libardour_mackie.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/surfaces/libardour_mackie.so)
/usr/lib/./ardour2/libardour.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/libardour.so)
/usr/lib/./ardour2/libmidi++.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/libmidi++.so)
/usr/lib/./ardour2/libardour_cp.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./ardour2/libardour_cp.so)
/usr/lib/./xulrunner-2.0/libxpcom.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./xulrunner-2.0/components/libdbusservice.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./xulrunner-2.0/components/libmozgnome.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by //usr/lib64/xulrunner-2.0/libxul.so)
/usr/lib/./xulrunner-2.0/libxul.so:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./xulrunner-2.0/libxul.so)
/usr/lib/./libwpd-0.9.so.9.0.4:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./libwpd-0.9.so.9.0.4)
/usr/lib/./libdigikamdatabase.so.2.0.0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib/./libdigikamdatabase.so.2.0.0)
/usr/lib/./libwpg-0.2.so.2.0.1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by /usr/lib64/libwpd-0.9.so.9)
/usr/lib/./libwpg-0.2.so.2.0.1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/libstdc++.so.6: version `GLIBCXX_3.4.14'
not found (required by
Re: [gentoo-user] downgrading gcc, stage 2
On Wed, 22 Feb 2012 20:47:24 +0100
meino.cra...@gmx.de wrote:
Hi,
while trying to get a clean system after downgrading gcc to
gcc-4.4.5. I encountered a field of black magick...more black
than magic at all:
To find broken libs I did these two commands:
sudo find /usr/lib/. /lib/. /usr/bin/. -type f -name 'lib*[^a]'
-exec ldd {} \; ! /tmp/librebuild.txt 21 cat /tmp/librebuild.txt |
grep
GLIB
Why don't you just use revdep-rebuild?
That tool automates precisely what you are trying to do manually.
--
Alan McKinnnon
alan.mckin...@gmail.com
Re: [gentoo-user] downgrading gcc, stage 2
On Wed, Feb 22, 2012 at 11:58 AM, Alan McKinnon alan.mckin...@gmail.com wrote:
On Wed, 22 Feb 2012 20:47:24 +0100
meino.cra...@gmx.de wrote:
Hi,
while trying to get a clean system after downgrading gcc to
gcc-4.4.5. I encountered a field of black magick...more black
than magic at all:
To find broken libs I did these two commands:
sudo find /usr/lib/. /lib/. /usr/bin/. -type f -name 'lib*[^a]'
-exec ldd {} \; ! /tmp/librebuild.txt 21 cat /tmp/librebuild.txt |
grep
GLIB
Why don't you just use revdep-rebuild?
That tool automates precisely what you are trying to do manually.
--
Alan McKinnnon
alan.mckin...@gmail.com
I tend to agree with Alan. revdep-rebuild should help.
Additionally, if I were really intent on downgrading gcc, then I would
probably remove EVERY application unneeded to keep the machine running
down to and including X11, do the downgrade, rebuild the kernel and
reboot, do an emerge -e @world, make sure all that is working, and
only then start building apps. But that's just me...
Not exactly related, but I'm personally wondering what's driving the
need to downgrade. For kicks yesterday I rebuilt my laptop which
currently has audio apps as well as Blender on it with the latest
stable gcc. Everything rebuilt fine and everything I've tried seems to
run.
Good luck,
Mark
[gentoo-user] Downgrading gcc
Hi, I want to downgrade gcc from 4.5.3-r1 to 4.4.5. The Gentoo gcc UPgrade guide tells me, that ABI are only upward compatible which implies problems when downgrading and not upgrading. Nonetheless a downgrade is needed here and I want to go to gcc-4.4.5. How can I acchieve this in a clean way? Best regards, mcc
Re: [gentoo-user] Downgrading gcc
Just re-emerge the older version e.g. emerge =...gcc-4.4.5 (... is the category). Then use eselect gcc or gcc-config to select the active gcc version. CMIIW Rgds, On Feb 20, 2012 11:24 AM, meino.cra...@gmx.de wrote: Hi, I want to downgrade gcc from 4.5.3-r1 to 4.4.5. The Gentoo gcc UPgrade guide tells me, that ABI are only upward compatible which implies problems when downgrading and not upgrading. Nonetheless a downgrade is needed here and I want to go to gcc-4.4.5. How can I acchieve this in a clean way? Best regards, mcc
Re: [gentoo-user] downgrading gcc
On Monday 20 April 2009 02:05:35 Dale wrote: Alan McKinnon wrote: On Sunday 19 April 2009 22:18:24 Mark Knecht wrote: 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Why would you want to do this? Do you suspect a toolchain API/ABI breakage between 4.1.2 and 4.3.2? He has been having trouble with mythtv, separate thread, and he has ran out of other options. He was following my thread and wants to back up to the old version of gcc to see if that corrects his problem. I suspect he would need to at least do a emerge -e mythtv to test this. I don't have mythtv here but I suspect that would be just about everything on his system and if gcc is causing this issue, he may as well test it all at once. That's the reason for what he is doing. OK, so it's sort of like Windows then - when you tried everything else and nothing works yet, just reinstall? I find these difficulties people are having with X somewhat amusing - my two personal machines have been on ~arch since forever, and even with huge amounts of activity in the last 18 months on X, gcc and glibc, all upgrades have been as smooth as silk for me. A possibility (speaking generically now), is that X and it's drivers and a bunch of other stuff all need to be compile with the same gcc. nvidia is like this and silently barfs if you don't. It's easy to get right with an upgrade - go to the latest - but a downgrade is a completely different animal (you don't know what you should be going back to). -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] downgrading gcc
Alan McKinnon wrote: On Monday 20 April 2009 02:05:35 Dale wrote: Alan McKinnon wrote: On Sunday 19 April 2009 22:18:24 Mark Knecht wrote: 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Why would you want to do this? Do you suspect a toolchain API/ABI breakage between 4.1.2 and 4.3.2? He has been having trouble with mythtv, separate thread, and he has ran out of other options. He was following my thread and wants to back up to the old version of gcc to see if that corrects his problem. I suspect he would need to at least do a emerge -e mythtv to test this. I don't have mythtv here but I suspect that would be just about everything on his system and if gcc is causing this issue, he may as well test it all at once. That's the reason for what he is doing. OK, so it's sort of like Windows then - when you tried everything else and nothing works yet, just reinstall? I find these difficulties people are having with X somewhat amusing - my two personal machines have been on ~arch since forever, and even with huge amounts of activity in the last 18 months on X, gcc and glibc, all upgrades have been as smooth as silk for me. A possibility (speaking generically now), is that X and it's drivers and a bunch of other stuff all need to be compile with the same gcc. nvidia is like this and silently barfs if you don't. It's easy to get right with an upgrade - go to the latest - but a downgrade is a completely different animal (you don't know what you should be going back to). Well, this is basically what I had to do. I wouldn't call it a complete reinstall but it is pretty close. It's not like booting from a CD and starting from scratch. In the original thread, he got a lot of help and tried a lot of things including recompiling a lot of things from what I read. I mentioned this should be a last resort. This is time consuming to say it lightly. That said, it has worked well for me. Everything on my rig is working again. If he has to do this downgrade of gcc, then a emerge -e world and everything works again, I'm going to really wonder what the deal is with gcc. Just me running into problems is one thing but to have someone else have issues as well, that's makes me wonder. Is there something funny going on that only affects certain hardware or something like that? How would one test it to see what is wrong when it is only a couple or a few people? Dale :-) :-)
Re: [gentoo-user] downgrading gcc
On Monday 20 April 2009 09:30:56 Dale wrote: That said, it has worked well for me. Everything on my rig is working again. If he has to do this downgrade of gcc, then a emerge -e world and everything works again, I'm going to really wonder what the deal is with gcc. Just me running into problems is one thing but to have someone else have issues as well, that's makes me wonder. Is there something funny going on that only affects certain hardware or something like that? How would one test it to see what is wrong when it is only a couple or a few people? It's more likely a compatibility issue between very specific modules or bits of code that affect lots of systems. Take for example this elog from the nvidia drivers: === This ebuild installs a kernel module and X driver. Both must match explicitly in their version. This means, if you restart X, you most modprobe -r nvidia before starting it back up === The interfaces that these things use have never been guaranteed to be stable, and gcc itself is free (within reason) to lay things out in memory anyway it sees fit. You get the same thing with X and it's drivers too. It makes sense - a server and it's drivers should all be part of the same release series and be built together with the same toolchain for best results. You DON'T get this problem with normal packages. You can upgrade and downgrade cairo all day long if you want and firefox won't care - the API it uses is stable and doesn't change. In your case and Mark's, you tried to downgrade something critical but have no information about what you should be downgrading to. When you synced portage, you lost the information about what was the latest arch and ~arch versions. Upgrade is easy - emerge latest arch for everything, we know it works, but portage doesn't offer a rollback function so downgrade is much harder. Once someone has figured out $LIST, you can emerge $LIST and life is good, but you don't have $LIST yet. Logic tells me you had two problems, and gcc is neither of them. Your box does not like latest X for whatever reason (problem 1) but you can't rollback to the last working version of everything involved as you don't know what it is (problem 2). So when all other efforts have failed, downgrade gcc and rebuild everything is very likely to fix those problems. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] downgrading gcc
Alan McKinnon wrote: It's more likely a compatibility issue between very specific modules or bits of code that affect lots of systems. Take for example this elog from the nvidia drivers: === This ebuild installs a kernel module and X driver. Both must match explicitly in their version. This means, if you restart X, you most modprobe -r nvidia before starting it back up === The interfaces that these things use have never been guaranteed to be stable, and gcc itself is free (within reason) to lay things out in memory anyway it sees fit. You get the same thing with X and it's drivers too. It makes sense - a server and it's drivers should all be part of the same release series and be built together with the same toolchain for best results. You DON'T get this problem with normal packages. You can upgrade and downgrade cairo all day long if you want and firefox won't care - the API it uses is stable and doesn't change. In your case and Mark's, you tried to downgrade something critical but have no information about what you should be downgrading to. When you synced portage, you lost the information about what was the latest arch and ~arch versions. Upgrade is easy - emerge latest arch for everything, we know it works, but portage doesn't offer a rollback function so downgrade is much harder. Once someone has figured out $LIST, you can emerge $LIST and life is good, but you don't have $LIST yet. Logic tells me you had two problems, and gcc is neither of them. Your box does not like latest X for whatever reason (problem 1) but you can't rollback to the last working version of everything involved as you don't know what it is (problem 2). So when all other efforts have failed, downgrade gcc and rebuild everything is very likely to fix those problems. While I'm not a dev, I do know this. All I did was downgrade gcc and a emerge -e world. After that, things started working again. X wasn't crashing, Seamonkey wasn't crashing, my USB ports starting working again, my sound started working again and several other little things that were weird. So far, I haven't changed any config files or any versions of a package. I haven't syncd the tree on this machine either. I didn't want to complicate things any farther with portage wanting to upgrade something else when I'm trying to get back to a stable system, The thing to notice is this, nothing changed but gcc. That's all. It is odd to me that when I upgraded gcc, things started to break. When I downgrade gcc, things start to work again. Since nothing else changed, in my mind, it has to be gcc. I may be wrong but the fact it works is undeniable. I'm all for what works. Dale :-) :-)
Re: [gentoo-user] downgrading gcc
On Mon, Apr 20, 2009 at 12:48 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Monday 20 April 2009 09:30:56 Dale wrote: That said, it has worked well for me. Everything on my rig is working again. If he has to do this downgrade of gcc, then a emerge -e world and everything works again, I'm going to really wonder what the deal is with gcc. Just me running into problems is one thing but to have someone else have issues as well, that's makes me wonder. Is there something funny going on that only affects certain hardware or something like that? How would one test it to see what is wrong when it is only a couple or a few people? It's more likely a compatibility issue between very specific modules or bits of code that affect lots of systems. Take for example this elog from the nvidia drivers: === This ebuild installs a kernel module and X driver. Both must match explicitly in their version. This means, if you restart X, you most modprobe -r nvidia before starting it back up === The interfaces that these things use have never been guaranteed to be stable, and gcc itself is free (within reason) to lay things out in memory anyway it sees fit. You get the same thing with X and it's drivers too. It makes sense - a server and it's drivers should all be part of the same release series and be built together with the same toolchain for best results. You DON'T get this problem with normal packages. You can upgrade and downgrade cairo all day long if you want and firefox won't care - the API it uses is stable and doesn't change. In your case and Mark's, you tried to downgrade something critical but have no information about what you should be downgrading to. When you synced portage, you lost the information about what was the latest arch and ~arch versions. Upgrade is easy - emerge latest arch for everything, we know it works, but portage doesn't offer a rollback function so downgrade is much harder. Once someone has figured out $LIST, you can emerge $LIST and life is good, but you don't have $LIST yet. Logic tells me you had two problems, and gcc is neither of them. Your box does not like latest X for whatever reason (problem 1) but you can't rollback to the last working version of everything involved as you don't know what it is (problem 2). So when all other efforts have failed, downgrade gcc and rebuild everything is very likely to fix those problems. -- alan dot mckinnon at gmail dot com Alan, Hi. Thanks for your inputs and help. I appreciate it. I think you've covered most of the issues fairly clearly. What you cannot cover is the specifics of my hardware, so I'll try to do this based on what I think I've learned. As best I can tell the failure I'm seeing is a segfault in the Intel VGA driver when doing xv video. OpenGL works fine, and other than xv the Intel driver works fine for me. Using mplayer I can watch videos when I choose OpenGL rendering. All applications fail when using xv, but my initial realization came from mythfrontend which is why this has had a 'mythtv segfaults' title in the past. None the less it's really xv. There are 1 line segfault messages in different log files after the crash pointing at the i915 driver saying it cannot pin an xv buffer in memory. This is apparently known at X.org as I found and posted my results in an existing bug report - one of many on apparently the same issue. Note that if you, or the person who decided to mark xorg-server-1.5 and gcc-4.3.2 stable didn't have Intel hardware, then only if they actually ran xv video apps, they wouldn't have seen this problem. This sort of problem is (to me) a root weakness of the Gentoo package management system. Nothing is really 'stable' as it's not tested against a wide range of known hardware platforms with a know set of test cases before it's marked 'stable' so this sort of thing happens now and again. There is no reason for you to say X isn't stable, or gcc causes problems because everything works on your system. (Or you think it does!) ;-) In my case I *think* the problem showed up only after rebuilding X with gcc-4.3.2 but at this point I've unfortunately sort of lost track of the whole history. I *believe* that gcc got upgraded, I switched my compiler to the newer 4.3.2 version, then an X upgrade came along, got built and started failing. My first attempt at fixing this was to downgrade xorg-server back to 1.3. This failed, but it was built with the newer compiler so it wasn't a real downgrade in the sense of going back to what I had before. I then tried moving to xorg-x11-7.4 which some people at X.org said fixed the problem for them. Unfortunately for me it didn't. Over the years this sort of thing has happened a few times with Gentoo so maybe once every 2 years I'll do an emerge -e system, emerge -e world just to make sure everything is up to date. As I was having problems I decided to do that and move the whole machine to 4.3.2. I got started
[gentoo-user] downgrading gcc
Hi, Is downgrading gcc allowed within the same major version? If I wanted to downgrade my gcc from 4.3.2 to 4.1.2 then: 1) Do I simply choose 4.1.2 using gcc-config? 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Thanks in advance, Mark
Re: [gentoo-user] downgrading gcc
Mark Knecht wrote: Hi, Is downgrading gcc allowed within the same major version? If I wanted to downgrade my gcc from 4.3.2 to 4.1.2 then: 1) Do I simply choose 4.1.2 using gcc-config? 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Thanks in advance, Mark You may also want to see my reply to the USB thread. Dale :-) :-)
Re: [gentoo-user] downgrading gcc
On Sunday 19 April 2009 22:18:24 Mark Knecht wrote: Hi, Is downgrading gcc allowed within the same major version? If I wanted to downgrade my gcc from 4.3.2 to 4.1.2 then: It's not a problem. If it were, there would be no point in allowing multiple versions as it would not be possible to select a lower numbered one 1) Do I simply choose 4.1.2 using gcc-config? Yes 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Why would you want to do this? Do you suspect a toolchain API/ABI breakage between 4.1.2 and 4.3.2? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] downgrading gcc
Alan McKinnon wrote: On Sunday 19 April 2009 22:18:24 Mark Knecht wrote: 2) Should I expect any problems with the system if I do emerge -e system emerge -e system [OPTIONAL] emerge -e world Why would you want to do this? Do you suspect a toolchain API/ABI breakage between 4.1.2 and 4.3.2? He has been having trouble with mythtv, separate thread, and he has ran out of other options. He was following my thread and wants to back up to the old version of gcc to see if that corrects his problem. I suspect he would need to at least do a emerge -e mythtv to test this. I don't have mythtv here but I suspect that would be just about everything on his system and if gcc is causing this issue, he may as well test it all at once. That's the reason for what he is doing. Dale :-) :-)
