[arch-general] How best to downgrade gcc to 4.4 or 4.3?
Guys, After running into a gcc 4.5.2 segfault, the trinity developer suggested a test to downgrade gcc to 4.4 or 4.3 and see if the gcc issue and issue concerning iccconfig.cpp go away. Looking through my old packages, the earliest I can find is 4.5.1. How best to downgrade?... and will I break everything if I do? My thought was just to pull the ABS pkgbuild and change pkgver back to 4.4.x, but I don't know if this will miss any patches, etc.. that may have been in place for earlier versions that are no longer there. Is there any old archive for pkgbuilds that would have an old gcc 4.4 or 4.3 in it? (obviously, if I knew the answers -- I wouldn't ask :) -- David C. Rankin, J.D.,P.E.
On 14/02/11 10:35, David C. Rankin wrote:
Guys,
After running into a gcc 4.5.2 segfault, the trinity developer suggested a test to downgrade gcc to 4.4 or 4.3 and see if the gcc issue and issue concerning iccconfig.cpp go away. Looking through my old packages, the earliest I can find is 4.5.1.
How best to downgrade?... and will I break everything if I do?
Not everything... but you will get some breakages (anything written in C++ probably won't work).
My thought was just to pull the ABS pkgbuild and change pkgver back to 4.4.x, but I don't know if this will miss any patches, etc.. that may have been in place for earlier versions that are no longer there. Is there any old archive for pkgbuilds that would have an old gcc 4.4 or 4.3 in it?
(obviously, if I knew the answers -- I wouldn't ask :)
Grab the gcc43 package from the AUR. I had a quick look at the PKGBUILD and it looks good. The gcc44 package not so much... Allan
On 02/13/2011 06:42 PM, Allan McRae wrote: <snip>
Grab the gcc43 package from the AUR. I had a quick look at the PKGBUILD and it looks good. The gcc44 package not so much...
Allan
Great! Thank you Allan, I'll be downgrading a VirtualBox VM so if it all goes south - not much of an issue. I'll let you know if it works :) -- David C. Rankin, J.D.,P.E.
On 14/02/11 10:59, David C. Rankin wrote:
On 02/13/2011 06:42 PM, Allan McRae wrote: <snip>
Grab the gcc43 package from the AUR. I had a quick look at the PKGBUILD and it looks good. The gcc44 package not so much...
Allan
Great! Thank you Allan,
I'll be downgrading a VirtualBox VM so if it all goes south - not much of an issue. I'll let you know if it works :)
That is not a downgrade but a separate package. You will need to use something like "CC=gcc-4.3 ./configure" in your PKGBUILD to use that gcc version. Allan
On 02/13/2011 07:07 PM, Allan McRae wrote:
That is not a downgrade but a separate package. You will need to use something like "CC=gcc-4.3 ./configure" in your PKGBUILD to use that gcc version.
Allan
Oh, your good... I would have messed that up royally. Thanks for being clairvoyant :p Now to figure out how that figures in to cmake builds :) -- David C. Rankin, J.D.,P.E.
On 02/13/2011 08:52 PM, David C. Rankin wrote:
On 02/13/2011 07:07 PM, Allan McRae wrote:
That is not a downgrade but a separate package. You will need to use something like "CC=gcc-4.3 ./configure" in your PKGBUILD to use that gcc version.
Allan
Oh, your good...
I would have messed that up royally. Thanks for being clairvoyant :p
Now to figure out how that figures in to cmake builds :)
Looks like adding the following to the PKGBUILD works: cd ${srcdir} cmake ../ \ -DCMAKE_C_COMPILER=${_c_compiler} \ -DCMAKE_CXX_COMPILER=${_cxx_compiler} \ <snip> is what will work. Let me know if this is the wrong way to do it. Thanks. -- David C. Rankin, J.D.,P.E.
On 02/13/2011 09:52 PM, David C. Rankin wrote:
On 02/13/2011 08:52 PM, David C. Rankin wrote:
On 02/13/2011 07:07 PM, Allan McRae wrote:
That is not a downgrade but a separate package. You will need to use something like "CC=gcc-4.3 ./configure" in your PKGBUILD to use that gcc version.
Allan
Oh, your good...
I would have messed that up royally. Thanks for being clairvoyant :p
Now to figure out how that figures in to cmake builds :)
Looks like adding the following to the PKGBUILD works:
cd ${srcdir}
cmake ../ \ -DCMAKE_C_COMPILER=${_c_compiler} \ -DCMAKE_CXX_COMPILER=${_cxx_compiler} \ <snip>
is what will work. Let me know if this is the wrong way to do it. Thanks.
UUGH! "undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11'" Looks like I need to downgrade other parts as well - bummer. kdebase built for 10 minutes until it hit the undefined reference. Full error: [ 7%] Building CXX object kcminit/CMakeFiles/kcminit.dir/kcminit_kdeinit_executable.cpp.o cd /home/david/tbld/kdebase/src/kcminit && /usr/bin/g++-4.3 -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -include tqt.h -I/home/david/tbld/kdebase/src/kcminit -I/home/david/tbld/kdebase/src -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -o CMakeFiles/kcminit.dir/kcminit_kdeinit_executable.cpp.o -c /home/david/tbld/kdebase/src/kcminit/kcminit_kdeinit_executable.cpp Linking CXX executable kcminit cd /home/david/tbld/kdebase/src/kcminit && /usr/bin/cmake -E cmake_link_script CMakeFiles/kcminit.dir/link.txt --verbose=1 /usr/bin/g++-4.3 -march=i686 -mtune=generic -O2 -pipe -include tqt.h -Wl,--hash-style=gnu -Wl,--as-needed CMakeFiles/kcminit.dir/kcminit_kdeinit_executable.cpp.o -o kcminit -rdynamic -L/opt/qt/lib libkdeinit_kcminit.so /opt/trinity/lib/libkutils.so.1.2.0 /opt/trinity/lib/libkparts.so.2.1.0 /opt/trinity/lib/libkio.so.4.2.0 /opt/trinity/lib/libkdeui.so.4.2.0 -lfreetype -lfontconfig /opt/trinity/lib/libkdesu.so.4.2.0 -lutil /opt/trinity/lib/libkwalletclient.so.1.0.1 /opt/trinity/lib/libkdecore.so.4.2.0 /opt/trinity/lib/libDCOP.so.4.2.0 /opt/trinity/lib/libkdefx.so.4.2.0 -ltqt -lqt-mt -lXrender -lX11 -lz -lICE -lSM -Wl,-rpath,/opt/qt/lib:/home/david/tbld/kdebase/src/kcminit:/opt/trinity/lib: /opt/trinity/lib/libkdefx.so.4.2.0: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' collect2: ld returned 1 exit status make[2]: *** [kcminit/kcminit] Error 1 make[2]: Leaving directory `/home/david/tbld/kdebase/src' make[1]: *** [kcminit/CMakeFiles/kcminit.dir/all] Error 2 make[1]: Leaving directory `/home/david/tbld/kdebase/src' make: *** [all] Error 2 Aborting... What other parts/packages do I need to downgrade, etc. to work with gcc-4.3? -- David C. Rankin, J.D.,P.E.
On 14/02/11 13:59, David C. Rankin wrote:
On 02/13/2011 09:52 PM, David C. Rankin wrote:
On 02/13/2011 08:52 PM, David C. Rankin wrote:
On 02/13/2011 07:07 PM, Allan McRae wrote:
That is not a downgrade but a separate package. You will need to use something like "CC=gcc-4.3 ./configure" in your PKGBUILD to use that gcc version.
Allan
Oh, your good...
I would have messed that up royally. Thanks for being clairvoyant :p
Now to figure out how that figures in to cmake builds :)
Looks like adding the following to the PKGBUILD works:
cd ${srcdir}
cmake ../ \ -DCMAKE_C_COMPILER=${_c_compiler} \ -DCMAKE_CXX_COMPILER=${_cxx_compiler} \ <snip>
is what will work. Let me know if this is the wrong way to do it. Thanks.
UUGH!
"undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11'"
Looks like I need to downgrade other parts as well - bummer. kdebase built for 10 minutes until it hit the undefined reference. Full error:
<snip>
What other parts/packages do I need to downgrade, etc. to work with gcc-4.3?
None - you probably need to rebuild earlier Trinity components with the older gcc though. Allan
On 02/13/2011 10:07 PM, Allan McRae wrote:
None - you probably need to rebuild earlier Trinity components with the older gcc though.
Allan
Thanks! -- David C. Rankin, J.D.,P.E.
On 02/13/2011 10:07 PM, Allan McRae wrote:
What other parts/packages do I need to downgrade, etc. to work with gcc-4.3?
None - you probably need to rebuild earlier Trinity components with the older gcc though.
Allan
Allan, Thanks -- that was the ticket. I rebuilt everything using gcc43 and for the first time - kdebase built without a single problem. (I even built it on two separate machines to make sure) So there is definitely a problem with gcc 4.5.2 (g++). Now we have the following building: 09:29 trinity:~/tbld> pacman -Q | grep trinity trinity-arts 1220535-1.1 trinity-kdebase 1220535-1.0 trinity-kdelibs 1220535-1.1 trinity-pyqt3 3.18.1-9 trinity-qt3 3.3.8-20 trinity-tqtinterface 1220535-1.0 I'll update the wiki and PKGBUILDs there later today with the ones that use gcc43. Thanks again. -- David C. Rankin, J.D.,P.E.
On 02/14/2011 09:33 AM, David C. Rankin wrote:
So there is definitely a problem with gcc 4.5.2 (g++).
Correction, There was a definite problem with the Trinity code after http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764 for gcc >=4.5 that rejected the existing class constructors in the Trinity code base. Fixes to the Trinity code will be out in a day or two and the Arch project can continue with the current gcc. Thanks for your help. Anybody interested in helping, feel free to jump in :p -- David C. Rankin, J.D.,P.E.
On Mon, 2011-02-14 at 19:19 -0600, David C. Rankin wrote:
On 02/14/2011 09:33 AM, David C. Rankin wrote:
So there is definitely a problem with gcc 4.5.2 (g++).
Correction,
There was a definite problem with the Trinity code after http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764 for gcc >=4.5 that rejected the existing class constructors in the Trinity code base. Fixes to the Trinity code will be out in a day or two and the Arch project can continue with the current gcc.
Thanks for your help. Anybody interested in helping, feel free to jump in :p
Just a quick question for you, as I understand it Trinity is basically a fork of kde3. From your comments in this thread it does seem there is some activity in the project. What's the plans of the project, an indefinite maintenance of current functionality (I'm assuming its qt3-based) ad infinitum?
On 02/14/2011 07:32 PM, Ng Oon-Ee wrote:
Just a quick question for you, as I understand it Trinity is basically a fork of kde3. From your comments in this thread it does seem there is some activity in the project. What's the plans of the project, an indefinite maintenance of current functionality (I'm assuming its qt3-based) ad infinitum?
It's actually a bit more than a fork at this point. Trinity is KDE3 that has been ported to cmake (for the most part), currently uses Qt3, but is being moved to Qt4 (in a proposed seamless fashion) through the use of tqtinterface that currently works with Qt3, but is designed to allow the use of Qt4 in the near future (still in work - and the details are over my head). When the shift to Qt4 is complete, Trinity will retain the KDE3 look to the interface, but simply incorporate Qt4 to do it. There is no desire to make Trinity look like KDE4. Trinity is basically KDE3 that has been rewritten to be compatible with the current Linux libraries, etc. I have written a wiki for Trinity on Arch where I have tried to include as much relevant information on the project as it relates to Arch (and which is a running set of notes on where I am in with the project). I have also included relevant links to the information at the Trinity site: https://wiki.archlinux.org/index.php/Trinity The current stable release is KDE 3.5.12. The svn development tree is KDE 3.5.13. The intent is to maintain KDE3 so that it remains a "choice" as a Linux desktop - no different than you have the "choice" to use gnome, kde4, lxde, e17, fluxbox, etc..., Trinity provides the choice to use a current KDE3. The goal of my project is simply to create a set of PKGBUILDs that allows Trinity to be easily built and maintained for Arch. There are current binaries provided and maintained for Debian, Slackware and Ubuntu. My project for Arch, another for openSuSE (Robert Xu) and another for Mandriva (Tim Williams) are currently underway. The challenge for me is Arch is so current, we were the first to run into the gcc >=4.5 problem. The trinity project (headed by Timothy Pearson) is active and has been around since KDE3 was abandoned. It has stable leadership and has gained needed support for critical mass. I think it's here to stay and it would be icing on the cake to make it available for Arch. The project has been fun so far and a learning experience, but I can always use help. If for nothing else, just help to point me in the right direction when I get stuck on a compile issue and help figuring out how best to do the PKGBUILDs. -- David C. Rankin, J.D.,P.E.
participants (3)
-
Allan McRae
-
David C. Rankin
-
Ng Oon-Ee