Go to the first, previous, next, last section, table of contents.
The autoconf
package generates `configure' scripts that
check the system configuration and generate and modify `Makefile'
accordingly. `configure' scripts also heavily stress the shell
(see section 2.1.15 pdksh) and you must have at least `pdksh-4.9' from Geek Gadgets
960530.
- Bug
-
configure
fails to detects non ANSI/ISO C compliant headers.
- Description
-
The
autoconf
`AC_HEADER_STDC' test fails because of a mixed
autoconf
/ixemul
bug pertaining to the ctype(3)
functions and the interpretation of the default locale behaviour.
islower()
returns true for ö, é etc. where it is expected
to return false for any character above 0x7f under the
default ("C") locale.
- Reported
-
by Rask Ingemann Lambertsen rask@kampsax.dtu.dk (Sep-96)
- Work-around
-
Correct the
ac_cv_header_stdc
entry in `config.cache' and
`config.h' by hand
- Volunteers
-
Lars Hecking lhecking@nmrc.ucc.ie made things progress
- Status
-
See discussion in comp.lang.c.moderated and gnu.misc.discuss.
The programs `as' and `ld' used by GCC are found in the
binutils
package. Among others are `strip', `objdump'
and `ar'.
The binutils-2.x
series all use BFD. BFD is a link library
to manipulate object and executable files in various formats.
The pre-2.x series of the binutils
programs did not use BFD to
write Amiga executables. They used custom output routines that worked
fine but used a UNIX object format instead of the native Amiga one. As
work on the BFD backend for the Amiga's hunk format progressed, the 2.x
series of the binutils started using BFD to write Amiga executables.
Switching to BFD is known to have caused a lot of grief and crashes, for
reasons as various as non-68000 code generation, failure to execute
autoinit sections (affecting Libnix, see section 2.1.12 libnix), bad loadfile hunk
structure, ixemul.library
not recognizing ixemul-compiled
programs, and more.
Other BFD quirks include huge binutils executables (as
,
ld
, strip
, objdump
etc.) as BFD gets linked in. As
an example, the Geek Gadgets strip
utility is 280KB in size,
strings
is 140KB. as
doubled in size from 100KB to 220KB.
Be aware of the linker's (and `strip' and all other BFD-based
tools) huge memory requirements (expect 2.5 times filesize).
At least writing executables files under various GCC options (including
`-s', `-resident' and `-fbaserel') seems to be working
since binutils-2.7
(Geek Gadgets snapshot 960902). Manipulating object
files in Amiga format using fancy options is still hazardous as of
November 1996.
- Bug
-
Executables crashing with 8000000x gurus when using gcc's
`-fbaserel', `-resident' or `-s' options
- Work-around
-
Update to at least
binutils-2.7
(since Geek Gadgets 960902)
Some ld (GNU linker) problems are related to BFS. See section 2.1.2 binutils.
- Bug
-
`strip' on non gcc-compiled binaries destroys them
- Description
-
strip
or rather BFD did not support more than three hunks (one
CODE, DATA and BSS). It didn't report an error but the executable is
likely to be damaged.
- Reported
-
by Tommy Johansson (around 17-Sep-96)
- Work-around
-
Use `util/misc/Strip37_2.lha' from Aminet or update to at
least Geek Gadgets 961012.
- Status
-
Snapshots since 961012 include a good BFD (see section 2.1.2 binutils) and
`strip'.
- Bug
-
`cvs commit' gives
cvs [commit aborted]: cannot commit files as 'root'
- Description
-
checkout, update, remove, add are all possible, but not commit.
Should CVS be compiled without the CVS_BADROOT option, which
refuses to allow root to commit, (see `commit.c' in CVS source
for details) to get it to work for non-networked users?
On the current Amiga, essentially everyone has root priviledges
regardless of what user the networking support sets you up as, so I [Fred Fish]
see no problem with disable the cvs feature that blocks root from
doing some operations.
Furthermore, `cvs commit' invokes an external editor to create a log
message. However, it passes it a UNIX style path name, which isn't grok'ed
by my favorite editor.
- Reported
-
by Diab Jerius djerius@cfa.harvard.edu 12-July-96
- Work-around
-
Start up INet225 and turn on network support in ixemul.library,
which sets you up as non-root. But then it's said to cause tons of
Enforcer hits.
- Volunteers
-
- Difficulty
-
looks like recompile
- Status
-
Norbert Püschel pueschel@imsdd.meb.uni-bonn.de has a beta
`ixemul.library' with UID/GID handling. It sets the default user
as nobody/nogroup when neither MultiUser nor networking are running.
- Bug
-
`cvs checkout' works at random
- Description
-
It doesn't check out complete directories. Caused by ixemul's
`convert_dir.c' which doesn't set
DT_DIR
in a struct
dirent
. Notice that ARexx' `rexx/rexxio.h' defines DT_DIR
with another value, causing a conflict with some applications.
- Reported
-
by Lars Hecking lhecking@nmrc.ucc.ie (6-Nov-96). Conflict reported
by Samuel Devulder devulder@info.unicaen.fr (31-Oct-96).
- Work-around
-
Enclose DT_* definitions in `GG:include/sys/dirent.h' with
#ifndef/#ifdef __amigaos__
- Status
-
Ixemul's `convert_dir.c' fixed in 45.1.
- Bug
-
`dumphunks' fails on binaries with embedded
MEMF_*
flags
- Description
-
In the Amiga object-file format, the most-significant bits of the "hunk size in
longwords" longword (perhaps even as much as the whole most significant byte,
but I'm not sure) are reserved for such things as memory-type indication, and
dumphunks
forgets to filter them out. This can lead to some really weird
numbers when you run dumphunks
on an executable with a chip hunk.
- Reported
-
by Jeroen T. Vermeulen jtv@dial.xs4all.nl (7-Dec-96)
- Status
-
A patch has been submitted by Daniel Vérité daniel@brainstorm.fr on 7-Dec-96.
- Bug
-
fd2inline
generates bad macros, causing errors difficult to find
- Description
-
Caused when type and argument have the same name, as in `gtlayout.library':
struct LayoutHandle *
LT_CreateHandleTagList( struct Screen *Screen, struct TagItem *TagList);
fd2inline
is designed to work fine with the original OS clib/fd
files, not all third-party ones.
- Reported
-
by Martin Recktenwald maret@stud.uni-sb.de (1-Nov-96)
- Work-around
-
Modify the `clib/*.h' file
- Status
-
The simple parser of fd2inline is not likely to be fixed, name clashes
are considered Bad Coding Practice.
- Bug
-
`cpp: unterminated macro call' with MUI headers
- Description
-
The problem is that some functions (declared/defined in the MUI
headers) are really macros with gcc and you end up in trying to
generate new macro calls, token by token, during the preprocessing.
- Reported
-
by Tom Hayko tjhayko@mail.io.org (1-Dec-96)
- Work-around
-
Don't use the
Begin
and End
macros in the MUI header
files, expand the macros manually.
- Difficulty
-
Rewrite macros in the MUI header files that have a variable number of
arguments to call the stubs found in `fd2inline-1.1'.
Package: fileutils (see section 2.1.6 fileutils).
- Bug
-
ls, cp, mv etc. (fileutils) do not correctly handle Amiga-style pathnames
- Description
-
`ls -l GG:' did not work, while `ls -l /gg' did.
To concatenate pathnames, UNIX programs either always insert an
extra slash in between the parts or insert a slash only if a
directory name is not already terminated by one. Both behaviours
are incorrect on the Amiga, where `foo//bar' is different from
`foo/bar' and no slash must be appended to device or volume
names like `RAM:'. The rule is to only append a slash if a
directory name is terminated by neither slash nor colon.
RAM: RAM:foo
DEVS:DOSdrivers
SYS:Classes/ SYS:Classes/gadget
DEVS:/ DEVS:/Storage
- Reported
-
by various (May 96)
- Work-around
-
supply UNIX-style pathnames (`/RAM/', `/dev/PC0') and
have
ixprefs
' "translate /" settings on.
- Volunteers
-
you?
- Difficulty
-
not difficult, just find all the places in all the sources
- Status
-
still broken as of Geek Gadgets release 960714
- Bug
-
`mv foo ram:' (mv across partitions) deletes foo but nothing is in RAM:
- Description
-
mv: cannot move `foo' to `ram:/foo': No such file or directory
.
`mv foo /ram/' didn't complain, but no file was found in /ram/ either.
5> list foo
foo 5 ----rwed Today 21:56:53
1 file - 2 blocks
5> mv foo /workIII/
mv: cannot move `foo' to `/workIII//foo': File exists
5> ls /workIII/
(no foo)
5> move foo text/
5> list text/foo
Directory "text" on Tuesday 09-Jul-96
foo 5 ----rwed Today
5> list workIII:info
Directory "workIII:info" on Tuesday 09-Jul-96
(..)
5> mv foo /workIII/info/
mv: cannot move `foo' to `/workIII/info//foo': Device not configured
- Reported
-
by Lynn Winebarger owinebar@nickel.ucs.indiana.edu
and Greg Jung JUNG@ossen.nrl.navy.mil (9-Jul-1996)
- Volunteers
-
None
- Difficulty
-
- Status
-
GCC output is affected by bugs in the assembler and linker. See section 2.1.2 binutils.
- Bug
-
Poor code is generated when using new inlines for varargs functions
- Description
-
Using libamiga.a is not that bad it's told so often.
It's much better to use the varargs stubs from libamiga.a. The defines
from the inlines result in very poor code. Actually your program
becomes bigger and slower because of the array filling.
- Reported
-
by Gunther Nikl gnikl@informatik.uni-rostock.de (16-Jul-96)
- Work-around
-
Use the stack-based functions found in libamiga.a:
#undef
concerned inline defines so that libamiga.a gets linked in.
- Status
-
- Bug
-
Slow floating point calculations
- Description
-
If you specify `-lm' without `-noixemul', the `libm.a'
library currently in use is extremely slow. Libnix' `libm.a' is
not affected and fast. Using ixemul, the best choice for 68040/FPU
optimizations is currently to either use ixemul with `-lc' only
(the math functions are already contained in the library), or use
`-m68040 -m68881'. When `-m68881' is used, `math.h'
includes `math-68881.h' which leads to inline FPU code generation
of the math functions instead of the equivalently fast ixemul functions.
- Reported
-
by various
- Work-around
-
Either don't specify `-lm' at all or use `-m68040 -m68881' for
inline FPU code. Possibly replace the non-Libnix `libm.a' with an
empty library. With Libnix, use `-lm' or `-m68040 -m68881' as
usual.
- Volunteers
-
Kriton Kyrimis kyrimis@dias.cti.gr
- Difficulty
-
Finding out a fast replacement for the non-Libnix `libm.a'
- Status
-
Still investigating the topic (Nov 1996). Motorola's FPSP library seems
a good candidate and is POSIX compliant.
- Bug
-
Need to make GCC accept absolute Amiga-style pathnames. GCC
cannot be used without
ixprefs
"translate /" settings on.
- Description
-
The old GCC-2.3.3 could deal with gcc Source:foo.c or
gcc /foo.c (parent directory) while now, you must use
gcc /Source/foo.c or gcc ../foo.c. These UNIXish
references will be put in preprocessor
#line
directives and GDB
debugging information, causing other programs (GNUEmacs among them)
not to be able to load/edit the source files.
- Reported
-
by Joerg.Hoehle@gmd.de (9-Jul-96)
- Volunteers
-
- Difficulty
-
The difficult part is to integrate the changes in such a way that
one can still use configure; make, not the actual change.
Some bugs mentioned, none included in this list yet.
- Bug
-
fixed or forbidden register was spilled
- Description
-
Some inline functions/macros use lots of registers, especially
BltBitMap(). RawDoFmt() has also been reported to be involved in such
a situation.
- Reported
-
by various
- Work-around
-
Work-around by using stack-based function calls instead of
inlines. Use libamiga.a/sprintf() instead of RawDoFmt().
- Volunteers
-
Kamil Iskra kiskra@ernie.icslab.agh.edu.pl is the maintainer of
the "new" inlines but knowing this won't help you.
- Difficulty
-
Rewrite your code differently.
- Status
-
- Bug
-
Internal compiler error: program cc1 got fatal signal 11
or 6
- Description
-
Segmentation fault - /ade/lib/gcc-lib/m68k-amigaos/2.7.2.1/cc1
Signal 11 (SIGSEGV) may be due to the stack extending code when the
compiler runs out of memory. The cause of signal 6 is unknown.
- Reported
-
by various
- Work-around
-
Use a lower level of optimization or none at all.
- Status
-
- Bug
-
Wrong floating-point results when using FPU instructions
- Description
-
Some, but not all are caused by ixemul.library. Some only occur on
68040 machines. Too many bug-reports reports to mention.
GCC's FPU machine-description file appears to be seriously broken.
- Volunteers
-
joop van de wege Joop.vandeWege@medew.ento.wau.nl is contributing bug-reports.
Kriton Kyrimis kyrimis@cti.gr is looking for good math routines.
- Status
-
Much work still needs to be done
- Bug
-
`-resident' executables crash, make can't be made resident
- Description
-
int a=1;
int * const p = &a;
int main()
{
a=2;
printf ("%d\n", *p);
}
With `-resident', result is 1 instead of 2. There's a problem with
const
items which are put in the code section and not relative to
a4
.
- Status
-
Daniel Vérité submitted a patch on 18-Oct-96.
- Bug
-
The
__chip
and other Amiga-specific keywords (__saveds
,
__regards
) don't work
- Description
-
Kamil Iskra implemented most of them but they didn't make it yet into
Geek Gadgets, neither is their implementation finished yet.
- Reported
-
by Mark collette mcollett@stu.athabascau.ca (7-Aug-96)
- Work-around
-
AllocMem()
and copy data or make Amiga object files (see also
`dev/misc/BintoHunk.lha' on Aminet and atom
from the AmigaOS
SDK) and use the blink
linker.
- Volunteers
-
Kamil Iskra kiskra@ernie.icslab.agh.edu.pl, Daniel Vérité
- Status
-
__chip
support is not yet complete as far as the assembler and linker
are concerned (Nov 96).
Almost every snapshot introduces few minor bugs as many patches to GCC
have been submitted but seldomly tested in the context of
cross-compilation. For Details, be sure to read
section `Cross environment' in The Geek Gadgets Project Documentation.
Report problems to gg-gcc@ninemoons.com.
- Bug
-
`#error: float.h values not known for cross-compiler'
- Description
-
A source just including `math.h' fails to compile.
ixemul
's
`include/float.h' should be included instead of GCC's.
- Reported
-
by Alfred Minarik am@mdy.univie.ac.at (16-Oct-96)
- Work-around
-
Delete `lib/gcc-lib/m68k-cbm-amigaos/2.7.2.1/include/float.h',
as suggested by Daniel Vérité daniel@brainstorm.fr.
- Bug
-
`ld: Undefined symbol _amiga_cpp_symname_hook'
- Description
-
The macro is in the target config file where it should be in the host
config file.
- Reported
-
by Maarten D. de Jong dejong@cpt6.stm.tudelft.nl (26-Oct-96)
- Work-around
-
Use the`pub/geekgadgets/updates/gcc-961012-patch-01' patch to Geek Gadgets 961012.
- Bug
-
some
info
commands do not work
- Description
-
info dcache
gives Enforcer hits.
info float
gives `No floating point info available for this processor.'
on my A4000/40, but info all-registers
correctly shows FPU registers.
- Reported
-
by Joerg.Hoehle@gmd.de (25-Aug-96)
- Status
-
- Bug
-
GhostScript hangs after ctrl-c or the `quit' command
- Work-around
-
Use
GhostScript
or the `post.library' from Aminet.
- Reported
-
by various (last Oct-96)
- Status
-
Joop van de wege Joop.vandeWege@medew.ento.wau.nl wants to continue
working on this after doing some other jobs.
The pdksh
shell stresses the UNIX-compatibility of ixemul.library.
See section 2.1.15 pdksh.
- Bug
-
`ENV:' notification problem with ixemul.library
- Description
-
If you change something in `ENV:' using the AmigaOS command
SetEnv
, ixemul may not notice it and still report the old
settings to all ixemul programs.
- Reported
-
by Jörg Höhle Joerg.Hoehle@gmd.de (18-Dec-96)
- Work-around
-
Flush ixemul.library from memory or try
UnSetEnv
to remove the
setting, then SetEnv
to force a notify, then UnSetEnv
again.
- Bug
-
fcntl(,, O_NONBLOCK)
doesn't work
- Description
-
From `RPM' file: `build/pack.c'
fcntl(fromCpio[0], F_SETFL, O_NONBLOCK);
bytes = read(fromCpio[0], buf, sizeof(buf));
When read() can't read anything from the file (in this case a pipe)
it returns -1. But read() waits, so the program is blocked.
- Reported
-
by Kristof Depraetere Kristof.Depraetere@rug.ac.be (6-Jul-96)
- Work-around
-
ioctl(fh, FIONBIO, 1);
- Status
-
Fixed in ixemul-44.0.
- Bug
-
missing
ttyname()
function
- Reported
-
by Laurent.Peron@emi.u-bordeaux.fr (7-Oct-96)
- Work-around
-
Update to at least ixemul-44.0
- Bug
-
missing
sbrk()
function
- Description
-
sbrk
is a low-level UNIX call which is inappropriate on the Amiga
as it assumes a memory heap growing in one direction only.
- Reported
-
by Steve Kaye stevek@phonelink.telme.com (19-Jul-96)
- Work-around
-
Use the GNU `dbmalloc' package if you can live with preallocating a
fixed size "sbrk pool" or see if there is some
#define
not to use
it.
- Bug
-
Every ixemul program opens `ixnet.library'
- Description
-
For every ixemul program started, the library must check if it was run
as a daemon as the startup is then different.
- Work-around
-
Disable networking in
ixprefs
.
- Bug
-
Can't use
less
as man
's pager
- Description
-
Many things can go wrong.
-
SetEnv TERM amiga
-
SetEnv LESSCHARSET latin1 to display all of ISO_8859_1
-
Less
uses ncurses
since Geek Gadgets 960902, growing the binary
from 90KB to 190KB. See section 2.1.14 ncurses for ncurses
problems.
- Work-around
-
Check everything. Better: use MultiView (see above) or the amigaized `Less-1.6Z'.
- Reported
-
by many, including Martin Blom lcs@lysator.liu.se (15-Oct-96)
- Bug
-
linker errors about DOSBase or SysBase in 970217 snapshot
- Description
-
The Libnix archives were stripped with GNU binutils which removed long
filenames causing duplicate entries, whereas the original Libnix archive
was built using BSD ar and ranlib.
- Reported
-
by Fred Fish fnf@fishpond.ninemoons.com (21-2-97)
- Work-around
-
Use Libnix
.a
files from other snapshots
- Bug
-
stdio buffer size is 1KB by default
- Description
-
The default should be somewhere between 8KB and 32KB. DiskSpeed shows
extremely poor results for buffers below 4KB.
- Reported
-
by Joerg.Hoehle@gmd.de (12-Jun-1996)
- Work-around
-
setvbuf()
, but you don't want to modify foreign code for that
- Difficulty
-
probably easy
- Bug
-
`-noixemul' compiled binaries guru
- Description
-
Caused since Libnix1.1 by the use of linker features (autoinit
sections) which were broken in the
binutils-2
linker.
See section 2.1.2 binutils.
- Work-around
-
Update to at least version 960530 of binutils/ld.
- Bug
-
Using
sprintf()
links in all of stdio
- Description
-
sprintf
uses some kind of pseudo FILE* to a RAM buffer internally
and then uses its IO routines (fputc
, open
,
__fflush
...) on it. This makes your code unnecessary big
when you don't want to use stdio (because you use
dos.library
calls for example). You can't make tiny executables
with Libnix sprintf()
.
- Reported
-
by Joerg.Hoehle@gmd.de (1-Oct-1996)
- Work-around
-
Try to use
sprintf
from `libamiga.a', be aware that
`%d' assumes 16-bit ints then.
See section 2.2.1 missing documentation.
- Bug
-
`man man' doesn't work, it says `cannot create'
- work-around
-
Update to `manutils-2.0' by Lars Hecking
lhecking@nmrc.ucc.ie, a far better
man
from NetBSD.
- Bug
-
Can't use another pager for
man
- Description
-
If you get `sh: less: not found', then
$PAGER
is not
set correctly. Set the local variable, not the global
(`ENV:PAGER') one: (Set PAGER `Which MultiView`).
Doing so is still prone to fail or deliver at least undesirable results,
for two reasons:
-
$PAGER
ist called with Unix path names, which native programs will
not grok; for this reason I have included a shell script viewer.sh
with `manutils-2.0', which will translate absolute path names. This
is really a crutch which may disappear in newer versions, but it's not
on my current priority list. (See `man.conf' for an example how to use it).
-
formatted man pages may still contain bold and underlined characters,
which make them a bit unreadable in MultiView.
[There is a man datatype on Aminet which takes care of
this. `manutils-2.1' will use temporary files like `/tmp/man.278672.1' to
let
mandt
recognize the file]
- Reported
-
by Martin Steigerwald steigerw@stud.uni-frankfurt.de (26-Jul-96).
`manutils-2.0' by Lars Hecking lhecking@nmrc.ucc.ie.
- Bug
-
The manual datatype `mandt' is not working
- Description
-
Not a Geek Gadgets bug. The so-called manual datatype can only display
formatted manual pages (those that contain codes like
m^H_a^H^_
)
but not unformatted (nroff
) ones (containing sequences like
.SH
, .TH
etc.). Unfortunately, most UNIX archives come
with unformatted manual pages.
- Work-around
-
Install `groff' to process unformatted manual pages or find
formatted ones on the Internet.
- Reported
-
by Lars Hecking lhecking@nmrc.ucc.ie (15-Oct-96)
- Status
-
Geek Gadgets
Makefile
s need to be changed to generate and install
readable (guide or formatted) manuals. See section 2.2.1 missing documentation.
All UNIX programs that do screen-oriented output use some package or
(link-)library for this purpose, either termcap, curses or
ncurses.
Ncftp
and less
(since Geek Gadgets 960902) use ncurses
and
its associated `lib/terminfo/...' files.
- Bug
-
Error messages about terminal or `terminfo'
- Description
-
Many things can go wrong.
-
SetEnv TERM amiga
-
Programs using ncurses will build a terminal information file when
none is found. Create an empty `GG:lib/terminfo/' directory, then
run
less
(or ncftp
) and wait for it to process your
`termcap' file, creating `GG:lib/terminfo/A/amiga'. It's not
necessary to install the giant (see below) ncurses
distribution when you
need just the `amiga' file.
-
$HOME
must be set correctly, as it will try to create
`$HOME/.terminfo/...' if it can't access `GG:lib/terminfo/'.
- Reported
-
by many. Explanations from Steve Hodge sbh@cs.waikato.ac.nz (18-Oct-96).
- Bug
-
`Less: Name collision between pcansi-25 pcansi-mono25'
- Description
-
Bad `terminfo' files or missing
$TERM
?
- Work-around
-
SetEnv TERM amiga. Make an empty `GG:lib/terminfo/' and
recreate entry (as above).
- Bug
-
`GG:lib/terminfo/...' is huge
- Description
-
It comprises 1696 files, summing up to 3.7MB of data, not
counting the file-system's rounding up to the next block.
Furthermore, binaries using ncurses instead of termcap grow,
less
for example from 90KB to 190KB.
- Work-around
-
Just keep `terminfo/a/amiga', `v/vt100*,vt220*',
`x/xterm*' and delete all others that you don't need.
- Reported
-
by Lars Hecking lhecking@nmrc.ucc.ie (16-Oct-96)
The shell `GG:bin/sh' is a link to `GG:bin/ksh', which is a
port of the pdksh package, a reimplementation of the Korn shell.
It is freely distribuable and reasonably compatible with the Bourne
shell and is therefore used as the basic UNIX shell within Geek Gadgets.
- Bug
-
^C doesn't work for non ixemul-programs when run inside pdksh
- Description
-
a mixed pdksh/ixemul bug?
- Reported
-
by Joerg.Hoehle@gmd.de (3-Jul-1996)
- Difficulty
-
Tough
- Status
-
^C is disabled as of ixemul V43.1
- Bug
-
pdksh
does not read `etc:profile' as it previously did
- Description
-
Should it?
- Reported
-
by David Aschbrenner pfloyd@netins.net (16-Oct-96)
- Work-around
-
If started as
-ksh
(the dash is the UNIX login marker), it will
read `etc:profile' and `$HOME/.profile'. Another possibility
is to set `$ENV' before starting pdksh
.
- Bug
-
line editing does not work in
pdksh
- Description
-
pdksh
uses the native console by default. Use `set -o emacs'
to get line editing through a readline
-like builtin function.
When `$VISUAL', `$EDITOR' or `$FCEDIT' contain the string
emacs
(or vi
), pdksh
switches to Emacs (or vi) line
editing by itself.
- Reported
-
by various, including Thomas Walter walter@pctc.chemie.uni-erlangen.de (21-Oct-96)
- Work-around
-
`set -o vi' or `set -o emacs' and `bind ^X=prefix-2' for
Emacs mode.
- Status
-
Cursor keys are not recognized (Nov-96) when using `set -o', but
Joerg.Hoehle@gmd.de posted some `bind' commands as a work-around
(11-Dec-96).
- Bug
-
really not a gcc bug?
- Description
-
After updating locally to ixemul 44.0, the RCS
conf.sh
script stopped
working correctly at the fread
test. This failure was reduced to the
test case included below. If the compile + run does not succeed on
the first combination of types, then the test fails to deduce the
right types. With ixemul 43.2, it just happened that for conf.sh
the
first combination was the right one, but the return type of fread
changed in 44.0, triggering this bug.
To make the below test succeed, edit `a.c' to change the hardwired
types of foo()
to be `int foo (int arg);' and do `sh a.sh'.
When run on a Unix system, the test works no matter what combination
of types foo()
has.
/* a.c --- Change these types to test */
long foo (long arg);
type foo (argtype arg) {}
main () { exit (0); }
-------- a.sh
#! /bin/sh
for type in int long
do
for argtype in int long
do
echo trying type=$type, argtype=$argtype
(gcc -Dargtype=$argtype -Dtype=$type a.c && a.out) && echo "FOUND IT" && break
done && break
done || {
echo $0: cannot deduce types
exit 1
}
echo $0: deduced types $type, $argtype
- Reported
-
on Sun, 18 Aug 1996, by fnf@ninemoons.com (Fred Fish)
- Work-around
-
- Status
-
bug triggered by fread() return type changing in ixemul-44.0
- Bug
-
Lock up when exiting some non-ixemul program run from pdksh
- Description
-
Typical examples are
GNUEmacs
, vim
and Multiview
.
- Reported
-
by Bo Najdrovsky bn@okcforum.org (2-Nov-96)
- Work-around
-
Update to ixemul-45.1 once it's available.
- Status
-
Traced to an uncleared signal disturbing ixemul.library. Fixed in 45.1.
- Bug
-
tar
does not accept Amiga filenames containing a colon, thus
tar -tfv Store:gcc-2.7.2.tar does not work.
- Description
-
new "feature" makes tar interpret the name before the colon as a
remote host name, which is bad on the Amiga. Either drop the
remote option completely or change the syntax in a portable
way.
The easiest way to circumvent the additional cmd line option is to add
flag_force_local = 1 at the top of tar.c/decode_options(). This is ok as
long as no one wants to use tar remotely (which doesn't work anyway, I
[Lars Hecking] am told. This feature needs the second fork() in
buffer.c/child_open(). And rexec(3), methinks.)
- Reported
-
by Joerg.Hoehle@gmd.de (4-Jul-1996)
- Work-around
-
Use `--force-local'
- Volunteers
-
Joerg.Hoehle@gmd.de is working on it, Hans Verkuil hans@wyst.hobby.nl
has supplied a patch adding a new `--force-remote' switch.
- Difficulty
-
Seems easy
- Status
-
A report about the "colon is used in pathnames of several OS" problem
has been posted to gnu.utils.bugs and been "filed" by Francois
Pinard pinard@iro.umontreal.ca, the GNU-tar maintainer.
- Bug
-
tar xvMf /fd0 does not work with `FD0:' RawDiskHandler
- Description
-
On a UNIX box, prepare a disk with tar cvMf /dev/fd0
Verzeichnis. Back on the Amiga, all I get is a requester saying
`Free: corrupted segment' after the first fileheader. It does work
with an old tar of mine.
Lars Hecking lhecking@nmrc.ucc.ie adds:
I have tried to find this bug and failed. AFAIR, the GNU tar port on Aminet
was compiled with SAS/C and should be less functional than the Geek Gadgets version
wrt stubbed-out Unix functions/syscalls. I think even compiling the SAS'd
sources with gcc doesn't make `-M' work. Which leads me to the conclusion
that hhere is either a bug in tar which doesn't show with SAS, or a bug in
ixemul.library, or a bug in gg-gcc.
- Reported
-
by Ingo Saitz ingo@r1.iqo.uni-hannover.de
- Volunteers
-
- Difficulty
-
- Status
-
Untested
- Bug
-
tar -tzvf foo.tgz and gzcat foo.tgz | tar -tvf - do not work
- Work-around
-
Update to at least Geek Gadgets version 960530 of tar.
All UNIX programs that do screen-oriented output use some package or
(link-)library for this purpose, either termcap, curses or
ncurses.
GNUEmacs and less (prior to Geek Gadgets 960902) use termcap
.
- Bug
-
`WARNING: terminal cannot clear to end of line' and others
- Description
-
Your
$TERM
or $TERMCAP
variable is not set correctly,
making termcap
-based programs assume a dumb terminal (that only
knows backspace). The terminal capabilities file location is
`GG:etc/termcap' or `etc:termcap'. Unless somebody can
telnet
to your machine, you can get along with a minimal version
that only contains an entry for `amiga' (and possibly `xterm'
if you run some X server) instead of the complete one that's 440KB.
- Work-around
-
First SetEnv TERM amiga. If it still doesn't work,
SetEnv TERMCAP GG:etc/termcap.
- Reported
-
by many, including Martin Steigerwald steigerw@stud.uni-frankfurt.de
The texinfo package (see section 2.1.18 texinfo) contains several elisp and
TeX files; some problems are related to them:
- Bug
-
TeX files may not be installed in the correct place.
- Description
-
The two TeX macro files, `texinfo.tex' and
`epsf.tex', which are needed when .texi files are processed
into .dvi files, may be installed in the wrong place, depending
on the local TeX installation. Furthermore, an older copy of
`texinfo.tex' may be included, which will break the use of
new features. The version of an `texinfo.tex' file can be
determined with the command:
grep '^\\deftexinfoversion\$Revision' geekgadgets/texinfo.tex \
| awk '{print $2}'
- Reported
-
by maintainer (Sep 97)
- Work-around
-
Move texinfo.tex and epsf.tex to a place where they can be found
by the TeX system. Remove any obsolete copies of
`texinfo.tex'.
- Bug
-
Elisp files are not present in the binary archive.
- Description
-
The emacs lisp (.el) files from the texinfo distribution are not
present in the binary archive, as they rely on features found in
emacs-19. The files are available in the source archive, and
should NOT be installed indiscriminate. Emacs' Info-mode will
cease to function if installed.
- Reported
-
by maintainer (Sep/Oct 97)
- Work-around
-
Modify the elisp files, or port emacs 19
- Difficulty
-
Medium, if the files are modified, Hard if the fix involves
porting emacs 19.
This list of long-waiting easy fixes are waiting for somebody to download
the archives, change the behaviour of the affected packages and send back
diffs to the Geek Gadgets mailing lists. Fred Fish can't do it all.
Most of them is a matter of modifying `Makefile' (i.e. in fact
`Makefile.in') or `configure' (`configure.in') and thus
may require some knowledge about autoconf
. Some require adding a
`configure' script to a package that does not yet use autoconf
.
Geek Gadgets packages must have configure scripts (not necessarily created by
autoconf, but doing so is recommended) and be able to build in a
directory other than the source directory.
- Bug
-
Some binary archives do not contain documentation files
- Description
-
The `Makefile'
install
targets do not copy manpages or
create AmigaGuide files. Known packages missing documentation or guide
files: octave
- Work-around
-
Get source archive and run makeinfo --amiga.
- Reported
-
by various, including Laurent.Peron@emi.u-bordeaux.fr (13-Oct-96)
- Difficulty
-
This particular problem for example would probably not take more than
an hour for someone to fix. See
autoconf
as an example of how to do it,
or any of the other packages for which Guide files get installed in
`GG:guide/'.
- Status
-
Fred Fish already corrected several packages: "The problem is that there
are hundreds of little things like this that could turn into a full time
job for one person, and I already have one of those."
- Bug
-
Some packages (i.e.
lynx
) does not use configure
, thus they are
not rebuilt on every snapshot. Besides violating the main goal of having
everything rebuild on each snapshot this can indeed cause problems if rebuilts
of other packages introduce non-backward-compatible changes.
- Requires
-
autoconf
knowledge
- Reported
-
various
- Status
-
Some people are said to work here and there.
Please inquire on gg-projects@ninemoons.com for the current
status on this.
This is not a list of all AmigaOS bugs but rather a mention of some that
affect the use of Geek Gadgets tools.
- Bug
-
pipe ...| ...
and/or PIPE: don't work correctly
- Description
-
PIPE:
aka `L:queue-handler' looses bytes up to and including
OS 3.1. Use Heinz Wrobel's `util/sys/HWGQueue.lha'.
Furthermore, the pipe
command from Andy Finkel's os204hacks
package is slightly broken. You may wish to replace it with either
`util/cli/pipe3310.lha' or `util/shell/Pipe-1.5.lha'
- Work-around
-
- Bug
-
Symbolic links don't work in RAM:
- Description
-
The RAM: filesystem doesn't support soft links. This affects RPM, as it
creates symbolic links in tmp: which is normally on RAM:
- Reported
-
by Kristof Depraetere Kristof.Depraetere@rug.ac.be (26-Nov-96)
- Work-around
-
As far as RPM is concerned, assign tmp: to a HD.
- Bug
-
Can't delete symbolic link
- Description
-
C:Delete
only works when the file the link points to can be accessed.
- Work-around
-
Use `GG:bin/rm' or other tools that just call
DeleteFile()
without trying to Lock()
first.
- Bug
-
`mathieeesing*.library' bug in conjunction with 68040
- Description
-
Reported to show up with G++
- Reported
-
by Kriton Kyrimis kyrimis@dias.cti.gr (5-Nov-96)
- Work-around
-
Use `util/boot/MathPatch.lha' from Aminet or the Libnix archive.
- Bug
-
Can't put {, } or " in AmigaGuide buttons
- Description
-
Balanced braces work, unbalanced don't (at least in 39.11). It also
depends on the library version. This affects `makeinfo --amiga'
when generating AmigaGuide files.
- Reported
-
by Kriton Kirimis kyrimis@cti.gr (22-Oct-96)
- Work-around
-
V35: Translate
{
to [
, }
to ]
and "
to '
V39: Either do the same, or only translate unbalanced braces (non-trivial to detect)
V40: Translate "
to '
But sometimes {
is needed and can't be translated (e.g. in an index list).
- Volunteers
-
Kristof Depraetere Kristof.Depraetere@rug.ac.be maintains the Amiga
port of Texinfo.
- Status
-
Makeinfo now translates the characters as above but only if one uses
@{
, @}
or @"
(old Texinfo
doesn't know
about this last one) (Oct-96).
- Bug
-
different guide files for V34, V39 and V40 versions of
`amigaguide.library'
- Description
-
\\
is needed instead of \
in V40, etc., requiring
the `--amiga-40' etc. options to makeinfo
.
- Difficulty
-
Get AT or whoever to release V41 for free, like they did for Installer,
so everybody gets it and uses that one.
This is not a list of all third party bugs but rather a mention of some that
affect the use of Geek Gadgets tools.
- Bug
-
AmiCDFS problems show up with
du
- Description
-
du
doesn't work with this file system, giving errors like
du: /HD2/AmiTCP/logs/aws-access: File exists
du: cannot change to `..' from directory /HD2/: Input/output error
The other `du: cannot return to starting directory: No such file or directory'
error is due to a bug in ixemul.library fixed in 45.1.
- Reported
-
by Thomas Walter walter@pctc.chemie.uni-erlangen.de (27-Nov-96)
- Work-around
-
Use another CDROM file system.
- Status
-
Has that bug been reported to Asimware?
- Bug
-
`libamiga.a' defines common symbols like
stub
- Description
-
... and many more. Avoid using a variable of that name in your code
or you'll get spurious and hard to find errors.
- Reported
-
by Matthias Hopf mshopf@informatik.uni-erlangen.de
- Work-around
-
Try to avoid using `libamiga.a' by using inlines.
Go to the first, previous, next, last section, table of contents.