SlackwareThis 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.
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.
I guess it worked without that line for some of us because we had the 32-bit compatibility libraries installed. When configure checked for the existence of those libraries, it found that they were there, but it actually found the 32-bit versions. And then it built the qt package with those libraries. The linker then of course managed to link to the correct ones, so the package was ok.
Just guessing, but maybe the Slackbuild also worked ok for Eric because he already had the compat32 support working, but then Pat rebuilt the package without that...
Yes, it may be the case. But I wonder how a 64bit lib could link to a 32bit lib... After all, it's weird...
Thanks Grissiom! That's a really weird one, since /usr/X11R6/lib64 == /usr/lib64 (it's just a symlink), and on an x86_64 Linux system /usr/lib64 _should_ be in the default search path, but as you've discovered qt3 needs to be told. I did verify that -L/usr/lib64 (or -L/usr/lib${LIBDIRSUFFIX}) works just as well. Anyway, thanks again! Very good detective work there.
Yes it should be. But it seems that some part of qt3 doesn't realize that it's in a x86_64 environment(it seek libs in /usr/X11R6/lib /usr/lib but not /usr/X11R6/lib64 /usr/lib64).... Anyway, it is good that qt4 is smarter
o_O Really? So is your newly built qt3 a 32bit lib or a 64bit lib? You can run qt3 programs flawlessly?
No, I had the 32 bit libs in the qt3 configure's default search path, but the multilib compiler correctly linked qt3 with the correct 64-bit versions. With out the extra flag, the qt3 configure will not see the libs and not build against them since it didn't look in lib64 for some reason.
At least that's what I understand of the situation.
The bug in the slackbuild script is still present in the -current tree, and it's TWO years later.
I'm still working with 13.0, but I DL'ed the code out of the current tree by mistake, and noticed that it will NOT build correctly without the '-L/usr/lib64' hack.
My system is still pure 64bit, so that triggered the configure bug again.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.