(1) Successfully build and installed following from source-code:
tcl
tclx
tcllauncher
(2) Build piaware from source code.
(3) Tested piaware, found it requires tls .
Checked, found tcl is already installed.
What a mess
[abcd@localhost ~]$ piaware
can't find package tls
while executing
"package require tls"
(file "/usr/lib/piaware_packages/piaware.tcl" line 9)
invoked from within
"source /usr/lib/piaware_packages/piaware.tcl"
("package ifneeded piaware 1.0" script)
invoked from within
"package require piaware"
(file "/usr/lib/piaware/main.tcl" line 10)
invoked from within
"source /usr/lib/piaware/main.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 source $path"
from tcllauncher running "piaware"
[abcd@localhost ~]$ sudo dnf install tcl
Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - BaseOS 6.5 kB/s | 4.1 kB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStre 8.4 kB/s | 4.5 kB 00:00
Package tcl-1:8.6.8-2.el8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[abcd@localhost ~]$ sudo dnf install tls
[sudo] password for abcd:
Updating Subscription Management repositories.
Last metadata expiration check: 0:28:35 ago on Mon 17 Feb 2020 03:35:01 PM EST.
No match for argument: tls
Error: Unable to find a match: tls
Tried to build tcltls from source-code, failed, wants openssl:
$ wget https://core.tcl-lang.org/tcltls/uv/tcltls-1.7.20.tar.gz
$ sudo tar zxvf tcltls-1.7.20.tar.gz
$ cd tcltls-1.7.20
$ sudo ./configure
... ... ...
... ... ...
checking which TLS library to use... openssl
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'virtual:world', not found
configure: error: Unable to get OpenSSL Configuration
[abcd@localhost tcltls-1.7.20]$ sudo make
make: *** No targets specified and no makefile found. Stop.
Checked openssl, found it is already installed:
[abcd@localhost ~]$ sudo dnf install openssl
Updating Subscription Management repositories.
Last metadata expiration check: 0:27:46 ago on Mon 17 Feb 2020 03:05:51 PM EST.
Package openssl-1:1.1.1c-2.el8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
Part of the problem is that Tcl packages built from source are not automatically linked to the RPM based Tcl8.6 install, so you have link them in manually. I am working on a Rocky Linux installer, but until I am done these instructions should be sufficient to get anyone on an RPM based system going. I have only tested them on Rocky Linux 9.2, so things may vary on other RPM based systems.
Install the following RPM packages via yum or dnf:
The rest has to be built and installed manually. First start with rtl-sdr, and then move on to dump1090-fa.
Look in the debian subdirectories of the dump1090 and rtl-sdr repositories for clues on how things are expected to land. The faup1090 binary is not built automatically when you build dump1090, so you have to run make faup1090 manually.
Install tclx:
git clone https://github.com/flightaware/tclx.git
cd tclx
./configure
make
sudo make install
sudo ln -s /usr/lib/tclx8.6 /usr/share/tcl8.6
cd ..
Install tcllauncher:
git clone https://github.com/flightaware/tcllauncher.git
cd tcllauncher
autoconf
./configure --prefix=/opt/tcl
make
sudo make install
sudo ln -s /usr/lib/Tcllauncher1.10 /usr/share/tcl8.6
cd ..
Install itcl:
git clone https://github.com/tcltk/itcl.git
cd itcl
./configure
make all
make test
ln -s itclWidget/tclconfig tclconfig
sudo make install
sudo ln -s /usr/lib/itcl4.2.3 /usr/share/tcl8.6
cd ..
Install mlat-client:
git clone https://github.com/mutability/mlat-client.git
cd mlat-client
./setup.py build
./setup.py install
cd ..
Noted following strange messages in Piaware log:
(1) sudo required
(1) dump1090-fa is shown as “unknown process”
Any idea what I missed or did wrong? Thank you in advance.
[abcd@fedora-37 ~]$ sudo journalctl -u piaware -b
Feb 17 09:13:47 fedora-37 piaware[889]: FlightAware server certificate validated
Feb 17 09:13:47 fedora-37 piaware[889]: encrypted session established with FlightAware
Feb 17 09:13:49 fedora-37 piaware[1013]: sudo: a password is required
Feb 17 09:13:49 fedora-37 piaware[889]: ADS-B data program 'unknown process' is listening on port 30005>
Feb 17 09:13:49 fedora-37 piaware[889]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-i>
Feb 17 09:13:50 fedora-37 piaware[889]: Started faup1090 (pid 1021) to connect to unknown process
When I checked logs on Rapberry Pi, I got following:
Feb 17 09:27:56 raspi-1 sudo[1451]: piaware : PWD=/ ; USER=root ; COMMAND=/bin/netstat --pr>
Feb 17 09:27:56 raspi-1 sudo[1451]: pam_unix(sudo:session): session opened for user root(uid>
Feb 17 09:27:56 raspi-1 sudo[1451]: pam_unix(sudo:session): session closed for user root
Feb 17 09:27:56 raspi-1 piaware[1061]: Starting multilateration client: /usr/lib/piaware/hel>
Feb 17 09:27:56 raspi-1 sudo[1472]: piaware : PWD=/ ; USER=root ; COMMAND=/bin/netstat --pr>
Feb 17 09:27:56 raspi-1 sudo[1472]: pam_unix(sudo:session): session opened for user root(uid>
Feb 17 09:27:56 raspi-1 sudo[1472]: pam_unix(sudo:session): session closed for user root
Feb 17 09:27:56 raspi-1 piaware[1061]: ADS-B data program 'dump1090-fa' is listening on port>
Feb 17 09:27:56 raspi-1 piaware[1061]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 >
EDIT: [SOLVED]
Have missed following command. After issueing it and rebooting, both issues were fixed
Error Message:
./generic/tclXbsearch.c: In function ‘TclX_BsearchObjCmd’:
./generic/tclXbsearch.c:346:28: error: ‘TCL_PARSE_PART1’ undeclared (first use in this function); did you mean ‘TCL_PARSE_SYNTAX’?
346 | TCL_PARSE_PART1|TCL_LEAVE_ERR_MSG) == NULL) {
| ^~~~~~~~~~~~~~~
| TCL_PARSE_SYNTAX
./generic/tclXbsearch.c:346:28: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:288: tclXbsearch.o] Error 1
Later Addition:
I am not a prorammer, so made a Google search for the error. AI immediately jumped in and gave following responce, which went over my head:
Yes, indeed it is an issue.
After tclx failed to built from source code, I found it is available in repository, so I was very happy and installed it by command sudo dnf install tclx
However when piaware started, it failed, and error messages said two things:
(1) can’t find package Tclx (although dnf list tclx said “installed” )
(2) version conflict for package “tcl”: have 9.0.2, need 8.1
Nov 03 16:59:59 Fedora-43 systemd[1]: piaware.service: Failed with result 'exit-code'.
Nov 03 17:00:29 Fedora-43 systemd[1]: piaware.service: Scheduled restart job, restart counter is at 9.
Nov 03 17:00:29 Fedora-43 systemd[1]: Started piaware.service - FlightAware ADS-B uploader.
Nov 03 17:00:29 Fedora-43 piaware[1122]: application-specific initialization failed: version conflict for package "tcl": have 9.0.2, need 8.1
Nov 03 17:00:29 Fedora-43 piaware[1122]: can't find package Tclx
Nov 03 17:00:29 Fedora-43 piaware[1122]: while executing
Nov 03 17:00:29 Fedora-43 piaware[1122]: "package require Tclx"
Nov 03 17:00:29 Fedora-43 piaware[1122]: (file "/usr/lib/Tcllauncher1.10/tcllauncher.tcl" line 5)
Nov 03 17:00:29 Fedora-43 systemd[1]: piaware.service: Main process exited, code=exited, status=1/FAILURE
Nov 03 17:00:29 Fedora-43 systemd[1]: piaware.service: Failed with result 'exit-code'.
There was a blog post last year about how FA is moving away from Tcl as it no longer meets their needs. There is no mention if/how/when this impacts their feeder software, but one has to assume it will happen sometime.
Your aproach was greate and worked on ver 9.2 & 9.6. of Rocky, Alma, CentOSStream, and Fedora 37 & 41. I wrote installation scripts for dump1090-fa & piaware, and posted these on GitHub at that time after testing on all above noted distros.
However recently released ver 10 of Rocky, Alma and Cent have following two problems:
PROBLEMS:
Packages tcltls and tcllib are no more available in version 10 repositories of Rocky, Alma, and CentStream
Version 9 were using python3.11, but version 10 are using python3.12 or python3.13. Since ver 3.12, module asyncore has been depricated and removed. As a result fa-mlat-client fails at runtime. Solution is to install package python3-pyasyncore, but it is NOT availabble in repository.of version 10 of above distros.
SOLUTIONS:
Download version 9 rpm packages from Fedora package archives and install these. The version 9 packages work OK on version 10
Few days ago I have updated automated installation scripts (written in 2023) for version 9, and incorporated above noted changes, so these are now suitable for versions 9 &10 both.
Tcl 9.0 has significant compatibility issues with Tclx 8.4.
Tcl 9.0 introduces major, backwards-incompatible changes to the core Tcl language and its C APIs, which prevents older extensions like Tclx 8.4 from working correctly without modification or recompilation.
Key issues and reasons for incompatibility include:
Version Mismatch and Auto-loading: Tcl 9.0 interpreters do not automatically look in the Tcl 8.x directories for packages. The pkgIndex.tcl file for Tclx 8.4 often explicitly checks for Tcl version 8.4, preventing it from loading in a Tcl 9.0 environment.
C API Changes (Stubs Mechanism): Extensions using the Tcl C APIs, as Tclx 8.4 does, need to be recompiled against the Tcl 9.0 stubs library and potentially modified to accommodate API changes. Trying to load a Tclx 8.4 shared library (.so file) into a Tcl 9.0 interpreter will likely result in an “incompatible stubs mechanism” error or an “invalid ELF header” error due to fundamental changes in how libraries are linked and loaded across major versions.
Language and Encoding Changes: Tcl 9.0 changed default behaviors for things like channel encoding (defaulting to strict UTF-8 instead of the Tcl 8.x “tcl8” profile), which can break scripts relying on older behaviors. While Tcl 9.0 aims to have a Tcl-level compatibility mode for scripts, C extensions still face binary compatibility issues.
Deprecated Features Removal: Tcl 9.0 removed several commands and subcommands that were deprecated in Tcl 8.4 (e.g., trace variable, trace vdelete), so Tclx commands relying on these removed features will fail.
Solution:
To use Tclx with Tcl 9.0, you need a version of Tclx that has been explicitly ported to Tcl 9.0. Check the official Tclx homepage or relevant package repositories for a Tcl 9.0 compatible release.
If a Tcl 9.0-compatible Tclx is not available, you may need to use Tcl 8.6 (the current stable release before 9.0) or utilize a compatibility package if provided by your operating system distributor (e.g., tcl8 on Fedora Linux).
Porting code to Tcl 9
Many Tcl programs written for Tcl 8 will run unchanged in Tcl 9. Many more Tcl programs can be modified in small and simple ways to produce a new program that runs in both Tcl 8 and Tcl 9. Extensions and applications using the public Tcl C APIs will involve more effort, but it is still within reasonable reach to produce source code supporting both Tcl 8 and Tcl 9 while both releases remain in widespread use.
Tk 9.0.0 does not support Tcl 8.6. Tk 9.0.0 extends Tcl 9.0.0. To make use of Tk 9.0.0, first the new Tcl release, Tcl 9.0.0, needs to be present. As new Tk features are developed, expect them to appear in Tk 9, but not necessarily in Tk 8.6.
See the following links for an accumulation of migration advice:
)