Hi, I'm not sure that the distro is as important as the version of FLTK that
comes with it. Some distros distribute older versions of packages than what
the developer built their application with. Anyway, just my 2 cents worth.
:-)Cheers, Bert
-------- Original message --------
From: Ken Pettit <petti...@gmail.com>
Date: 3/25/20 12:44 (GMT-06:00)
To: m100@lists.bitchin100.com
Subject: Re: [M100] Building VirtualT
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 <petti...@gmail.com>
To: m100@lists.bitchin100.com
Subject: Re: [M100] Building VirtualT
Message-ID: <5e7a6d3b.4020...@gmail.com>
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>
