-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Libphp4 and GCC_3.3 are not playing well together. I have tried both apache and apache2 with various configs and no go regardless. I get the following when issueing the command: /etc/init.d/apache restart Syntax error on line 8 of /etc/httpd/suse_loadmodule.conf: Cannot load /usr/lib/apache2-prefork/libphp4.so into server: /usr/lib/libstdc++.so.5: symbol _Unwind_Resume_or_Rethrow, version GCC_3.3 not defined in file libgcc_s.so.1 with link time reference /etc/init.d/apache restart Syntax error on line 8 of /etc/httpd/suse_loadmodule.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/lib/libstdc++.so.5: symbol _Unwind_Resume_or_Rethrow, version GCC_3.3 not defined in file libgcc_s.so.1 with link time reference Any comments or suggestions? TIA! Cheers, Curits. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/N8npiqnGhdjCOJsRAratAJ95wEfJQnjzITjDCXuZICwMrORKlgCfTbKy lWHb6XzQ25+Q+NQ4PH1FR0o= =lhNG -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 11 August 2003 06:26 pm, Philipp Thomas wrote:
Curtis Rey
[Mon, 11 Aug 2003 11:52:53 -0500]: Libphp4 and GCC_3.3 are not playing well together.
Exactly which version of gcc was used to compile libphp4 (that is, if you compiled it yourself)? And how was it linked?
Philipp
rpm -qa | grep gcc gcc-c++-3.3-43 gcc-g77-3.3-43 gcc-info-3.3-43 gcc-java-3.3-43 gcc-objc-3.3-43 gcc-3.3-43 libgcc-3.3-43 la /usr/lib/apache2-prefork/libphp4.so - -rwxr-xr-x 1 root root 2586520 2003-03-17 11:35 /usr/lib/apache2-prefork/libphp4.so la /usr/lib/apache/libphp4.so - -rwxr-xr-x 1 root root 2595044 2003-03-17 11:35 /usr/lib/apache/libphp4.so If I'm reading this correctly apparently it isn't not linked... hmmm! where do I want to point this to if it is indeed the problem? TIA Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/OCtJiqnGhdjCOJsRAktEAJ4lJZ7ngRPeE7cgFepH2YxquZDF3QCeL3DI PWq6bcGwA6LCopeXTngFRwo= =HQZM -----END PGP SIGNATURE-----
Curtis Rey
gcc-3.3-43
What does 'gcc --version' say? Did you compile php4 by yourself? If not, did you take it from the distribution?
- -rwxr-xr-x 1 root root 2595044 2003-03-17 11:35 /usr/lib/apache/libphp4.so
If I'm reading this correctly apparently it isn't not linked... hmmm!
No, I didn't make myself clear enough. A library is created by linking object files. This is done when compiling it. If you didn't compile libphp4 by yourself, you wouldn't know how libphp4 was linked. Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 11 August 2003 07:37 pm, Philipp Thomas wrote:
Curtis Rey
[Mon, 11 Aug 2003 18:48:21 -0500]: gcc-3.3-43
What does 'gcc --version' say?
Did you compile php4 by yourself? If not, did you take it from the distribution?
- -rwxr-xr-x 1 root root 2595044 2003-03-17 11:35 /usr/lib/apache/libphp4.so
If I'm reading this correctly apparently it isn't not linked... hmmm!
No, I didn't make myself clear enough. A library is created by linking object files. This is done when compiling it. If you didn't compile libphp4 by yourself, you wouldn't know how libphp4 was linked.
Philipp
Correct, they are rpms. I have gotten them for the disks and updates. Otherwise they are pretty stock. So the config is essentially that of SuSE. I have been fiddling with various conf files for apache but have the orig backed up. I have very frequently had problems with apache, especially considering that I usually only set it up for localhost in order to use an extended/updatable help system. Other than that I have only update the rpms. I generally use tarballs for non-stock programs/libs and occasionally for stuff like mplayer/xine (though packman is now covering most of that and others). If I do use tarballs then I use checkconfig to convert to rpms to keep the database up to speed and so YaST doesn't go bonkers on me (still gets cranky though). As for as the gcc version is concerned: gcc --version gcc (GCC) 3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks in advance :) Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/OEviiqnGhdjCOJsRAr/bAJ9ytZ1fvVri60VOtsjX0XpwJf7tIACaAsg5 Yb6h2Efx9UWJu8O52QpIeaY= =H/fC -----END PGP SIGNATURE-----
On Monday 11 August 2003 22:07, Curtis Rey wrote: .......<huge snip>..........
Other than that I have only update the rpms. I generally use tarballs for non-stock programs/libs and occasionally for stuff like mplayer/xine (though packman is now covering most of that and others). If I do use tarballs then I use checkconfig to convert to rpms to keep the database up to speed and so YaST doesn't go bonkers on me (still gets cranky though).
Whoa! Whoa! Curtis ! New interseting stuff for me ! checkconfig ?? Are you saying you can convert tarball stuff with checkconfig to rpm status?? Tell me -teach me! Sorry, hope this is not construed as thread theft. Just had to know, Bob S.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 12 August 2003 12:30 am, Bob S. wrote:
On Monday 11 August 2003 22:07, Curtis Rey wrote:
.......<huge snip>..........
Other than that I have only update the rpms. I generally use tarballs for non-stock programs/libs and occasionally for stuff like mplayer/xine (though packman is now covering most of that and others). If I do use tarballs then I use checkconfig to convert to rpms to keep the database up to speed and so YaST doesn't go bonkers on me (still gets cranky though).
Whoa! Whoa! Curtis ! New interseting stuff for me !
checkconfig ?? Are you saying you can convert tarball stuff with checkconfig to rpm status?? Tell me -teach me!
Sorry, hope this is not construed as thread theft. Just had to know,
Bob S.
OPPS! I did it again. Not checkconfig... CHECKINSTALL (sometimes I amaze myself - as in being dense). Yes a program called CHECKINSTALL (not yell at you, yelling at myself) can be used to convert tarballs into rpms. So, you do a ./configure and make. Of course if you have to do all those things relavent to setup it up like libpaths, KDEDIR paths, etc, or whatever. Once you get the ./config and make to run without errors (or if your savvy errors that aren't going to cludge the program or system like isn't using fltk but is configed to use gtk/gtk2 or whatever), then instead of running the "make install" command you run the "checkinstall" command. The program kicks in and asks you a short series of questions, like the name of the rpm. So for instance if you compiling alsa-0.9.6.blahblah then you would name the rpm alsa-0.9.6rc5 or alsa-0.9.5-42 or whatever (generally I pretty much name the same as the tarball). Then some other questions like have it clue in the rpm data base and yada yada. It's fairly straight forward. Anyway, once it has run it makes an rpm package of the tarball but keeps the original tarball there as well. This is nice because if you install tarballs then the rpm database usually remains clueless. This is problematic becuase it with complain, whine, and otherwise refuse to install a program because some dependent lib is not install (or whatever) when you know damn well you just installed the tarball for the depenency 5 minutes ago... but as a tarball and then the fun insues. So therefore you have two sets of the same package when using checkinstall, the original tarball and the rpm you made from the tarball. If you want to uninstall the package later just give the command "rpm -e <package name>" and boom it's removed via rpm. And you still have the tarball. Also handy in case your config didn't go all that smoothly but you gave it a shot and it failed. You can go back and try to config it again, run checkinstall and see if you've corrected the problem. Of course if you config is so kludged that it has some sort of dire effect overall then you might have wanted to nail the config a little better, but one has to actually put some effort into that scenario usually. So it's: tar xvfz or xvfj (bz2) <package>.tar.gz/tar.bz2 cd <package> ./configure make checkinstall answer question lather, rinse, repeat. HTH, Curtis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/OIIniqnGhdjCOJsRAkFmAJ0U26aoglqfHhAGol4ua2wlB2hP7gCdGH7f VOCqqsUFeynLjfSR/bvSLFg= =nj6J -----END PGP SIGNATURE-----
On Monday 11 August 2003 22:30, Bob S. wrote:
On Monday 11 August 2003 22:07, Curtis Rey wrote:
.......<huge snip>..........
Other than that I have only update the rpms. I generally use tarballs for non-stock programs/libs and occasionally for stuff like mplayer/xine (though packman is now covering most of that and others). If I do use tarballs then I use checkconfig to convert to rpms to keep the database up to speed and so YaST doesn't go bonkers on me (still gets cranky though).
I saw the Apache/libphp4.so error after I upgraded to the newer GCC 3.3 from ftp://ftp.suse.com/pub/projects (the 8.2 GCC gave "prerelease" in the version message) and fixed it by re-installing libgcc-3.3-43.i586.rpm and running "ldconfig" . Mark Almeida -- Powered by SuSE Linux Pro 8.2/Kmail 1.5.3
The Wizard
I saw the Apache/libphp4.so error after I upgraded to the newer GCC 3.3 from ftp://ftp.suse.com/pub/projects (the 8.2 GCC gave "prerelease" in the version message) and fixed it by re-installing libgcc-3.3-43.i586.rpm and running "ldconfig" .
Yes, gcc needs more than one package to be usable. These packages form the base on which all other packages build: libgcc (shared runtime support library) cpp (preprocessor, actually the C frontend as there is no separate preprocessor anymore). gcc (compiler driver, gcc specific headers etc.) This base is all you need if you only want to compile C Programs. All following package sets need the C compiler, i.e. must be installed in addition to the above base packages. C++: gcc-c++ (compiler driver plus C++ frontend) libstdc++ (standard C++ library, shared libraries only) libstdc++-devel (static libraries and header files) Fortran77: gcc-g77 Java: gcc-java (java compiler) libgcj (java libraries, shared version only) libgcj-devel (headers, static libraries, symlinks for linking) Ada: gnat (nearly complete Ada development package) gnat-runtime (ADA shared runtime libraries) Objective C: gcc-objc (objective C frontend) libobjc (libraries, headers etc.) And independently from the rest the documentation in texinfo format: gcc-info Maybe I should expand the README to make it clear which packages are needed? Philipp -- Philipp Thomas work: pthomas@suse.de private: philipp.thomas@t-link.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 12 August 2003 05:20 pm, Philipp Thomas wrote:
The Wizard
[Tue, 12 Aug 2003 08:16:44 -0700]: I saw the Apache/libphp4.so error after I upgraded to the newer GCC 3.3 from ftp://ftp.suse.com/pub/projects (the 8.2 GCC gave "prerelease" in the version message) and fixed it by re-installing libgcc-3.3-43.i586.rpm and running "ldconfig" .
Yes, gcc needs more than one package to be usable. These packages form the base on which all other packages build:
libgcc (shared runtime support library) cpp (preprocessor, actually the C frontend as there is no separate preprocessor anymore). gcc (compiler driver, gcc specific headers etc.)
This base is all you need if you only want to compile C Programs.
All following package sets need the C compiler, i.e. must be installed in addition to the above base packages.
C++:
gcc-c++ (compiler driver plus C++ frontend) libstdc++ (standard C++ library, shared libraries only) libstdc++-devel (static libraries and header files)
Fortran77:
gcc-g77
Java:
gcc-java (java compiler) libgcj (java libraries, shared version only) libgcj-devel (headers, static libraries, symlinks for linking)
Ada:
gnat (nearly complete Ada development package) gnat-runtime (ADA shared runtime libraries)
Objective C:
gcc-objc (objective C frontend) libobjc (libraries, headers etc.)
And independently from the rest the documentation in texinfo format:
gcc-info
Maybe I should expand the README to make it clear which packages are needed?
Philipp
I had installed all the packages via the project/gcc directory weeks ago and followed the instruction posted on both the website and the README. rpm -qa | grep cpp cpp-3.3-43 rpm -qa | grep gcc gcc-c++-3.3-43 libgcc-3.3-43 gcc-g77-3.3-43 gcc-info-3.3-43 gcc-java-3.3-43 gcc-objc-3.3-43 gcc-3.3-43 rpm -qa | grep libgcc libgcc-3.3-43 rpm -qa | grep libgcj libgcj-3.3-43 libgcj-devel-3.3-43 rpm -qa | grep libgcj-devel libgcj-devel-3.3-43 rpm -qa | grep gcc-g77 gcc-g77-3.3-43 rpm -qa | grep libstdc libstdc++-3.3-43 libstdc++-devel-3.3-43 rpm -qa | grep gcc-java gcc-java-3.3-43 rpm -qa | grep gcc-objc gcc-objc-3.3-43 rpm -qa | grep libobjc libobjc-3.3-43 rpm -qa | grep gccinfo nada zip zilch. After updating the new kernel via rpm as suggested in the announcement and via yast the NVIDIA drivers (kernel/GLX) won't install via the installer, sources rpms under rebuild give the following: *** Failed cc sanity check. Bailing out! *** make: *** [gcc-check] Error 1 + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.51101 + umask 022 + cd /usr/src/packages/BUILD + cd NVIDIA_kernel-1.0-4496 + rm -f /tmp/files.lst + '[' -z '' ']' ++ uname -r + export TARGET_KERNEL=2.4.20-4GB-athlon + TARGET_KERNEL=2.4.20-4GB-athlon + '[' -d /lib/modules/2.4.20-4GB-athlon/kernel ']' + INSTALLPATH=/lib/modules/2.4.20-4GB-athlon/kernel/drivers/video + mkdir -p /var/tmp/NVIDIA_kernel-1.0//lib/modules/2.4.20-4GB-athlon/kernel/drivers/video + install -m 0444 nvidia.o /var/tmp/NVIDIA_kernel-1.0//lib/modules/2.4.20-4GB-athlon/kernel/drivers/video install: cannot stat `nvidia.o': No such file or directory Bad exit status from /var/tmp/rpm-tmp.51101 (%install) But the GLX drivers will rebuild, but an rpm -ba for the GLX returns the essentially the same as above: *** Failed cc sanity check. Bailing out! *** make: *** [gcc-check] Error 1 + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.57628 + umask 022 + cd /usr/src/packages/BUILD + cd NVIDIA_kernel-1.0-4496 + rm -f /tmp/files.lst + '[' -z '' ']' ++ uname -r + export TARGET_KERNEL=2.4.20-4GB-athlon + TARGET_KERNEL=2.4.20-4GB-athlon + '[' -d /lib/modules/2.4.20-4GB-athlon/kernel ']' + INSTALLPATH=/lib/modules/2.4.20-4GB-athlon/kernel/drivers/video + mkdir -p /var/tmp/NVIDIA_kernel-1.0//lib/modules/2.4.20-4GB-athlon/kernel/drivers/video + install -m 0444 nvidia.o /var/tmp/NVIDIA_kernel-1.0//lib/modules/2.4.20-4GB-athlon/kernel/drivers/video install: cannot stat `nvidia.o': No such file or directory Bad exit status from /var/tmp/rpm-tmp.57628 (%install) This also happens with most others sources/src.rpm's. The strange thing is that this is a recent occurance. It didn't give me problems until early this week <shrugs> Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/OZLUiqnGhdjCOJsRAvXbAJ4hN3nzP5wp2UZmE1vhkKVRpfXmPACeP2FY 43e+5LnLtAU3yVAdWRaMknM= =pGDo -----END PGP SIGNATURE-----
participants (4)
-
Bob S.
-
Curtis Rey
-
Philipp Thomas
-
The Wizard