[SOLVED] Building libav with 64 bit NVidia drivers 32bit compatibility drivers

Geist · 07-18-2013, 10:34 AM

64 bit, multilib Slackware 14 (current) with NVIDIA-Linux-x86_64-319.32.run here.

make[3]: Leaving directory `/tmp/build/tmp-libva/libva-0.32.0/va/egl'
make[2]: Leaving directory `/tmp/build/tmp-libva/libva-0.32.0/va/egl'
make[2]: Entering directory `/tmp/build/tmp-libva/libva-0.32.0/va'
CCLD libva-glx.la
/usr/lib/libGL.so: could not read symbols: File in wrong format
collect2: error: ld returned 1 exit status

Is what I am getting, both with SBo and alien slackbuilds, and regardless of LDFLAGS with /usr/lib64.
The reason I have the compat drivers is Wine.

Any help is appreciated and I will deliver any further infos, should they be requested.

Cheers!

-------------------------------------------------------------------------------------------
Fix:

NVidia installer messed up the libGL.la file located at /usr/lib64/libGL.la
Changing

Code:

# Libraries that this one depends upon.
dependency_libs=' -L/usr/X11R6/lib -lm -lXext -lX11 -ldl'


# Directory that this library needs to be installed in:
libdir='/usr/lib'

to

Code:

# Libraries that this one depends upon.
dependency_libs=' -L/usr/X11R6/lib64 -lm -lXext -lX11 -ldl'

# Directory that this library needs to be installed in:
libdir='/usr/lib64'

solved the problem.

WhiteWolf1776 · 07-18-2013, 10:43 AM

So you already followed this advice:

http://slackbuilds.org/faq/#multilib

and it still fails?

Can you put up the full package names for mesa on your system? Last time I saw this, and the slackbuilds.org fix didn't work, the person had compat32 and i486 mesa packages on their x64 slackware.

Geist · 07-18-2013, 10:47 AM

WhiteWolf1776:
Yes, I have followed that advice and it still fails, tried it with libsuffix and setting it to lib64 directly, no dice.

mesa-9.1.4-x86_64-1
mesa-compat32-9.1.2-x86_64-2compat32

Are my mesa packages.

So far this has been the only problematic package for me, had no troubles with multilib for anything else.

ponce · 07-18-2013, 11:39 AM

FYI, I just tried and building a package for libva works fine for me on slackware64-current with multilib and nvidia-driver (with 32bit libraries too) using SBo script.

WhiteWolf1776 · 07-18-2013, 11:50 AM

Only thing I see is that your mesa packages are out of sync... not sure how that would do this, but all of your compat32 packages should be in sync with your x64 packages.

Geist · 07-18-2013, 11:53 AM

Code:

ponce:
Hm.
I tried building it with the script without sbopkg and I'm getting the same make error.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm -I../va/x11 -DVA_DRIVERS_PATH=\"/usr/lib64/va/drivers\" -O2 -fPIC -MT va_compat.lo -MD -MP -MF .deps/va_compat.Tpo -c va_compat.c -o va_compat.o >/dev/null 2>&1
mv -f .deps/va_compat.Tpo .deps/va_compat.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -fPIC -version-info 1:3:0 -release 0.31.1.1 -no-undefined  -o libva.la -rpath /usr/lib64 va.lo va_trace.lo va_crystalhd.lo va_compat.lo  -ldl 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/va.o .libs/va_trace.o .libs/va_crystalhd.o .libs/va_compat.o   -ldl  -O2   -Wl,-soname -Wl,libva-0.31.1.1.so.1 -o .libs/libva-0.31.1.1.so.1.0.3
libtool: link: (cd ".libs" && rm -f "libva-0.31.1.1.so.1" && ln -s "libva-0.31.1.1.so.1.0.3" "libva-0.31.1.1.so.1")
libtool: link: (cd ".libs" && rm -f "libva.so" && ln -s "libva-0.31.1.1.so.1.0.3" "libva.so")
libtool: link: ar cru .libs/libva.a  va.o va_trace.o va_crystalhd.o va_compat.o
libtool: link: ranlib .libs/libva.a
libtool: link: ( cd ".libs" && rm -f "libva.la" && ln -s "../libva.la" "libva.la" )
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm   -I../va/x11 -DVA_DRIVERS_PATH="\"/usr/lib64/va/drivers\""    -O2 -fPIC -MT va_tpi.lo -MD -MP -MF .deps/va_tpi.Tpo -c -o va_tpi.lo va_tpi.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm -I../va/x11 -DVA_DRIVERS_PATH=\"/usr/lib64/va/drivers\" -O2 -fPIC -MT va_tpi.lo -MD -MP -MF .deps/va_tpi.Tpo -c va_tpi.c  -fPIC -DPIC -o .libs/va_tpi.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libdrm -I../va/x11 -DVA_DRIVERS_PATH=\"/usr/lib64/va/drivers\" -O2 -fPIC -MT va_tpi.lo -MD -MP -MF .deps/va_tpi.Tpo -c va_tpi.c -o va_tpi.o >/dev/null 2>&1
mv -f .deps/va_tpi.Tpo .deps/va_tpi.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -fPIC -version-info 1:3:0 -release 0.31.1.1 -no-undefined  -o libva-tpi.la -rpath /usr/lib64 va_tpi.lo libva.la -ldl 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/va_tpi.o   -Wl,-rpath -Wl,/tmp/SBo/libva-0.31.1/va/.libs -Wl,-rpath -Wl,/usr/lib64 ./.libs/libva.so -ldl  -O2   -Wl,-soname -Wl,libva-tpi-0.31.1.1.so.1 -o .libs/libva-tpi-0.31.1.1.so.1.0.3
libtool: link: (cd ".libs" && rm -f "libva-tpi-0.31.1.1.so.1" && ln -s "libva-tpi-0.31.1.1.so.1.0.3" "libva-tpi-0.31.1.1.so.1")
libtool: link: (cd ".libs" && rm -f "libva-tpi.so" && ln -s "libva-tpi-0.31.1.1.so.1.0.3" "libva-tpi.so")
libtool: link: ar cru .libs/libva-tpi.a  va_tpi.o
libtool: link: ranlib .libs/libva-tpi.a
libtool: link: ( cd ".libs" && rm -f "libva-tpi.la" && ln -s "../libva-tpi.la" "libva-tpi.la" )
/bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -fPIC -version-info 1:3:0 -release 0.31.1.1  -o libva-x11.la -rpath /usr/lib64  libva.la x11/libva_x11.la  -lX11   -lXext   -ldrm   -lXfixes   -ldl 
libtool: link: gcc -shared  -fPIC -DPIC  -Wl,--whole-archive x11/.libs/libva_x11.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/tmp/SBo/libva-0.31.1/va/.libs -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 ./.libs/libva.so /usr/lib64/libXext.so -L/usr/lib64 /usr/lib64/libdrm.so -lrt /usr/lib64/libXfixes.so /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so -ldl  -O2   -Wl,-soname -Wl,libva-x11-0.31.1.1.so.1 -o .libs/libva-x11-0.31.1.1.so.1.0.3
libtool: link: (cd ".libs" && rm -f "libva-x11-0.31.1.1.so.1" && ln -s "libva-x11-0.31.1.1.so.1.0.3" "libva-x11-0.31.1.1.so.1")
libtool: link: (cd ".libs" && rm -f "libva-x11.so" && ln -s "libva-x11-0.31.1.1.so.1.0.3" "libva-x11.so")
libtool: link: (cd .libs/libva-x11.lax/libva_x11.a && ar x "/tmp/SBo/libva-0.31.1/va/x11/.libs/libva_x11.a")
libtool: link: ar cru .libs/libva-x11.a   .libs/libva-x11.lax/libva_x11.a/dri1_util.o .libs/libva-x11.lax/libva_x11.a/dri2_util.o .libs/libva-x11.lax/libva_x11.a/va_dri.o .libs/libva-x11.lax/libva_x11.a/va_dri2.o .libs/libva-x11.lax/libva_x11.a/va_dricommon.o .libs/libva-x11.lax/libva_x11.a/va_fglrx.o .libs/libva-x11.lax/libva_x11.a/va_nvctrl.o .libs/libva-x11.lax/libva_x11.a/va_x11.o 
libtool: link: ranlib .libs/libva-x11.a
libtool: link: rm -fr .libs/libva-x11.lax
libtool: link: ( cd ".libs" && rm -f "libva-x11.la" && ln -s "../libva-x11.la" "libva-x11.la" )
/bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -fPIC -version-info 1:3:0 -release 0.31.1.1  -o libva-glx.la -rpath /usr/lib64  libva.la glx/libva_glx.la libva-x11.la -lX11 -lGL -ldl 
libtool: link: gcc -shared  -fPIC -DPIC  -Wl,--whole-archive glx/.libs/libva_glx.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/tmp/SBo/libva-0.31.1/va/.libs -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -L/tmp/SBo/libva-0.31.1/va/.libs ./.libs/libva.so ./.libs/libva-x11.so -L/usr/lib64 /tmp/SBo/libva-0.31.1/va/.libs/libva.so /usr/lib64/libdrm.so -lrt /usr/lib64/libXfixes.so /usr/lib64/libxcb.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so /usr/lib/libGL.so -L/usr/X11R6/lib -lm /usr/lib64/libXext.so /usr/lib64/libX11.so -ldl  -O2   -Wl,-soname -Wl,libva-glx-0.31.1.1.so.1 -o .libs/libva-glx-0.31.1.1.so.1.0.3
/usr/lib/libGL.so: could not read symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[3]: *** [libva-glx.la] Error 1
make[3]: Leaving directory `/tmp/SBo/libva-0.31.1/va'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/SBo/libva-0.31.1/va'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/libva-0.31.1'
make: *** [all] Error 2

And here a listing of some GL files in /usr/lib/
Not that I know if this helps.

-rwxr-xr-x 1 root root 1157 May 15 00:51 /usr/lib/libEGL.la
lrwxrwxrwx 1 root root 15 Jun 11 00:39 /usr/lib/libEGL.so -> libEGL.so.1.0.0
lrwxrwxrwx 1 root root 15 Jun 11 00:39 /usr/lib/libEGL.so.1 -> libEGL.so.1.0.0
-rwxr-xr-x 1 root root 118228 May 15 00:52 /usr/lib/libEGL.so.1.0.0
lrwxrwxrwx 1 root root 10 Jul 18 16:30 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 15 Jul 18 16:30 /usr/lib/libGL.so.1 -> libGL.so.319.32
-rwxr-xr-x 1 root root 989784 Jul 18 16:30 /usr/lib/libGL.so.319.32
-rw-r--r-- 1 root root 604410 Mar 18 22:43 /usr/lib/libGLEW.a
lrwxrwxrwx 1 root root 16 Jun 11 00:39 /usr/lib/libGLEW.so -> libGLEW.so.1.9.0
lrwxrwxrwx 1 root root 16 Jun 11 00:39 /usr/lib/libGLEW.so.1.9 -> libGLEW.so.1.9.0
-rw-r--r-- 1 root root 416680 Mar 18 22:43 /usr/lib/libGLEW.so.1.9.0
-rwxr-xr-x 1 root root 1215 Feb 22 00:33 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root 15 Jun 11 00:39 /usr/lib/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root 15 Jun 11 00:39 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 552632 Feb 22 00:33 /usr/lib/libGLU.so.1.3.1

Geist · 07-18-2013, 11:55 AM

Quote:

Originally Posted by WhiteWolf1776

Only thing I see is that your mesa packages are out of sync... not sure how that would do this, but all of your compat32 packages should be in sync with your x64 packages.

Oh... I did not notice that (I blame the scorching heat. :P ) I'm going to sync things up and try again, thanks~.

WhiteWolf1776 · 07-18-2013, 11:59 AM

If it still fails, mod the slackbuild script as below suggests... so far that is all I have had to do.

from here:
http://slackbuilds.org/faq/#multilib

18.I have problems compiling with my unofficial and unsupported multilib setup.

If you are using multilib packages from somewhere and also have some 32bit packages installed, then you might run into problems with the build process trying to link 32bit libraries instead of 64bit libraries. If this occurs, it can probably be solved by placing the following line:
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
after the lines for CFLAGS and CXXFLAGS passed to the configure script. In other words, make it look something like this:
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
./configure \
Beyond that, you are on your own. This is an unsupported setup.

ponce · 07-18-2013, 12:18 PM

here libva doesn't try linking using /usr/lib at all: maybe it's something related to your setup/shell environment.

Geist · 07-18-2013, 12:24 PM

ponce:
Interesting. Getting the compat packages up to date did not do the trick, even with the modifications WhiteWolf suggested.

I'll look into it. Maybe oh my zsh or one of my old, migrated bash files are mucking things up, thanks~ =)

Edit:
Still can't get it to work.
Is there something I could do to make it easier to diagnose what's going wrong?

Geist · 07-18-2013, 01:08 PM

By the way, I've always used the NVidia driver installer directly and not the slackbuild ones. Could that be affecting things?

WhiteWolf1776 · 07-18-2013, 01:25 PM

I just used the nvidia .run file for years... not really an issue...

getting back to simple tho... before you run the slackbuild you su to get root access (with a - to get it's env)... i.e.

su -
password:

then go to the directory with the slackbuild and ./<whatever>.SlackBuild

and you are using bash... ?

Just looking for the diff somewhere in here.

Geist · 07-18-2013, 01:32 PM

Whitewolf:
I see, hm.

But yeah, I used bash / login shell both with su - and a tty in single user mode.

WhiteWolf1776 · 07-18-2013, 01:43 PM

did you install the nvidia and say "YES" in the installer to loading 32 bit compatibility libraries? I remember there being that option... not sure of the effect to your current case tho.

Geist · 07-18-2013, 01:47 PM

Whitewolf:
Yes, I chose to install the compatibility libraries.

http://pastebin.com/GTCMrdqU

By the way, a full build log with http://slackbuilds.org/repository/14.0/libraries/libva/ ponce linked.

built from a tty, login shell, bash, pretty much vanilla settings, unless I have missed something.

edit:
If I hadn't installed the compatibility libraries then libav would build cleanly. I've done it before.
I might just ditch the compat libraries, but if it's possible to build it with them present, too, then that'd be nice, Wine, etc.
Does Wine need them, though?