GCC seems to be lost, and other libraries

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

PS: I did try a forced reinstall of gcc48 with no effect at all

Has no one any ideas?

Try to rebuild the linker cache:

sudo /sbin/ldconfig

Maybe it got corrupted because of an unclean shoutdown.

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

Hm. You say this is a 64bit workstation, and the libs that aren’t not found are present in /usr/lib64/, right?

But are really the necessary 64bit packages installed?

uname -a
rpm -qi glibc

And I would suggest to run “fsck -f” on the root partition. Maybe there’s something wrong with the filesystem.

On 2014-05-28 14:36, jpff wrote:

> Thank you for the suggestion. Just did that and there is no change

Ok, post:


cat /etc/os-release
zypper lr --details

Maybe we can see something.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)


cage:~ # cat /etc/os-release
NAME=openSUSE
VERSION="13.1 (Bottle)"
VERSION_ID="13.1"
PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
cage:~ # zypper lr --details
#  | Alias                        | Name                               | Enabled | Refresh | Priority | Type   |
 URI                                                             | Service
---+------------------------------+------------------------------------+---------+---------+----------+--------+
-----------------------------------------------------------------+--------
 1 | download.nvidia.com-opensuse | nVidia Graphics Drivers            | Yes     | Yes     |   99     | rpm-md |
 http://download.nvidia.com/opensuse/13.1/                       |        
 2 | ftp.gwdg.de-suse             | Packman Repository                 | Yes     | Yes     |   98     | rpm-md |
 http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_13.1/        |        
 3 | openSUSE-13.1-1.10           | openSUSE-13.1-1.10                 | Yes     | No      |   99     | yast2  |
 cd:///?devices=/dev/disk/by-id/ata-HL-DT-STDVD-RAM_GH22LS30     |        
 4 | opensuse-guide.org-repo      | libdvdcss repository               | Yes     | Yes     |   99     | rpm-md |
 http://opensuse-guide.org/repo/13.1/                            |        
 5 | repo-debug                   | openSUSE-13.1-Debug                | No      | Yes     |   99     | NONE   |
 http://download.opensuse.org/debug/distribution/13.1/repo/oss/  |        
 6 | repo-debug-update            | openSUSE-13.1-Update-Debug         | No      | Yes     |   99     | NONE   |
 http://download.opensuse.org/debug/update/13.1/                 |        
 7 | repo-debug-update-non-oss    | openSUSE-13.1-Update-Debug-Non-Oss | No      | Yes     |   99     | NONE   |
 http://download.opensuse.org/debug/update/13.1-non-oss/         |        
 8 | repo-non-oss                 | openSUSE-13.1-Non-Oss              | Yes     | Yes     |   99     | yast2  |
 http://download.opensuse.org/distribution/13.1/repo/non-oss/    |        
 9 | repo-oss                     | openSUSE-13.1-Oss                  | Yes     | Yes     |   99     | yast2  |
 http://download.opensuse.org/distribution/13.1/repo/oss/        |        
10 | repo-source                  | openSUSE-13.1-Source               | No      | Yes     |   99     | NONE   |
 http://download.opensuse.org/source/distribution/13.1/repo/oss/ |        
11 | repo-update                  | openSUSE-13.1-Update               | Yes     | Yes     |   99     | rpm-md |
 http://download.opensuse.org/update/13.1/                       |        
12 | repo-update-non-oss          | openSUSE-13.1-Update-Non-Oss       | Yes     | Yes     |   99     | rpm-md |
 http://download.opensuse.org/update/13.1-non-oss/               |        

Apologies for formatting

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

On 2014-05-28 15:46, jpff wrote:

> Apologies for formatting

I had to copy to an editor to see it well. No big problem. You will have
to find out why the wrapping happened :wink:

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)

There are 3 i586 packages

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

Looks OK to me

and fsck was clean

What’s the output from:


printenv | grep LD

(I’m just wondering whether LD_LIBRARY_PATH is there, perhaps set to a bad value, as I think that could cause similar symptoms).

On 2014-05-28 17:16, nrickert wrote:

> Code:
> --------------------
>
> printenv | grep LD
>
> --------------------

It is empty in my case. :-?


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-05-28 17:06, jpff wrote:

> There are 3 i586 packages

Don’t forget the i686 packages.

> 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)

Some light: I chased awk to /usr/bin/gawk which is a 32bit binary

cage:~ # file /usr/bin/gawk
/usr/bin/gawk: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=2ea8d58e9d9e847ecaad5a77db54e3a642313cf7, stripped

whic is different from my working laptop. However zypper says I have installed the only gawk package. Forcing a reinstall fixes the libsigsegv error.

Now to find a reason for the cc1 problem. I have force-reinstalled gcc48 already

Thank you for the ideas so far
==John ff

Despite reinstalling gcc48 the binary was 32bit. I seem to have fixed for now with more frced reinstalls.

I guess I will never know how this changed, but it looks as if I am back.

Thank you; I really appeciate the assistance. This was driving me nuts

==John ff

cc1 is part of the package “cpp48”.

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.

Hm, as you didn’t have 32bit packages installed: maybe something you installed/ran manually copied those 32bit executables to /usr/bin/?

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)

On 2014-05-28 18:06, wolfi323 wrote:

> But as mentioned already, it doesn’t cause any problems either.

Unless symptomatic of binaries from another install being copied over,
or remaining from a previous install…


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.