|
|
| Home > Programming > |
FAQ: BETA Programming Language (version 1.11 - 08 Dec 97) |
Section 6 of 6 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6
95. It aborts with an "Illegal Instruction" error.
+ You need to obtain the TLINK32.EXE linker (version 1.50),
which is part of the Borland C++ (version >= 4.5).
Make:
+ MAKE.EXE, which is included in the above Assembler package
from Borland, and is also part of Borland C++ (version >=
4.5).
C libraries:
+ must be obtained from e.g. Borland C++ (version >= 4.5).
If you have installed Borland C++ for Windows 95/NT, version 4.5 or
later, all you need to install additionally is Borland Assembler
(available from Borland).
You can purchase these utilities from either Microsoft
(http://www.microsoft.com/) or Borland(http://www.borland.com/). Please
contact their national representatives for ordering information.
----------------------------------------------------------------------------
W03) Why do I need a MAKE facility?
Question:
I do not have a MAKE facility on my Windows 95/NT machine. Why do I need
that - I thought that the BETA compiler analyzed the dependencies itself?
Answer:
The BETA compiler keeps track of dependencies between all involved beta
files. However, if you want to link in object files generated by an external
C compiler og assembler, you may add a MAKE property to make the BETA
compiler invoke the make-facility to keep the external objectfiles
up-to-date (see section 2.4 in "The Mjolner System - Using on Windows 95 /
Windows NT [mia94-32]).
If you do not use the MAKE property in your programs, in principle you do
not need a make facility. But since a few of the standard libraries included
in the Mjolner System contains such MAKE properties, you will need a
make-facility anyway. However, since all external object files in the
standard libraries are up-to-date when distributed by Mjolner Informatics,
you can do with a dummy make-utility.
For instance you may create a C file like this:
main()
{
exit(0);
}
compile it with your C compiler, and install it in your path with the name
MAKE.EXE (if you use the Borland SDK) or NMAKE.EXE (if you use the Microsoft
SDK).
----------------------------------------------------------------------------
W04) Error in directory scan using Borland SDK? [corrected in r4.0]
Question:
Why does the following program fail with a memory exception on my windows
95/NT machine? I am using v5.1(6) of the compiler and SDK=bor.
ORIGIN '~beta/basiclib/v1.4/directory';
--PROGRAM:descriptor--
(# d: @directory;
do '.' -> d.name;
d.scanEntries
(#
do select
(# whenDir::<
(# do (theDir).entry.path.name -> screen.putline #);
#);
#);
#)
Answer:
This is due to an error in the directory library. The problem is, that the
file %betalib%\sysutils\v1.4\private\nti\bor\directory_ntbody.obj in the
release 3.1 distribution of the Mjolner System has been compiled with an
older version of the compiler. The solution is to delete the obj-file and
recompile %betalib%\sysutils\v1.4\private\directory_ntbody.bet.
----------------------------------------------------------------------------
W05) Make-error for lazyref_gc.c using Borland SDK? [corrected in r4.0.2]
Question:
When I use persistentstore or objectserver in my Windows 95/NT application I
get this error from the compiler:
MAKE Version 3.7 Copyright (c) 1987, 1994 Borland International
Fatal: 'c:\beta\betarun\v2.7\nti\c\lazyref_gc.c' does not exist -
don't know how to make it
I have installed BETA in C:\BETA.
Answer:
The reason is that there were some problems to get the two make facilities
from Microsoft and Borland to work with BETA. The solution was to handle the
lazyref_gc.c file specially in the make files. However, the lazyref_gc.c
file is part of the source code for the BETA runtime system, which is not
distributed with the release.
Solution:
Create a dummy lazyref_gc.c and update timestamp of corresponding .obj file.
This can be done by compiling and executing the following program:
ORIGIN '~beta/basiclib/v1.4/directory';
INCLUDE '~beta/sysutils/v1.4/envstring';
--PROGRAM: descriptor--
(# d: @directory;
f: @file;
do ' Create directory for C file ' -> putline;
'$(BETALIB)/betarun/v2.7/nti/C' -> expandEnvVar -> d.name;
(if not d.entry.exists then d.touch if);
' Create dummy C file ' -> putline;
'/lazyref_gc.c' -> ((d.name).copy).append -> f.name;
(if not f.entry.exists then f.touch if);
' Update timestamp of dependant object file ' -> putline;
'$(BETALIB)/objectserver/v2.1/private/nti/$(SDK)/lazyref_gc.obj'
-> expandEnvVar -> f.name;
f.touch;
#)
----------------------------------------------------------------------------
W06) Known bugs, limitations and inconveniences in release 4.0.2
1. Most parts of systemenv are still not implemented. Most of the demos in
demo\basiclib\systemenv fails. Specificly using the operation
"keyboard.get" will block.
2. Process and socket communication is currently NOT supported. It may
work, but known errors exist in these modules. These modules have been
scheduled for re-structuring. It is possible, though not likely, that
the interface specification changes.
3. Binary/ASCII files has a work-around (kluge) to compensate for a bug(?)
in Windows NT/95. If a text file with UNIX style EOL characters (\n) is
opened as a text file the offset (ftell) of the first character in the
file is the negative of the number of '\n's found in the first 512
bytes. The kluge is that if a file is opened as a text file and a '\n'
(UNIX EOL) is found before '\r\n' (Windows NT EOL) it will be opened as
a binary file.
4. File time stamps have proven difficulties in BETA on Windows NT. We (at
GMT+1) experience the problem that files are reported to have a
timestamp one hour less than the real time stamp of the file. This also
means that when touching a file entry the file will be touched with a
wrong time stamp (in out case one hour later than the real time).
5. Freja is not available for nti
6. Valhalla is not available for nti
7. The new timedate library does not work (linker error).
----------------------------------------------------------------------------
W07) Known bugs, limitations and inconveniences in release 4.1
1. Some parts of systemenv are still not implemented. Some of the demos in
demo\basiclib\systemenv fails. Specificly using the operation
"keyboard.get" will block the entire process, not only the component
issuing the call.
2. Binary/ASCII files has a work-around (kluge) to compensate for a bug(?)
in Windows NT/95. If a text file with UNIX style EOL characters (\n) is
opened as a text file the offset (ftell) of the first character in the
file is the negative of the number of '\n's found in the first 512
bytes. The kluge is that if a file is opened as a text file and a '\n'
(UNIX EOL) is found before '\r\n' (Windows NT EOL) it will be opened as
a binary file.
3. File time stamps have proven difficulties in BETA on Windows NT. We (at
GMT+1) experience the problem that files are reported to have a
timestamp one hour less than the real time stamp of the file. This also
means that when touching a file entry the file will be touched with a
wrong time stamp (in out case one hour later than the real time).
4. Freja is not available for nti
----------------------------------------------------------------------------
SECTION VII: BETA on HPUX
----------------------------------------------------------------------------
HP01) What are the system requirements to run BETA on HPUX workstations?
HP9000/700:
* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* OS: HP-UX 9
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)
----------------------------------------------------------------------------
HP02) Why do some callbacks cause "Illegal Instruction" on hpux9pa (using
v5.0 of the compiler)?
If the following program is compiled and run on an hpux9pa (HP series 700
HPPA, HP-UX 9.x) using the BETA compiler version v5.0), it displays a window
with the text "Timer" in it, prints a random number of 7'digits on the
screen, and then dies with "Illegal Instruction":
ORIGIN '~beta/Xt/v1.8/awenv';
--- program: descriptor ---
AwEnv
(# l: @Command
(# init:: (# do 'Timer'->label #)#);
t: @Timer
(# timeOut:: (# do 10->start; '7'->Put; #) #);
do l.init;
10->t.start;
#)
The reason for this, is that in v2.6 of the hpux9pa runtime system for BETA
there is an error, which occurs if a callback is called very soon after it
is installed. In this case it is called ~10 ms after being installed, and
almost no other code has been executed in this period of time. In this
situation an HPPA cache should have been flushed to ensure the correct
behaviour, but there was an error in the runtime system delivered with
release 3.0 of the Mjolner System. The solution is to acquire a patched
runtime system from Mjolner Informatics.
----------------------------------------------------------------------------
SECTION VIII: BETA on Linux
----------------------------------------------------------------------------
Lx01) What are the system requirements to run BETA on Linux machines?
* Linux (release 2.0 or later)
* CPU: Intel 386/486/Pentium
* RAM: 8Mb (16 to 32 recommended)
* X11 Release 5 or later
* OSF/Motif 1.2 or later (not required just to run compiler)
* Programs needed: (g)as, ld, make.
In lack of Motif libraries, you can use the Lesstif Motif clone. These
libraries works acceptable, but they are not 100% stabil. See
BETA-LESSTIF-FAQ
----------------------------------------------------------------------------
Lx02) How to make the BETA compiler version 5.0/5.1 work with Linux ELF
libraries [corrected in r4.0]
If you are using a Linux version with support for the ELF libraries, the
Mjolner System (release 3.1) cannot be used immediately. You will have to
introduce the following patch:
1. Make sure that /usr/lib/crt0.o can be found. E.g. do this:
pushd /usr/lib; ln -s /usr/i486-linuxaout/lib/crt0.o; popd
2. Make sure the linker is called with "-m i386linux", either by adding
LINKOPT linux '-m i386linux';
in the top of basiclib/v1.4/private/betaenv_unixbody.bet, or
(preferable) by adding this in your .bashrc (or the corresponding stuff
in your .tcshrc):
export BETALINKOPTIONS='-dc -dp -X -m i386linux';
The BETALINKOPTIONS environment variable sets *all* options to the
linker, that is why you have to set the other stuff in the variable
too.
Disclaimer: This has not been tried with the Motif libraries, but it ought
to work.
Thanks to Erik Ernst and Stephen J Bevan
for their investigations on this subject.
----------------------------------------------------------------------------
Lx03) Why does GuiEnv demos segmentation fail? [error in r4.0 & r4.0.1]
With some Linux distributions, the demos in $BETALIB/guienv/v1.4/demos (aka
BETALIB/demo/guienv) all fail with a segmentation fault upon startup,
whereas, e.g. the MotifEnv demos all work correct.
The reason for this seems to be a buggy gcc used for producing some of the
files in the BETA releases r4.0 and r4.0.1. This was done at the time that
the Linux community was switching towards ELF binaries, and possibly this is
the reason, that gcc produced wrong files. The problem has not been observed
for release 4.0.2.
A workaround is to do the following (as the owner of BETALIB):
cd $BETALIB/guienv/v1.4/private/X11
chmod -R u+w .
rm linux/guienv_unix.o
rm linux/Canvas.o
rm linux/Button.o
rm linux/IconButton.o
rm linux/ToggleButton.o
beta guienv_unixbody
chmod -R a-w .
----------------------------------------------------------------------------
SECTION IX: BETA on Silicon Graphics
----------------------------------------------------------------------------
SG01) What are the system requirements to run BETA on Silicon Graphics
workstations?
* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* OS: IRIX 5.3 or 6.2 (32 bit)
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)
If you run IRIX 5.3, you must have installed patch 410 from SGI in order to
fix the linker to generate pure ELF binaries. If you have not applied this
patch, the linker will fail like this:
Unknown flag: -woff
----------------------------------------------------------------------------
SG02) Gnu C Compiler gcc not supported
You cannot link applications, that specify external OBJFILEs compiled with
gcc. You must use cc for external object files. If you get an error like:
ld: FATAL 2: Internal: at ../commonlib/ld3264/relocate.c \
merge_ext returns nil during relocation
this may be caused by an attempt to link a gcc-produced file into your
application.
If you use make files invoked via the MAKE property in a BETA fragment, you
should use $(CC) instead of a hardcoded C compiler name. The BETA compiler
sets CC to a proper default value on alle UNIX platforms.
If you do not know which external object file caused the error to happen,
you may find out like this:
1. Compile the program with beta -p. This will preserve the job-file,
containing the link-directive(s) for the program.
2. Open the preserved jobfile in a text-editor. The job-file is located in
the sgi subdirectory, and has the same name as the application, but
with ..job appended.
3. Add -v as argument to the last invocation of /bin/ld in the job file.
4. Save and execute the job-file.
When the job-file starts to link the final application, it will now print
out the name of each file in the last link-directive as they are processed.
This includes all external object files (specified by OBJFILE in the BETA
code), and you should thus be able to see what file causes the linker to
fail: It is likely to be the last one printed out before the linker crashes.
----------------------------------------------------------------------------
SG03) Remember to set LD_LIBRARY_PATH
After linking shared objects, the LD_LIBRARY_PATH should be set so that it
includes the directory, where the shared object files reside. The compiler
will tell which directory this is. If you get an error like:
793:./foo: rld: Fatal Error: cannot map soname 'foo1..gso' \
using any of the filenames /usr/lib/foo1..gso:/lib/foo1..gso:\
/lib/cmplrs/cc/foo1..gso:/usr/lib/cmplrs/cc/foo1..gso: \
-- either the file does not exist or the file is not mappable \
(with reason indicated in previous msg)
when running you application (here foo), this may be caused by
LD_LIBRARY_PATH not being set correctly.
----------------------------------------------------------------------------
SG04) Using BETA on IRIX 6 machines
On the newest Silicon Graphics OS, IRIX 6, three binary object file formats
are supported by the OS - old 32 bit format, new 32 bit format and new 64
bit format. The BETA compiler in release 4.1, however, only supports the old
32 bit format - the format also used for IRIX 5.
There are 3 implications of this:
1. Link directive:
The compiler automatically fixes the link directive on IRIX 6 machines
2. Using BUILD:
If you are using BUILD properties, and may thus need to invoke the C
compiler, please note that you have to specify the CC environment
variable before compiling your BETA program:
setenv CC 'cc -32'
If you are compiling with beta -d ..., you may also set CC like this:
setenv CC 'cc -O2 -32'
In a future version of the compiler, this will be done automatically.
3. LD_LIBRARY_PATH specification:
If your program is linked using shared object files (the compiler will
tell you so), as always, you should set LD_LIBRARY_PATH to point to the
directory, where the shared object files are places (usually directory
sgi). Since the compiler uses old 32 bit object files, it is enough to
set LD_LIBRARY_PATH. That is, do not set any of the new
LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH variables. If you need to set
any of these, then all 3 variables should be set, and the sgi directory
should be included in all three.
----------------------------------------------------------------------------
SG05) Limitations, bugs and inconveniences
SG05.1) Limitations
The following limitations are currently specific to the SGI implementation:
1. Lazy Fetch in persistence is not implemented. This means that the
following demos fail:
demo/persistentstore/largeRead
demo/persistentstore/crossloc
2. Check for suspend involving callbacks is not done. If you do a suspend
in a callback situation the program is likely to crash.
3. It is uncertain if valhalla (v2.2) will work for executables that
contain shared object files.
4. Integer division by zero will yield unpredictable results (should be
caught as an exception as on other platforms). [corrected in r4.1]
5. The compiler may sometimes crash during code generation. Normally you
can just restart the compilation in this case. [corrected in r4.1]
6. There is sometimes a problem with real expressions involving external
calls. This is e.g. the case in the demo
demo/r4.0/tutorial/SquareRoot
which currently does not work on sgi. [corrected in r4.1]
7. The following runtime errors may not always result in correct dumps:
Repetition subrange out of range
Text parameter to C routine too big (max. 1000 bytes)
8. Do not specify an output file in the sgi-directory to the compiler.
I.e. do not do this:
beta -o sgi/foo foo.bet
Instead you should do this:
beta -o foo foo.bet
mv foo sgi/
The first method may fail when linking shared. The problem is, that the
shared object files are renamed to the file sgi in the sgi directory,
and thus the program will fail to execute. [corrected in r4.1]
9. Do not use the current notation in fragment paths. E.g. use
~beta/basiclib/v1.5/betaenv instead of ~beta/basiclib/current/betaenv.
You may get linker errors, if you use the current notation.
SG05.2) doGCand scanobjdoes not work
The pattern doGC in betaenv does not work on SGI. This is used in
implementation of
sysutils/v1.6/scanobjects
used in the demo
demo/sysutils/objinterface/scanobj
which consequently does not work.
SG05.3) About ld: WARNING 56: Invalid warning number (133)
When the beta compiler is used on IRIX 5.3 it may give the warning ld:
WARNING 56: Invalid warning number (133) at link time. This warning is
caused by the compiler trying to turn of an IRIX 6.2 warning (number 133),
which does not exist on IRIX 5.3. The warning can be safely ignored.
SG05.4) About ld: WARNING 85: definition of vendorShellWidgetClass...
When compiling awenv programs on SGI, the linker will give the following
warnings:
ld: WARNING 85: definition of vendorShellWidgetClass in /usr/lib/libXaw.so
preempts that definition in /usr/lib/libXt.so.
ld: WARNING 85: definition of vendorShellClassRec in /usr/lib/libXaw.so
preempts that definition in /usr/lib/libXt.so.
These warnings are caused by (intentional) overriding of the X Toolkit
VendorShell in the SGI athena libraries. The warnings can be safely ignored.
----------------------------------------------------------------------------
SG06) Disclaimer (Slow startup of tools)
Startup time for SGItools(compiler, frigg, sif, psbrowser, ...) are quite
significant. This is due to the dynamic linker, and may be fixed in a future
version.
----------------------------------------------------------------------------
SECTION X: BETA on Sun workstations
----------------------------------------------------------------------------
Sun01) What are the system requirements to run BETA on Sun workstations?
* RAM: 16 MB, 32Mb recommended.
* Disk: 150 MB disk space
The installation is approx. 100 MB + documentation approx. 13 MB.
* Sun SPARC/Solaris:
o OS: Solaris 2.x
* X window system (Rel. 11.3 or newer)
* Motif 1.2 or later (not required for textual BETA programs)
----------------------------------------------------------------------------
Jorgen Lindskov Knudsen / Aarhus University / jlk@daimi.aau.dk
--
* Jorgen Lindskov Knudsen | Phone: +45 8942 3233 Fax: +45 8942 3255 *
* Dept. of Computer Science | GSM: +45 2099 7357 *
* Univ. of Aarhus, Building 540 | E-mail: jlknudsen@daimi.aau.dk *
* Ny Munkegade, DK-8000 Aarhus C | WWW: http://www.daimi.aau.dk/~jlk *
Section 6 of 6 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6
| Back to category Programming - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use