You are not logged in.
Hello,
in order to run a third party closed source software, I needed to
ln -s /usr/lib32/libjpeg.so /usr/lib32/libjpeg.so.62
In order not to do this by hand in the future, I'd like to make this by the PKGBUILD. But as far as I can see, the PKGBUILD script is only about files inside the package, not outside of them.
So is there a clean way to include
ln -s /usr/lib32/libjpeg.so /usr/lib32/libjpeg.so.62
in a PKGBUILD?
Thanks!
Last edited by Carl Karl (2013-11-08 00:42:54)
Offline
You ought not do this. Certainly, you mustn't do this if you plan to share the pkgbuild with others. Even if you only plan to use it yourself, it is a really bad idea.
This can be done. At least, not that exact command. But the equivalent. But I personally think that if you don't know how to do it, there is all the more reason you shouldn't do it since you probably have no idea of the sorts of trouble this is likely to cause. This just isn't the right way to solve the problem.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
This can be done. At least, not that exact command. But the equivalent.
Thinking a bit more about it I found the way, thanks for that hint.
You ought not do this. Certainly, you mustn't do this if you plan to share the pkgbuild with others. Even if you only plan to use it yourself, it is a really bad idea.
But I personally think that if you don't know how to do it, there is all the more reason you shouldn't do it since you probably have no idea of the sorts of trouble this is likely to cause. This just isn't the right way to solve the problem.
I really understood what's your opinion on that (and you're right, this is not for the AUR), but you're right:
you probably have no idea of the sorts of trouble this is likely to cause.
Yes, I don't know, so I can't fully understand your opinion.
And I don't know what the alternative is. Leaving out the symlink leads to:
error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
And as I said, it is unfortunately closed source (and I need it for my job), so what's the alternative?
I heard here, that unmanaged files are more or less the worst thing you can do, so including that symlink in the package makes it at least managed by pacman....
Last edited by Carl Karl (2013-11-07 06:04:06)
Offline
The correct alternative is to build and install the correct version of libjpeg alongside of the current one.
Edit, I'm guessing it's here: https://aur.archlinux.org/packages/libjpeg6/ or even better: https://aur.archlinux.org/packages/libjpeg6-turbo/
Last edited by Scimmia (2013-11-07 06:21:29)
Offline
@Scimmia:
Been there, done that. No use, still
error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
with both packages you mentioned.
(Perhaps I should at that the closed source 3rd party application is a 32bit program without having a 64bit equivalent, so therefore the /usr/lib32 path is needed.)
Offline
Actually this seems to be the AUR package that should be built (though I'm at work and can't test it just yet to be sure) https://aur.archlinux.org/packages/lib32-libjpeg6/
Offline
@mcmillan:
Great, that works, thanks!
How can one find the matching package?
Last edited by Carl Karl (2013-11-07 17:25:20)
Offline
Sorry. I didn't mean to be so mysterious. Basically it hides a problem and it can cause further problems. So the application you do it for believes that it has a certain version of the library but it doesn't which could well cause weird failures, even if it does compile. Once that symbolic link is in your system, moreover, anything else you compile can potentially find it and try to compile against it. Suppose you were building something which did something conditionally e.g. "if we find version X of lib Y, assume A; if we find version Z of lib Y, assume B" or which just depended on a particular version of the library. Now you will have silent errors building up in the stuff you are compiling, even though it has nothing to do with the original application you installed the work around for.
There may be other reasons it is bad, too, which I don't know about. That's the stuff I know about.
Anyway, I'm certainly glad you found a better solution. As for finding packages, you could just search AUR using the web interface or you could use something like cower. In this case, you could try, for example:
$ cower -s lib32-libjpeg
aur/lib32-libjpeg6 6b1-1 (392)
Legacy version of Library of JPEG support functions (32 bit)
aur/lib32-libjpeg6-turbo 1.2.1-1 (12)
libjpeg derivative with accelerated baseline JPEG compression and decompression
aur/lib32-libjpeg7 7-3 (19)
Library of JPEG support functions, version 7 (32 bit)
32 bit libraries for 64 bit systems all start lib32- so that's why I searched on lib32-libjpeg rather than just libjpeg. cower is an extremely useful, minimal and lightweight AUR helper. Obviously, you could use another AUR helper if you liked - cower is just my favourite.
Last edited by cfr (2013-11-07 22:57:34)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
@cfr
many thanks for your really useful answer! I didn't know of cower before and so.
Offline