I have been away for a while. On return updated my 64bit workstation (AMD Phenom quad; 64bit) but now I cannot compile C programs
It reports
gcc: error trying to exec ‘cc1’: execvp: No such file or directory
Comparing with another (working) machine, my laptop, the only cc1 I can see is in /usr/lib64/gcc/x86_64-suse-linux/4.8/
-rwxr-xr-x 1 root root 12571880 Oct 4 2013 /usr/lib64/gcc/x86_64-suse-linux/4.8/cc1*
-rwxr-xr-x 1 root root 13567240 Oct 4 2013 /usr/lib64/gcc/x86_64-suse-linux/4.8/cc1plus*
same on both computers.
I also note when starting an xterm I get
awk: error while loading shared libraries: libsigsegv.so.2: cannot open shared object file: No such file or directory
awk: error while loading shared libraries: libsigsegv.so.2: cannot open shared object file: No such file or directory
but /usr/lib64 has that library. I recall something similar regarding a crypto library but cannot reproduce just now.
It seems as if it is not looking in /usr/lib64 for things.
What could have gone wrong? And more importantly how do I get my compilation world back?
Ru7nning OpenSuSE13.1 with fvwm; no kde or gnome
==John ff
Thank you for the suggestion. Just did that and there is no change
cage:~ # ldconfig
cage:~ # su -l jpff
awk: error while loading shared libraries: libsigsegv.so.2: cannot open shared object file: No such file or directory
awk: error while loading shared libraries: libsigsegv.so.2: cannot open shared object file: No such file or directory
and still no C compilation
gcc: error trying to exec 'cc1': execvp: No such file or directory
cage:~ # uname -a
Linux cage 3.11.10-11-desktop #1 SMP PREEMPT Mon May 12 13:37:06 UTC 2014 (3d22b5f) x86_64 x86_64 x86_64 GNU/Linux
cage:~ # rpm -qi glibc
Name : glibc
Version : 2.18
Release : 4.15.1
Architecture: x86_64
Install Date: Sun 18 May 2014 19:56:39 BST
Group : System/Libraries
Size : 6579337
License : LGPL-2.1+ and SUSE-LGPL-2.1+-with-GCC-exception and GPL-2.0+
Signature : RSA/SHA256, Thu 15 May 2014 13:35:16 BST, Key ID b88b2fd43dbdc284
Source RPM : glibc-2.18-4.15.1.src.rpm
Build Date : Wed 07 May 2014 15:09:59 BST
Build Host : build24
Relocations : (not relocatable)
Packager : http://bugs.opensuse.org
Vendor : openSUSE
URL : http://www.gnu.org/software/libc/libc.html
Summary : Standard Shared Libraries (from the GNU C Library)
Description :
The GNU C Library provides the most important standard libraries used
by nearly all programs: the standard C library, the standard math
library, and the POSIX thread library. A system is not functional
without these libraries.
Distribution: openSUSE 13.1
Will try fsck soon, but yes 64bit packages as before – it was working in April
I had to copy to an editor to see it well. No big problem. You will have
to find out why the wrapping happened
Ok, no problem that I can see in the repo list. So, lets check the
packages themselves.
Try one of these (the first one is for import on a spreadsheet, if you
wish):
rpm -q -a --queryformat "%{INSTALLTIME};%{INSTALLTIME:day}; \
%{BUILDTIME:day}; %{NAME};%{VERSION}-%-7{RELEASE};%{arch}; \
%{VENDOR};%{PACKAGER};%{DISTRIBUTION};%{DISTTAG}
" \
| sort | cut --fields="2-" --delimiter=\; \
| tee rpmlist.csv | less -S
or
rpm -q -a --queryformat "%{INSTALLTIME} %{INSTALLTIME:day} \
%{BUILDTIME:day} %-30{NAME} %15{VERSION}-%-7{RELEASE} %{arch} \
%25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}
" \
| sort | cut --fields="2-" | tee rpmlist | less -S
The “{arch}” field is the one you have to watch: find out if you got
packages from the wrong architecture. Be careful of “false” positives,
because there are some applications (proprietary ones, specially) that
do not have a 64 bit version.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
cage:~ # grep i586 rpmlist.csv
Wed Jan 19 2011; Wed Jan 05 2011; libx264-107;0.107svn20101016-1.pm.1.6;i586; http://packman.links2linux.de;mantre@links2linux.de;main_pm / openSUSE_11.3_Update;(none)
Tue Jan 21 2014; Fri Sep 27 2013; master-boot-code;1.22-14.1.2 ;i586; openSUSE;http://bugs.opensuse.org;openSUSE 13.1;(none)
Sat May 24 2014; Mon May 19 2014; wine-mp3;1.1.39-13.1 ;i586; http://packman.links2linux.de;packman@links2linux.de;Essentials / openSUSE_13.1;(none)
Not sure what libx264 is but there is also a x86_64 package of this name installed
I never use wine (surprised it is there), which leaves the master boot code, but it does boot OK
Plus of course many noarch packages (288), but really x86-64 otherwise, 200 of which have 32bit in their name
> Code:
> --------------------
> cage:~ # grep i586 rpmlist.csv
> Wed Jan 19 2011; Wed Jan 05 2011; libx264-107;0.107svn20101016-1.pm.1.6;i586; http://packman.links2linux.de;mantre@links2linux.de;main_pm / openSUSE_11.3_Update;(none)
> Tue Jan 21 2014; Fri Sep 27 2013; master-boot-code;1.22-14.1.2 ;i586; openSUSE;http://bugs.opensuse.org;openSUSE 13.1;(none)
> Sat May 24 2014; Mon May 19 2014; wine-mp3;1.1.39-13.1 ;i586; http://packman.links2linux.de;packman@links2linux.de;Essentials / openSUSE_13.1;(none)
>
> --------------------
>
>
> Not sure what libx264 is but there is also a x86_64 package of this
> name installed
Well, it is old (current version is libx264-142-0.142), and it should
not be there. Maybe you have xine-32, or similar, which some people
install in order to use the old windows codecs package. I don’t think
this is needed, but I very much doubt it can cause your problems.
grub and wine-mp3 have to be 32 bit, so that’s correct.
> I never use wine (surprised it is there), which leaves the master boot
> code, but it does boot OK
> Plus of course many noarch packages (288), but really x86-64 otherwise,
> 200 of which have 32bit in their name
>
> Looks OK to me
Yes, to me too.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
You should uninstall libx264-107 though. That’s quite old (from 2010 as the version indicates), the current version is libx264-142.
This is most likely a left-over from an earlier openSUSE version and not used by anything.
But as mentioned already, it doesn’t cause any problems either.
On 2014-05-28 18:06, wolfi323 wrote:
>
> jpff;2645963 Wrote:
>> I guess I will never know how this changed, but it looks as if I am
>> back.
> Hm, as you didn’t have 32bit packages installed: maybe something you
> installed/ran manually copied those 32bit executables to /usr/bin/?
I would make an rpm verify run, see that the checksums match.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
???
No, if binaries would have been copied over, that package wouldn’t be installed.
or remaining from a previous install…
But then it wouldn’t cause any problems, that’s my point.
It would just sit there, unused.
To explain the most likely reason for this package being still there:
libx264 had many incompatible version updates.
libx264-142 is a different package than libx264-107. So installing the one does not remove or update the other.
It is handled in this way so you can install different incompatible versions of libraries next to each other, so you can install/use applications using the old one and applications the new one.
And even on upgrading, that package won’t be removed. So it’s most likely a left-over from a previous 32bit installation.
But again, it just takes space on the disk, nothing else.
