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

WhiteWolf1776 · 07-18-2013, 02:08 PM

Geist,

I just pulled and built this myself on a multilib system... and it all built without editing of the slackbuild of any kind, just like it did for ponce.

I can see in your build log, it is for some reason linking the libGL against /usr/lib instead of /usr/lib64... but no idea why it would do that on your system and not on mine, unless your env is diff somehow, or you modified the slackbuild script in some way.

Sorry I can't help more, just not sure where to go from here... maybe try the #freenode irc channel where it's easier to ask 20 questions and figure out what's up with your system.

Geist · 07-18-2013, 02:15 PM

Whitewolf:
I didn't modify the slackbuild in the instance I pastebinned.
And yeah, I understand, it seems to be kind of a non intuitive problem. I checked out my environment (env/set) and didn't see anything strange, but I must admit that I am not exactly an expert.

Thank you for your time, though. I'm going to snoop around some more and then maybe check out ##slackware.

Cheers~!

Edit:
http://slackware.com/~alien/multilib/
I used the `fast track' approach to set up multilib.

thirdm · 07-18-2013, 02:35 PM

What value does sys_lib_search_path_spec have in /tmp/SBo/libva-0.31.1/libtool? You have a libGL in /usr/lib64 too?

I'm pretty fuzzy about how libtool works and reading 7000 line shell scripts will put you in the madhouse, but it looks like from here...

Quote:

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

... to here ...

Quote:

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

... libtool decides that -lGL ought to be expanded to /usr/lib/libGL.so. I haven't worked it all the way through, but I'm guessing libdrool takes the paths in sys_lib_search_path_spec to look for existence of libGL.so and expands that out to the full path of whatever it found first. Am I wrong?

I guess if you want a real treat you could try manually running ../libtool yourself with those arguments and with trace turned on.

Geist · 07-18-2013, 02:45 PM

thirdm:
sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-slackware-linux/4.7.1 /usr/lib64 /lib64 /usr/x86_64-slackware-linux/lib "
I got that value by cd'ing into /tmp/SBo/libva-0.31.1 followed by libtool --config | grep sys_lib_search_path_spec
(I don't have much experience with libtool, thus, I'm not sure if I am doing it right.)

I do have libGL files in /usr/lib64, though.

I wish I had more knowledge to deliver better cooperation.

Edit:
I just noticed that there was actually a file called `libtool' in the libva directory, after all.
I've loaded it into vim and searched around.
sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib /usr/x86_64-slackware-linux/lib /usr/lib64/seamonkey "
the sys_lib_search_path_spec is "/usr/lib64/gcc/x86_64-slackware-linux/4.7.1 /usr/lib64 /lib64 /usr/x86_64-slackware-linux/lib ", as well.

thirdm · 07-18-2013, 02:52 PM

That looks alright to me. Do you have a gl.pc file anywhere with a path to /usr/lib in it? Is there a libGL.so.la (libtool library) somewhere with /usr/lib in it? I only have my ISP's NetBSD machine in front of me and its libgl doesn't have .la at all, but it does have a gl.pc file. Maybe it's pkg_config throwing you off (at least as a proximate cause)?

Geist · 07-18-2013, 02:56 PM

http://pastebin.com/rAmqQdZx

is /usr/lib/libGL.la

http://pastebin.com/cqCmYg9R
is /usr/lib64/libGL.la

both have the libdir set to '/usr/lib'

could that be it?

thirdm · 07-18-2013, 03:01 PM

I think it could, especially the latter. So if you change the latter and try your link again, does it get by that error?

If so, I guess the next question is where this .la comes from and why does it have the wrong path?

Geist · 07-18-2013, 03:10 PM

thirdm:

I changed the value for libdir in /usr/lib64/libGL.la to '/usr/lib64' and the build completed correctly.

About why and how the wrong paths were generated? I don't really know. I actually did an uninstall / clean reinstall earlier, but thank you regardless. This was quite insightful, seeing how I know a little bit about something I, until now, knew nothing about

Still, I do vaguely remember there being something not right with the driver installation package when the 32 compat libraries are installed as well.
I'll hunt around for that, the circumstances were different, but the result was more or less the same. Hard to google for, though, I know that cause I've tried earlier, lol.

lpallard · 07-30-2013, 10:02 PM

Quote:

Originally Posted by Geist

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.

I confirm the fix mentioned by Geist in post 1 to work perfectly on Slackware64-14.0

Thanks Geist!

phenixia2003 · 08-01-2013, 11:16 AM

Hello,

I looked at this and I think something went wrong between 313.30 (the last with correctly installed libGL.la files) and 319.12 (the first, I guess, with badly installed libGL.la files). Indeed, I tried both of these driver in expert mode, and compared the resulting nvidia-installer.log about libGL.la files. I found this :

nvidia-installer.log (313.30)

Code:

-> Installing: /tmp/template-XyKbG6 --> /usr/lib64/libGL.la
-> Deleting: /tmp/template-XyKbG6
-> Installing: /tmp/template-bD194g --> /usr/lib/libGL.la
-> Deleting: /tmp/template-bD194g

Both of the libGL.la files have libdir set correctly.

nvidia-installer.log (319.12)

Code:

-> Installing: /tmp/template-9NrLsH --> /usr/lib64/libGL.la
-> Deleting: /tmp/template-9NrLsH
-> Installing: /tmp/template-SUR5Ev --> /usr/lib64/libGL.la
-> Deleting: /tmp/template-SUR5Ev

Here, I guess the 64-bit libGL.la is installed first, then the 32-bit (for compat32). But, the 32-bit libGL.la is put in the bad location and overwrites the 64-bit version.

At this point, I tried to install the 319.12, but I said no to the compat32. However, the nvidia-installer contains the same issue :

Code:

-> Installing: /tmp/template-HACVKO --> /usr/lib64/libGL.la
-> Deleting: /tmp/template-HACVKO
-> Installing: /tmp/template-69q8jK --> /usr/lib64/libGL.la
-> Deleting: /tmp/template-69q8jK

--
SeB

phenixia2003 · 09-04-2013, 02:38 AM

Hello,

I notified this issue to nvidia here. A bug has been (internally) filled for this.

--
SeB

qazo · 09-07-2013, 11:22 AM

i have to thank you guys for solving this problem, i have been trying to find out what was wrong for most of my day: trying to compile gtkglext. I also thought it could have been my multilib setup, never would have thought it was something that someone else did wrong. Thanks alot

phenixia2003 · 10-02-2013, 03:43 AM

Hello,

This issue is fixed in latest long live branch version (i.e 319.60) :

Quote:

Added support for the following GPU:

GeForce GTX 760 Ti OEM
Fixed a bug that could cause OpenGL applications to crash during the initialization of new threads.
Fixed a bug that caused the GPU and Memory clock frequencies for some PowerMizer performance levels on Kepler boards to be reported incorrectly in the nvidia-settings control panel.
Fixed a bug that caused the X server to fail to start on certain laptops when the boot display was on an external DisplayPort monitor, for example if the laptop was booted while the lid was closed.
Fixed a bug in nvidia-installer that caused the 32-bit libGL.la libtool library file to be installed to the wrong location.

--
SeB

Geist · 10-02-2013, 03:59 AM

Awesome! I'm going to test this right away, hopefully the driver itself will install now.
(I'm running the short lived branch at the moment because a (kernel, I think) update in current prevented me from using the long live one a couple of weeks ago, can't remember the details. )