For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Build failure on fedora from reporing: /usr/lib/ could not read symbols: File in wrong format

Phil Cobbin's picture

This looks like some sort of NVIDIA driver related issue.

Any suggestions on how to rework the configure and get this fixed would be a big help

Forum supervisor's picture

Hi Phil,
The most probably NVIDIA drivers have been installed incorrectly.
/usr/lib/ can not find some symbols.
Try to make :

> ldd -r /usr/lib/


Phil Cobbin's picture

here's the output:
ldd -r /usr/lib/ => (0xf7f9a000) => /usr/lib/ (0xf6f5d000) => /usr/lib/ (0xf6f5b000) => /lib/ (0xf6f33000) => /usr/lib/ (0xf6f23000) => /usr/lib/ (0xf6df3000) => /lib/ (0xf6dee000) => /lib/ (0xf6c7d000)
/lib/ (0x41cc7000) => /usr/lib/ (0xf6c7a000) => /usr/lib/ (0xf6c5e000)

I still get the make error, I also note there is an earlier warning that is probably related:
*** Warning: linker path does not have real file for library -lXt.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libXt and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

Thanks for your help, also the subsequent post with a script did not work as my system does not have a /usr/lib64/nvidia directory.

This sure sounds like an NVIDIA adventure so I've fixed my inittab for the eventual driver crash.

Marco Nawijn's picture

Hi Phil,

Are you running Fedora. In that case it might be that is linked to the wrong non-NVIDIA library. I had the same issue. For some reason each "yum update" invalidates the link. I have a small bash script that corrects the issue:

#!/usr/bin/env bash

# Author: M. Nawijn
# Purpose: Restore symbolic links to NVIDIA libGL* libraries.
# These symbolic links are somehow restored to default
# non-NVIDIA libraries after yum update

# Test for existence of NVIDIA shared libs


if [ -L $nvlibdir/ ]; then
echo "NVIDIA sharedlibrary exists"

if [ -L $libdir/ ]; then
echo "OpenGL sharedlibrary exists"

\rm $libdir/
\rm $libdir/

ln -s $nvlibdir/ $libdir/
ln -s %nvlibdir/ $libdir/
echo "NVIDIA sharedlibrary links restored."

Forum supervisor's picture

Hi Marco,
Thanks for your contribution.
The corresponding issue with ID = OCC22493 has been registered.
Later you can know if the patch is certified and integrated by checking references to the specified ID in OCCT Release Notes.

Sharjith Naramparambath's picture

The issue is clear. You have 64 bit system on which you have also installed the 32bit compatibility opengl libraries while installing the nvidia driver and now the linker is picking up the opengl libraries in /usr/lib instead of /usr/lib64. The solution is simple, you just need to reconfigure with the X include and library path pointing to /usr/lib64.