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

Reply via email to