Didier Godefroy writes:
cc -O4 -g3 -w -I../../include -I../../include -pthread
-I/usr/local/include -pthread -I/usr/local/include -c -o ure.o ure.c
cc: Fatal: A memory access violation (bus error or segmentation fault)
has occurred. Please submit a problem report.
What can I try and send to get this fixed?
To the compiler vendor. Though ask your sysadmin first, in case it
should go via your support contract.
A compiler crash is a bug in the compiler, regardless of whether or not
some OpenLDAP bug triggered it.
As for what to report to them: Their website may have a bug database
which describes how to report bugs. Typically, you'd include
compiler version, OS, and architecture, the exact compile command,
and the contents of ure-bug.c after replacing '-c -o ure.o' with
'-E ... > ure-bug.c'. That way they can reproduce the bug themselves
wihtout downloading and configuring OpenLDAP.
But check that this doesn't cure the bug: i.e. that you get the same
compile error when you compile with ... '-c -o ure-bug.o ure-bug.c'.
(This assumes -E does produce preprocessor output, which is common for
compilers but not universal.)
As for getting OpenLDAP to work until it's fixed: Experiment with other
compiler flags, e.g. remove -O4 -g3. Might do it just for the offending
If that doesn't help and the Tru64 folks can't help quickely enough: You
could get someone who knows C to search for the code which triggers the
bug: Remove parts of ure.c until the crash disappears, then add some
back until it comes back, and so on. That _might_ turn up an OpenLDAP
bug or at least some piece of code which it _might_ make sense to tweak
a bit to work around the compiler bug.