Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
07-18-2013, 03:08 PM
|
#16
|
Member
Registered: Oct 2010
Location: Bowling Green, KY
Distribution: Slackware
Posts: 288
Rep:
|
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.
|
|
|
07-18-2013, 03:15 PM
|
#17
|
Member
Registered: Jul 2013
Distribution: Slackware 14 / current
Posts: 442
Original Poster
Rep:  
|
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.
Last edited by Geist; 07-18-2013 at 03:17 PM.
|
|
|
07-18-2013, 03:35 PM
|
#18
|
Member
Registered: May 2013
Location: Massachusetts
Distribution: Slackware, NetBSD, Debian, Sourcemage, 9front
Posts: 383
Rep: 
|
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.
|
|
|
07-18-2013, 03:45 PM
|
#19
|
Member
Registered: Jul 2013
Distribution: Slackware 14 / current
Posts: 442
Original Poster
Rep:  
|
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.
Last edited by Geist; 07-18-2013 at 03:53 PM.
|
|
|
07-18-2013, 03:52 PM
|
#20
|
Member
Registered: May 2013
Location: Massachusetts
Distribution: Slackware, NetBSD, Debian, Sourcemage, 9front
Posts: 383
Rep: 
|
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)?
|
|
1 members found this post helpful.
|
07-18-2013, 04:01 PM
|
#22
|
Member
Registered: May 2013
Location: Massachusetts
Distribution: Slackware, NetBSD, Debian, Sourcemage, 9front
Posts: 383
Rep: 
|
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?
|
|
|
07-18-2013, 04:10 PM
|
#23
|
Member
Registered: Jul 2013
Distribution: Slackware 14 / current
Posts: 442
Original Poster
Rep:  
|
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.
|
|
|
07-30-2013, 11:02 PM
|
#24
|
Senior Member
Registered: Nov 2008
Posts: 1,052
Rep: 
|
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!
|
|
|
08-01-2013, 12:16 PM
|
#25
|
Senior Member
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052
|
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
|
|
1 members found this post helpful.
|
09-04-2013, 03:38 AM
|
#26
|
Senior Member
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052
|
Hello,
I notified this issue to nvidia here. A bug has been (internally) filled for this.
--
SeB
|
|
1 members found this post helpful.
|
09-07-2013, 12:22 PM
|
#27
|
LQ Newbie
Registered: Dec 2012
Distribution: Slackware
Posts: 11
Rep: 
|
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
|
|
|
10-02-2013, 04:43 AM
|
#28
|
Senior Member
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052
|
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
|
|
1 members found this post helpful.
|
10-02-2013, 04:59 AM
|
#29
|
Member
Registered: Jul 2013
Distribution: Slackware 14 / current
Posts: 442
Original Poster
Rep:  
|
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. )
|
|
|
All times are GMT -5. The time now is 01:38 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|