Didier Godefroy writes:

`/usr/local/openldap/openldap-2.4.16/libraries/liblunicode' 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 file.

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.