Package Details: ucon64 2.2.1-2

Git Clone URL: (read-only, click to copy)
Package Base: ucon64
Description: A ROM backup tool and emulator's Swiss Army knife program.
Upstream URL:
Keywords: backup emulator hacking programming rom
Licenses: GPL
Submitter: None
Maintainer: gammy
Last Packager: gammy
Votes: 4
Popularity: 0.000000
First Submitted: 2006-11-06 20:54
Last Updated: 2021-02-19 13:51

Latest Comments

1 2 Next › Last »

gammy commented on 2021-02-19 13:53

Added a minor update (bumping this package to 2.2.1-2) which downloads and applies another post-release patch: V64_send_gauge.patch. This patch amends a minor issue with the progressbar when dealing with the Doctor V64.

gammy commented on 2020-12-18 13:59

The package has been updated for ucon64 v2.2.1. A post-release patch affecting 64-bit systems is also pulled and applied. Another - AUR-specific - patch has been added to make a slight modification to the stock ucon64rc file for package backward-compatibility. Some hardening has also been applied. Thank you dbjh for helping out!

gammy commented on 2019-07-04 15:31

The package has been updated for ucon64 v2.2.0.

gammy commented on 2019-05-23 18:03

A quick update: I contacted dbjh who is currently the lead developer of ucon64, and he kindly fixed the issues mentioned by harpin, in SVN r2734. He also informed me that the cflags issue (which we also have a patch for in the package) has also been fixed. As soon as a new stable version of ucon64 is released, I will update this package and remove the patches.

harpin commented on 2019-05-19 12:20

Thank you, works great! I see with ldd that ucon64 is linked against on my machine. Bonus: your patches/explanations did help me learn a lot about make syntax ;)

gammy commented on 2019-05-19 10:46

harpin, 2.1.0-2 now hopefully solves your problem: If you have libieee1284, ucon64 is built with support for it. If not, it .. isn't. :) Let me know if you gave any issues!

gammy commented on 2019-05-17 13:19

I'm glad you found a workaround for now.

When I have some time (maybe tonight, but no guarantees!) I will write a patch (and include it + apply it in the package) so that the CD64 Makefile and code can use the shared library rather than the static one. Even if upstream doesn't want to change the code, it doesn't hurt for us to have this working correctly in arch/artix. If this works out, I will add libieee1284 as a depdendency as well.

Thanks for taking the time to point out a problem - without comments like yours, I would not have noticed!

harpin commented on 2019-05-17 12:15

Thank you very much for your time, very nice explanation!! libieee1284 is required by sane on my machine, so anybody who uses a scanner will have trouble building.

I have reinstalled the package by adding the following sed inside the PKGBUILD function prepare() to disable LIBIEEE1284 and force PPDEV. sed -i 's|^(LIBIEEE1284=1)|#\1|' ${pkgname}-${pkgver}-src/src/backup/libcd64/Makefile

Since the current integration of libieee1284 inside ucon64 (as of v2.1.0) cannot work on a default archlinux system with libieee1284 installed (unless manually building the static library libieee1284.a I guess). Is it safe to disable it and use PPDEV instead?

gammy commented on 2019-05-17 09:49

Hi harpin! I've tried to reproduce it here, but it builds just fine. libieee1284 is a parallel port communication library optionally used by the CD64 (Nintendo 64) backup code in ucon64. It looks like the cd64 code supports two parallel port libraries: One is libieee1284 (as a static library as you state), and the other is the standard linux ppdev parallel port library, part of the kernel.

Here's the code in src/backup/libcd64/Makefile:

feq ($(findstring Linux,$(OSTYPE)),Linux)
ifeq ($(shell if test -r /usr/include/ieee1284.h; then echo 1; else echo 0; fi),1) LIBIEEE1284=1
ifeq ($(shell if test -r /usr/include/linux/ppdev.h; then echo 1; else echo 0; fi),1) PPDEV=1

I'm not sure what extra functionality is provided by libeee1248, but it's certainly not required to build or run the CD64 component. My guess is that you for whatever reason happen to have the file /usr/include/ieee1284.h, and that this triggers the build files to use the static library, which you most likely do not have (and as you say, the libieee1284 library provided in arch/artix is in the form of a shared library, not a static library).

The fact that ucon64 uses a static library is an upstream issue and is either due to ucon64 being developed on a linux distribution which uses a static library version of libieee1284, or that the code is out of date or no longer maintained.

The solution (without losing cd64 support) is to remove the offending ieee1284 header; if you really don't have any ieee1284 library installed, then the file should not be there. This isn't a proper fix either though: If you have that file, you - on arch/artix - should have the shared library version of ieee1284, which ucon64 doesn't support at this time anyway. I could write a patch for it to use in the package (and suggest it be merged upstream), but I'm too busy to do it right now this minute.

Can you check if you have the aforementioned file, and check if a package actually owns it with "pacman -Fos /usr/include/ieee1284.h" ? I'd be interested to know.

harpin commented on 2019-05-14 20:57

It fails to build on my machine (x86_64): ld: cannot find /usr/lib/libieee1284.a: No such file or directory

This is because the option --with-libcd64 is added to configure. Even if I install libieee1284 manually it fails because libieee1284.a is not included in the package, only

I can build the package manually if I remove --with-libcd64. Can you reproduce?