@Narthorn, yeah now that you mention it, I can't get @Hcartiaux's solution to work either. I suppose you could mess around with LD_LIBRARY_PATH, but that variable may vary from distro to distro, unless it's part of some standard.
However, I'm not sure that adding a symlink meant for use by a single package to the LD_PATH is a super great idea since that means that anything and everything would be taking advantage of said symlink, as in if a library _actually_ could _only_ use version 5 of Ncurses and _not_ version 6, then it'd load the symlink just to crash because of the differences in the API.
Uhh... I don't know if I'll have a chance to get to this today, but... *sigh*, for now I'd recommend just uhh... run `downgrade libtinfo` and use the previous version, which should be 6-6. If that doesn't work for you, then just add the symlink either manually or (BETTER) to the libtinfo package and install it locally and whatnot.
Search Criteria
Package Details: epsxe 2.0.5-34
Package Actions
Git Clone URL: | https://aur.archlinux.org/epsxe.git (read-only, click to copy) |
---|---|
Package Base: | epsxe |
Description: | Enhanced PSX emulator |
Upstream URL: | https://epsxe.com |
Keywords: | emulator playstation |
Licenses: | unknown |
Conflicts: | bin32-epsxe |
Submitter: | None |
Maintainer: | hav3lock |
Last Packager: | hav3lock |
Votes: | 229 |
Popularity: | 0.39 |
First Submitted: | 2007-05-02 16:59 (UTC) |
Last Updated: | 2024-09-14 02:27 (UTC) |
Dependencies (18)
- bash (bash-devel-static-gitAUR, bash-devel-gitAUR, busybox-coreutilsAUR, bash-gitAUR)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classicAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR)
- libarchive (libarchive-gitAUR)
- libcanberra
- libcdio (libcdio-gitAUR)
- libcurl-compat (libcurl-http3-ngtcp2-compatAUR, libcurl-compat-gitAUR)
- libxt
- libxv
- ncurses (ncurses-gitAUR)
- openssl-1.0AUR
- sdl_ttf
- cmake (cmake-gitAUR) (make)
- intltool (make)
- mesa (mesa-minimal-gitAUR, mesa-gitAUR, mesa-amd-bc250AUR, mesa-wsl2-gitAUR, amdonly-gaming-mesa-gitAUR, mesa-amber) (make)
- nasm (nasm-gitAUR) (make)
- tar (tar-gitAUR, busybox-coreutilsAUR) (make)
- unzip (unzip-natspecAUR, unzip-zstdAUR) (make)
- valgrind (valgrind-gitAUR) (make)
Required by (5)
Sources (12)
- configure_ac.patch
- dfxvideo_cfg_c.patch
- epsxe.desktop
- epsxe.png
- epsxe.sh
- https://archive.org/download/archlinux_pkg_ncurses/ncurses-5.9_20141101-1-x86_64.pkg.tar.xz
- https://www.epsxe.com/files/ePSXe205linux_x64.zip
- https://www.epsxe.com/files/shaders.zip
- Makefile.patch
- pcsxr-1.9.95.tar.gz
- pcsxr-fix-undefined-operations.patch
- peopsxgl_gpu_c.patch
Latest Comments
« First ‹ Previous 1 .. 12 13 14 15 16 17 18 19 20 21 22 .. 33 Next › Last »
hav3lock commented on 2015-10-13 00:43 (UTC)
Narthorn commented on 2015-10-12 23:42 (UTC) (edited on 2015-10-12 23:42 (UTC) by Narthorn)
On my system, without /usr/lib/libncurses.so.5, epsxe will not run:
./epsxe: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
I cannot confirm what hcartiaux said in the comment on 2015-09-30 18:11. For me, just having symlinks in /opt/epsxe/ does NOT work. Putting a symlink to /usr/lib/libncursesw.so.6.0 in /usr/lib/libncurses.so.5 does work.
This looks like an upstream bug, though. They have to fix whatever strange hardcoded way of loading libs they have so that it looks in the right place for libncurses.so.5.
hav3lock commented on 2015-10-12 06:55 (UTC)
@threeofsix, I think that it was actually the libtinfo package causing the problems: epsxe doesn't install or create anything in /usr/lib; it creates a symlink to /usr/lib/libncursesw.so.6, but it shouldn't be doing anything close to the opposite of that.
Is this problem still happening with the latest update of libtinfo?
@FernandoBasso, sorry I never got to your comment, somehow the email mentioning that you posted never reached my eyes, lulz. What the crap, yeah, that does sound like an ncurses problem. With the latest changes to the libtinfo package and crap are you still having the same problem?
Like here's the thing guys, I'm running the latest version of all of my packages, a lot of the times none of this crap happens to me--that doesn't *necessarily* mean anything, though, since my system is probably an example of the ideal environment where everything that could go wrong _doesn't_.
Let me know if this is still happening--I have no way/idea how I would test this on my own.
threeofsix commented on 2015-10-12 01:01 (UTC)
I had the same problem as @FernandoBasso a couple weeks. The problem seemed to come from the fact that the package had rewritten /usr/lib/libncursesw.so.6 to symlink to /usr/lib/libtinfo.so.5 rather than /usr/lib/libncursesw.so.6.0. I uninstalled the package and was able to log back into my system.
Does anyone know if it is safe to reinstall?
FernandoBasso commented on 2015-10-03 11:54 (UTC) (edited on 2015-10-03 11:55 (UTC) by FernandoBasso)
The last update to this package made my system impossible to log into (even from tty). I had to use the live cd to move libtinfo.so.5 away because from the CD, if I did `pacman -r /path/to/arch/ -S bash ncurses` I would see the message “libncursesw and libtinfo.so.5 have the same soname but different type” (I don't remember it exactly).
It was easy to fix, but I can't rename that libtinfo.so.5 back and use the emulator, I guess.
hav3lock commented on 2015-10-01 20:40 (UTC)
@Yamakaky, sorry to be so grumpy about this--I'm having kind of a bad day; I apologize for letting external stresses influence how I treat yall at times. Even as awesome as I am--and I'm pretty awesome, lol--I'm still just as human and prone to being not so awesome as yall are.
All yall stay awesome now. Over and out. :P
hav3lock commented on 2015-10-01 20:36 (UTC)
@Yamakaky, okay, so epsxe absolutely **___requires___** the libncurses.so.5 symlink. If it isn't provided for in the epsxe package, then it must be provided by some other package: ncurses isn't providing this anymore, since its latest version bump. So here's what I can do:
1. provide the symlink in another package such as the libtinfo family, or create an entire package for a single symlink, such as a ncurses5 package, which won't even provide the 5th version of ncurses since it'll only provide a symlink to version 6.
2. I can remove the symlink from the PKGBUILD and add it somewhere else, like in the epsxe.sh file, but doing so will mean that the package database will have _no idea that the symlink exists_!
3. Or I can leave things as they are since they work just fine and that's really _all I care about_.
Not to be a jerk about this or anything, but epsxe isn't providing anything with the new symlink setup. A program would have to literally exist in the same directory as epsxe or actually be expecting to find an ncurses symlink in epsxe's install directory in order for it to take advantage of the symlink created in this package.
Yamakaky commented on 2015-10-01 19:32 (UTC)
You are not providing ncurses, so your pacakge should not contain this symlink.
hav3lock commented on 2015-09-30 20:39 (UTC)
Hey, no problem; I'll update the package and fix those symlinks in the next day or so. Thanks for pointing them out. @Hcartiaux @Yamakaky
hcartiaux commented on 2015-09-30 18:11 (UTC)
Hi hav3lock,
Thanks for your work on maintaining epsxe in arch, which is not an easy task...
I agree with Yamakaky, I think you should create these symlinks in /opt/epsxe/, I tested this and it works, there should be no risk of side effects.
case "$CARCH" in
('x86_64') ln -s /usr/lib32/libncursesw.so."${_lib32_ncurses}" "$pkgdir"/opt/${pkgname}/libncurses.so.5;
ln -s /usr/lib32/libtinfo.so "$pkgdir"/opt/${pkgname}/libtinfo.so.5;;
('i686') ln -s /usr/lib/libncursesw.so."${_ncurses}" "$pkgdir"/opt/${pkgname}/libncurses.so.5;;
Pinned Comments