Last year I managed to build gcc 4.5.1 on x86_64 OpenBSD4.8, with
difficulty. I am currently trying to repeat this with gcc 4.6.2 and
running into additional trouble that I need to ask the list for help with.
Ultimately I intend to submit a patch to make gcc build cleanly on this
platform. (I'm still waiting for my employer release.)
Here are the issues I'm hitting:
----
I get "missing sentinel in function call" warnings from
gcc/lto-plugin/lto-plugin.c because on my platform NULL evaluates to "0L".
There is a fixinclude (openbsd_null_definition) that may be relevant. I
believe lto-plugin.c gets its NULL definition from stdlib.h, but
stdlib.h is not in the 'files' list for this fixinclude. In OpenBSD 4.8
I find NULL definitions in three additional files not in the fixinclude:
dirent.h, stdlib.h, rpc/types.h
The NULL definition in dirent.h does not appear to match the fixinclude
pattern match due to comments.
I attempted to edit fixincl.x (I don't have autogen) and rerun but this
didn't help; I get the same error. I know basically nothing about the
fixinclude process -- I don't even know how to check whether the attempt
to compile lto-plugin.c used a fixinclude at all.
If I manually add -DNULL='((void*)0)' to the failing libtool command
line, I can continue.
But how do I fix this so that no manual step is needed?
----
Shortly thereafter, I get an error "Configuration
x86_64-unknown-openbsd4.8 not supported" from configure-stage1-gcc.
This is familiar; I had the same problem when I built gcc 4.5.1. The
config files don't recognize x86_64 OpenBSD (they only know i386).
I don't know the correct way to add this architecture to
gcc/config.gcc. I can copy all the settings under
i[34567]86-*-openbsd*, but I am ignorant of the implications and fear
that a blind copy is incorrect.
The same problem occurs for libgcc/config.host.
----
Finally, I am getting stuck in stage3 trying to link
.libs/libstdc++.so.6.16. The error is:
/usr/bin/ld: /storage/gcc462_1/obj/./gcc/libgcc.a(unwind-sjlj.o):
relocation R_X86_64_32 can not be used when making a shared object;
recompile with -fPIC
Sure enough, when this was compiled it didn't have -fPIC. Why not? I
tried using gmake BOOT_CFLAGS='-fPIC' and although I saw that it
affected some command lines, it didn't affect the compilation of
unwind-sjlj.c. Is that not the correct way to send compiler switches to
all stages?
I haven't found any workaround for this yet. Help?
--
Kyle Markley