Hi Kevin,
Okay, thanks. Guess I'm going to have to spend some time tonight
getting a Fedora VM up and running (or downloaded).
Ken
On 3/25/20 8:55 AM, Kevin Becker wrote:
I get the same error. To be clear, I did not exactly follow Brian's
instructions as I did not compile FLTK. I just installed it from the
Fedora repos.
On Wed, 2020-03-25 at 08:17 -0700, Ken Pettit wrote:
Hey Kevin,
Turns out I don't have a system on which the build fails, so it's
hard for me to test if I fixed it.
I noticed in Brian's GNUMakefile, he added the --ldflags option to
the fltk-config line. This is adding additional library support, and
the error "DSO missing..." usually means there is a missing library
option.
I have added the '--ldflags' to the GNUMakefile on SourceForge. Can
you do a 'git pull' and see if that fixes the problem?
Thanks,
Ken
On 3/25/20 7:43 AM, Kevin Becker wrote:
FWIW I can compile Brian's source on Fedora 31 using the distro
packaged version of FLTK with no issue but your official sourceforge
version errors out.
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libfltk.so:
undefined reference to symbol 'XRenderQueryExtension'
/usr/bin/ld: /usr/lib64/libXrender.so.1: error adding symbols: DSO
missing from command line
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:124: virtualt] Error 1
On Wed, 2020-03-25 at 07:27 -0700, Ken Pettit wrote:
Hey Guys,
Okay, I have fixed this bug (in src/file.cpp). The de-tokenizer
was not testing for quoted strings. I pushed the changes to the
git repo here if anyone wants to pull it and compile prior to an
official VT 1.8 release:
git clone https://git.code.sf.net/p/virtualt/code virtualt
Ken
On 3/25/20 12:23 AM, Peter Noeth wrote:
Does that include bug fixes from v1.7?
I sent Ken a PM back a while ago describing a bug I found, but got
no response.
The problem occurs when transferring a BASIC program from VirtualT
to the PC in ASCII format. The bug concerns any BASIC program that
uses embedded ASCII characters with the value greater than 127d
directly in PRINT statements. When these characters are used (for
example, the downward pointing triangle, 167d A7h), the ASCII
character value is not preserved in the saved output file, but
instead a BASIC keyword is substituted.
For example (+ character is really 167d, input with the keyboard
sequence [CODE]_ ):
A program containing the line:
11510 PRINT@280,"++";
is saved in the ASCII format output file as:
11510 PRINT@280,"GOTOGOTO";
I am not sure if the keyword GOTO is the actual substitution, as I
am away from my "development" computer and can verify, but it
illustrates the basic problem. Likely, as BASIC keywords are
probably represented as values higher than 127d, and the routine
in VirtualT to save a file on the PC in ASCII format is not
setting a flag to track the occurrences of the " character pairs
and interpret any characters within as ASCII characters and not
BASIC keywords.
Regards,
Peter
<snip>
Message: 10
Date: Tue, 24 Mar 2020 13:27:39 -0700
From: Ken Pettit <[email protected] <mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Subject: Re: [M100] Building VirtualT
Message-ID: <[email protected]
<mailto:[email protected]>>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hey Guys,
Steven Hurd also converted the SourceForge.net cvs repo to a
git repo.
Both he and I have been making updates to that repo. I am working
toward a VT 1.8 release.
Ken
<snip>
