Package Details: mudlet 4.17.1-1

Git Clone URL: https://aur.archlinux.org/mudlet.git (read-only, click to copy)
Package Base: mudlet
Description: A modern MUD client with a graphical user inteface and built in Lua scripting
Upstream URL: http://www.mudlet.org
Keywords: client games mud
Licenses: GPL
Submitter: None
Maintainer: Xabre
Last Packager: Xabre
Votes: 22
Popularity: 0.003126
First Submitted: 2009-03-14 03:05 (UTC)
Last Updated: 2023-03-29 12:44 (UTC)

Dependencies (20)

Required by (0)

Sources (1)

Latest Comments

1 2 3 4 5 6 .. 12 Next › Last »

Xabre commented on 2023-03-19 18:38 (UTC)

Mudlet 4.17, full changelog here https://github.com/Mudlet/Mudlet/releases/tag/Mudlet-4.17.0

Xabre commented on 2023-02-28 10:09 (UTC) (edited on 2023-02-28 10:10 (UTC) by Xabre)

@kalrykh It should compile as-is on ARM system, yes. I never included it in arch= area because: 1) ArchARM is a separate distro and derivative distributions were always a bit tricky issue on Arch and 2) I simply don't have and don't use an ARM system so it would be wrong and misleading to state that something works when I am not able to test and compile it myself. But, nothing should stop you from compiling and testing it on your own. Be aware that Mudlet's 3D mapper (at least used to) can create problems due to the state of OpenGL drivers on ARM systems, so if you run into the problem of it crashing Mudlet during running try compiling with WITH_3DMAPPER=NO switch. :)

kalrykh commented on 2023-02-28 04:04 (UTC)

Not sure if it matters, but FYI -- I'm on an aarch64 system. When I build this with yay, it tells me my architecture isn't supported and asks if I want to try to build it anyway...and everything builds/runs fine. Wasn't sure if the PKGBUILD could be updated to include aarch64 or not, but even if not, thought I'd leave this here to let people know it seems to work fine.

Xabre commented on 2022-06-16 19:20 (UTC) (edited on 2022-06-16 19:27 (UTC) by Xabre)

Glad you got it to work, as I honestly have no idea what's it all about. However, might I suggest that you check if you have and old makepkg.conf file that contains some old stuff cause my makepkg.conf doesn't have anything about -fuse-ld in it (you said you changed lld to ld, I have neither there) (btw, the differnce is that ld is gcc linker, lld is llvm linker specifically for clang, so I think they should not be mixed

jeois commented on 2022-06-16 19:03 (UTC)

I fixed it by changing "-fuse-ld=lld" to "-fuse-ld=ld" in /etc/makepkg.conf I have no idea what the difference between those linkers are, but it seems to be working now :)

jeois commented on 2022-06-16 18:47 (UTC)

Thanks for checking, and I'm not worried about the warnings either. It seems to create the files and then the last g++ command to create the package fails.

https://pastebin.com/r0rMrifW

As you can see, it's calling g++ even though my makepkg.conf says to use clang, so it's probably not the compiler choice per se. Specifically, I think it's this parameter: -fuse-ld=lld but I'm not sure how to get rid of it using yay, paru or pamac. For now, I'll just use the appimage binary, even though I have to set my firewall every time for it.

Xabre commented on 2022-06-16 12:58 (UTC) (edited on 2022-06-16 13:00 (UTC) by Xabre)

Ok, successfully compiled using gcc, installed and it seems to work. Successfully compiled using clang/llvm, installed, seems to work. Yes, compiler in both cases throws a lot of warnings, but it's been like that for years (and every new release adds a few more) So, I know that 'It Works For Me' is not the answer you were hoping for, but I'll need at least a full build log to investigate what gave you that error. Try using GCC instead of Clang, see if it makes any difference. P.S. Using standard Arch, currently with [testing] enabled for Plasma 5.25 goodies.

Xabre commented on 2022-06-16 12:20 (UTC)

Will check, not sure what it might be

jeois commented on 2022-06-16 12:14 (UTC)

Thanks for updating/maintaining...

I'm having trouble compiling; it throws this error:

ld.lld: error: undefined symbol: main
>>> referenced by start.S:103 (../sysdeps/x86_64/start.S:103)
>>>               /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/Scrt1.o:(_start)
collect2: error: ld returned 1 exit status
make: *** [Makefile:1684: mudlet] Error 1

Perhaps it's because my compiler is llvm instead of gcc? it should still call the correct one. The git package throws the same error. I can't find any issues related to this error on upstream source. qt update broke it? Any ideas?

Xabre commented on 2022-02-01 20:35 (UTC)

Mudlet 4.15, changelog here: https://www.mudlet.org/2022/02/4-15-gifs-music-shortcuts-n-more/

1 2 3 4 5 6 .. 12 Next › Last »