>Compiled on an Intel machine it runs quite fine (on that
>Intel machine); compile on my Alpha, it fails with odd
>errors, e.g. in not being able to fopen() a file, cannot
>create a temp file, and not enough memory for malloc.
>
>Editing the pertaining source file, and commenting out code
>run _after_ the error causing algorithm results in no errors.
>
>I really cannot find any C-related problem (casting or so),
>and gcc -Wall does not cause any warnings at all.
>
>Upgrading from libc 0.40.2 to 0.40.3 doesn't help.
>Upgrading memset.S with Linus' recent version doesn't help.
>
>Any ideas? Please?
>
>Met vriendelijke groeten, Wim van Dorst
I had also some bad surprises on linux-alpha with source code (e.g., Linux
commands) using malloc() and that was non-portable from Intel/ix86 to Dec/Alpha.
What I write below is perhaps trivial for you; if so you should perhpas
ask for help on another linux-alpha mailing list:
axp-list@redhat.com
1) check "everywhere" in your source code how malloc() is declared:
it should be defined by:
#include <stdlib.h>
i.e. with an ANSI-conformant prototype using "size_t' for #of bytes to allocate,
NOT `int': size_t == unsigned long == 64-bit on Digital Unix and Linux-alpha!
2) check then the type of variables that are used to contain such #of bytes:
if `int's are used, control where are made implicit castings and make them
explicit (just a recommandation). Alternatively, you can change the type of
them to `size_t' [including <sys/types.h> for getting in the def. for size_t],
but you should also control implicit castings, ?printf() format, etc. for
them.
3) if it is not already done, control the return code of each call to malloc(),
at least in a `debug' mode: e.g., printing out on error the name of the module
which made the call to malloc(), the number of required bytes ... this casting
it to `long' and using a "%ld" format or equiv.!
Note that I used an older version of libs/header files than yours--the one
coming with the `BLADE_0.3' distribution [on Digital site]--, and probably
an older kernel/gcc than yours (I used the BLADE_0.3 ones): my libc.a was
something like the 0.35?, dated Nov 10, 1995 and 2000370 bytes long.
Good luck,
fred