Build questions:
Behaviour questions:
FreeBSD questions:
As can be guessed by TnFOX's description - "TnFOX is a modern secure, robust, multithreaded, exception aware, internationalisable, portable GUI toolkit library designed for mission-critical work in C++ and Python" - Tn is also all those things, however it is also far, far more.
Tn came from the "Tornado" project, a name I had to drop thanks to Wind River Systems. I was most sorry to do so as it is a very apposite name - it engenders "revolution", "speed", "dynamism", "unpredictability" and it also means exactly the same thing in Spanish. All these things Tn will be.
I've still not answered the question, have I? Okay - Tn is a total rethink from the ground-up of how software should be structured. Inimical to this is a total rethink of how humans and computers should interface, as well as how computers should interface with each other. At an implementation level, Tn aims to be as good a quality of software as I know how to make it - secure, robust, scalable, internationalisable and portable.
You can find out more about Tn at http://www.nedprod.com/Tn/
BUILDING_TCOMMON
is defined.Not compiled:
config.py
and setting the disableGUI
variable to True
. The no GUI build consists merely of the TnFOX extensions to FOX and virtually no FOX code at all. Here's what you do get:
At the time of writing, the no-GUI build shrinks the binary as follows:
msvc7.1 (x86) gcc4.0.2 (x64) FOX v1.6 [1] : 2.59Mb 4.1Mb TnFOX v0.86 (no GUI) : 0.95Mb 1.6Mb TnFOX v0.86 (minimal) : 2.97Mb (+15%) 5.7Mb (+39%) TnFOX v0.86 (everything): 4.40Mb (+70%) 6.3Mb (+54%)
As you can see, GCC produces code between 68% and 91% larger for the same source. Newer versions of GCC should catch up with MSVC over time (indeed, it's already 50-60% better than with v3.3!)
The optional parts are as follows:
src/sqlite3
To fix, go to
C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\VisualStudio\7.1
and open the file VCComponents.dat
in a text editor. Replace with the following: [VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories] Path Dirs=$(PATH) Include Dirs=$(INCLUDE) Reference Dirs=$(FrameWorkDir)$(FrameWorkVersion) Library Dirs=$(LIB) Source Dirs=$(VCInstallDir)atlmfc\src\mfc;$(VCInstallDir)atlmfc\src\atl;$(VCInstallDir)crt\src
umask()
is completely ignored and on NT this is very different to the default of granting Everyone full control. Quite simply, this behaviour is by default much more secure for both you and your users. If it's a problem, you can always use the QFile::setPermissions() method to alter the permissions of a created file or indeed via the static method any arbitrary file.root
and set the suid and sgid bits. To do this (as root): chown root:root <executable name> chmod a+s <executable name>
famd
is always running as GNOME and KDE use it - however on FreeBSD to which it only became part of the main distribution recently, it is not running by default. TnFOX based applications will print the above warning at startup and will retry opening a FAM connection on first use of FX::FXFSMonitor but if it fails again, an exception will be returned.
The solution is to enable famd
. On FreeBSD v5.x, it gets more complicated as first you must create a port mapping in /etc/rpc
, get the port mapper daemon running (called rpcbind), then get inetd
configured and running and in theory, famd
will get invoked on demand. You should consult the documentation for FAM at http://oss.sgi.com/projects/fam/ and bear in mind that sysinstall can do most of the hard work for you in its post-install configure section (though you should manually tidy up /etc/rc
.conf regularly). If running inetd
is too risky for you (even with a configure file devoid of anything except famd
), it is possible to run famd
standalone - again, see the SGI documentation for more info.
Just to help you get going quicker:
For /etc/rpc
(already present on 5.x):
sgi_fam 391002 fam # file alteration monitor
/etc/inetd
.conf: sgi_fam/1-2 stream rpc/tcp wait root /usr/local/bin/fam fam
libc_r
.
What is happening is that the newer kernel scheduled (kse) POSIX threads is conflicting with the previous POSIX threads implementation in libc_r
- they cannot coexist within the same process space. TnFOX uses the newer kind exclusively but if you're getting this error then some dependent library has linked against libc_r
.
There are two solutions: (i) The slow solution is to use ldd
to find what shared object is importing libc_r
and recompile it to link against libpthread
or libkse
depending on your FreeBSD version. (ii) The fast solution is to permanently prevent libc_r
from ever being used again on your system no matter what - to do this, open /etc/libmap
.conf and map libc_r.so to libpthread.so or libkse.so - see man libmap.conf
for more.