Elkulator compilation on Kubuntu 13.10

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
Kecske Bak
Posts: 688
Joined: Wed Jul 13, 2005 7:03 am
Location: Treddle's Wharf, Chigley
Contact:

Elkulator compilation on Kubuntu 13.10

Post by Kecske Bak » Wed Jan 22, 2014 10:39 am

On Kubuntu 13.10 I've tried compiling Elkulator (both version 1 from the Elkulator site and the tip from the HG repository) and have run up against the same issue both times which prevents the build from completing. B-Em compiles with no problems at all.

Code: Select all

/usr/bin/ld: elkulator-tapenoise.o: undefined reference to symbol 'fmod@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [elkulator] Error 1
make[1]: Leaving directory `/home/kecskebak/.local/bin/elkulator-7a27d182e732/src'
make: *** [all-recursive] Error 1
I want to work on the Acorn Electron version of :?: for Retro Software at the moment, so any help anyone can give me with getting it to compile would be much appreciated.

EDIT: With thanks to DavidB I've now got all my problems with this sorted out.

First thing you need to do is to make all the symlinks to automake1.11 point to automake1.13 (or whatever version of automake you have installed if you don't have 1.11 installed). David says he'll fix this in configure.ac.

The next thing you need to do is add -lm to the /src/Makefile LIBS line. (interestingly, I had to do this twice, the first time you do this it seems to get overwritten). Again, David said he'll fix this issue as well.

When this is done Elkulator should build with no problems.

Many thanks to David for going to the time and trouble of fixing this for me so I could compile Elkulator. =D>

User avatar
davidb
Posts: 2070
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by davidb » Wed Jan 22, 2014 11:27 pm

This patch should hopefully fix the problem.

Good luck with development on :?:. :D
Attachments
missing_lm_linking.diff.zip
Fix linking to libm on Ubuntu 12.04 and later.
(414 Bytes) Downloaded 81 times

derek
Posts: 65
Joined: Thu May 07, 2015 7:31 pm
Location: Runcorn, UK
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by derek » Thu Jan 25, 2018 8:49 am

Hi,

I am trying to compile Elkulator on Mint 18.2 x64 Linux, which failed t compile with the same error.

I have Allegro 4.2.2 installed and have successfully compiled B-EM, ARCEM, RPCEM all work great.

How do I use the Diff file?
Regards,

Derek

User avatar
davidb
Posts: 2070
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by davidb » Thu Jan 25, 2018 10:06 am

Unzip the attachment somewhere and copy the diff file into the Elkulator directory, then from within that directory type the following:

Code: Select all

patch -p1 < missing_lm_linking.diff
You should see the following output:

Code: Select all

patching file configure.ac
Reconfigure the project with

Code: Select all

autoreconf
If this fails then you may need to run an additional command first:

Code: Select all

automake --add-missing
autoreconf
At this point you should be able to run the configuration process as usual.

Good luck! :D

derek
Posts: 65
Joined: Thu May 07, 2015 7:31 pm
Location: Runcorn, UK
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by derek » Sun Feb 04, 2018 10:25 am

Hi,

Thank you for the advice and information.

I am still still getting this error when running confugure:

Code: Select all

Elkulator/missing: Unknown `--is-lightweight' option
Try `Elkulator/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
I tried: autoreconf -fi

configure worked without error, but trying make, gave the following error:

Code: Select all

In file included from uef.c:8:0:
/usr/include/zlib.h:1313:21: note: expected ‘gzFile {aka struct gzFile_s *}’ but argument is of type ‘struct gzFile_s **’
 ZEXTERN int ZEXPORT gzread OF((gzFile file, voidp buf, unsigned len));
                     ^
uef.c:77:21: error: request for member ‘have’ in something not a structure or union
                     gzgetc(uef);
                     ^
uef.c:77:21: error: request for member ‘have’ in something not a structure or union
                     gzgetc(uef);
                     ^
uef.c:77:21: error: request for member ‘pos’ in something not a structure or union
                     gzgetc(uef);
                     ^
uef.c:77:21: error: request for member ‘next’ in something not a structure or union
                     gzgetc(uef);
                     ^
uef.c:77:28: warning: passing argument 1 of ‘gzgetc’ from incompatible pointer type [-Wincompatible-pointer-types]
                     gzgetc(uef);

Regards,

Derek

User avatar
davidb
Posts: 2070
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by davidb » Sun Feb 04, 2018 12:47 pm

I think I encountered this problem before. Either it's related to the version of zlib you have on your system or you need to update the Elkulator sources to include a fix.

Which version of zlib do you have installed? I have 1.2.8:

Code: Select all

$ dpkg -l | grep zlib
ii  zlib1g:amd64                          1:1.2.8.dfsg-2+b1                          amd64        compression library - runtime
ii  zlib1g-dev:amd64                      1:1.2.8.dfsg-2+b1
I don't know where the canonical version of Elkulator resides these days, otherwise I would recommend fetching that. In any case, look in the src/uef.c file and check line 15. If it says

Code: Select all

gzFile *uef;
then it needs to be changed to

Code: Select all

gzFile uef;
If all else fails, you can download the sources to my customised version of Elkulator from this page. Hopefully this will build more smoothly. ;)

derek
Posts: 65
Joined: Thu May 07, 2015 7:31 pm
Location: Runcorn, UK
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by derek » Mon Feb 05, 2018 9:12 am

Hi David,

I have the same version of zlib on my Linux Mint 18.2 x64 setup.

I looked at Line 15 in src/uef.c file, which was:

Code: Select all

gzFile *uef;
Changing the statement to:

Code: Select all

gzFile uef;
Made the emulator compile and run correctly,

Thank you for you help.
Regards,

Derek

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by ThomasHarte » Mon Feb 05, 2018 3:23 pm

If you were willing to try an alternative, I'd be really grateful for feedback on the build process. I'm not generally fantastic at Linux-type tasks.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by paulb » Mon Feb 05, 2018 3:42 pm

ThomasHarte wrote:If you were willing to try an alternative, I'd be really grateful for feedback on the build process. I'm not generally fantastic at Linux-type tasks.
Reminds me of the wrappers I did for ElectrEm (Classic and Future!) a few years ago now.

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by ThomasHarte » Mon Feb 05, 2018 3:55 pm

paulb wrote:
ThomasHarte wrote:If you were willing to try an alternative, I'd be really grateful for feedback on the build process. I'm not generally fantastic at Linux-type tasks.
Reminds me of the wrappers I did for ElectrEm (Classic and Future!) a few years ago now.
I'm still very grateful for those!

This time around I was very proud of myself for being able to offer a solution on my own at all. It's definitely worth the effort of supporting two platforms too, as GCC gives me yet another set of warnings that may well have fixed some latent bugs now but even if not will definitely have prevented some in the future*, and having to debug against a completely distinct OpenGL driver exposed a significant latent flaw in my handling of some shader stuff**. So it's probably pushed bit rot back a few years.

* specifically, the common C++ oversight of thinking that constructor initialisers run in the order that values are listed, not the order that the members are declared, though I'm treating C++11 as a floor so I mostly fixed this by switching to inline initialisation.
** the composite stuff is a multi-stage effort, and I was omitting binding of samplers to locations for anything beyond the first-stage shader. Luckily for me, the macOS GLSL compiler for the GPUs I've tested on happens to assign samplers to locations in the order they appear in the source code, which also happened to be the locations I was intending to provide. So no problem on the Mac. But undefined behaviour, and no output on Linux. That was a bit of a head scratcher.

derek
Posts: 65
Joined: Thu May 07, 2015 7:31 pm
Location: Runcorn, UK
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by derek » Sun Feb 11, 2018 11:20 am

ThomasHarte wrote:If you were willing to try an alternative, I'd be really grateful for feedback on the build process. I'm not generally fantastic at Linux-type tasks.
Hi Thomas,

I have downloaded and compiled clksignal okay, all works great when loading a Electon software images.

How do I just start the emulator without any software file. Giving the Basic prompt?
Regards,

Derek

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Elkulator compilation on Kubuntu 13.10

Post by ThomasHarte » Mon Feb 12, 2018 2:03 pm

As counter-intuitive as it may sound, there's currently no way to launch a machine just to have a machine. All launches are to use a piece of media.

So workarounds are to launch a utility ROM or an empty (but formatted) disk image. I've written myself a ticket, in brief for now but I'll improve it shortly, so this will be corrected.

(also, it doesn't currently disconnect your keyboard while typing a load command, so you can also just type random nonsense and cause CHAIN"" to turn into DCHASDFGDNIN"" or whatever, and short circuit the launch loop that way, but that's considered a bug)

In case you're curious, it's to do with the history of the thing and the primary audience: I decided that the main use case for an emulator is running software that already exists, and that the main causes of friction are the extra layer of interface and the assumption that users know anything about the computer they want to run the software of. Hence the mild reversal of the norm whereby you don't specify anything about a machine — even which machine you're talking about — you just provide the thing you want to run and let the emulator figure it all out. That's relatively easy on an Electron but quite a bit more effort elsewhere.

EDIT: oh, and drag and drop for replacing disks/tapes/etc works while the emulator is running. But tapes are currently read-only.

Post Reply