Improving build on OpenBSD x86_64
A few months ago I managed to build gcc 4.5.1 on an OpenBSD x86_64 platform. This was difficult, even with the patches available in my system's ports tree (which could build gcc 4.3). I would like to volunteer to make this platform better supported. However, I have not contributed to gcc before, and I do not know where to begin. I would like to work with a mentor who can assist me with the gcc community's policies and procedures. Who would help me get started? -- Kyle Markley
Various problems building on x86_64 OpenBSD
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
Built gcc 4.5.1 on amd64-unknown-openbsd4.8
Hello, Following the recommendations on http://gcc.gnu.org/install/finalinstall.html, I'm reporting my success at building gcc 4.5.1 on amd64-unknown-openbsd4.8 because this platform is not listed in http://gcc.gnu.org/buildstat.html. $ ./config.guess amd64-unknown-openbsd4.8 $ /tmp/usr/local/bin/g++-4.5.1 -v Using built-in specs. COLLECT_GCC=/tmp/usr/local/bin/g++-4.5.1 COLLECT_LTO_WRAPPER=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-openbsd4.8/4.5.1/lto-wrapper Target: x86_64-unknown-openbsd4.8 Configured with: ../gcc/configure --program-suffix=-4.5.1 --enable-threads --enable-languages=c++ : (reconfigured) ../gcc/configure --program-suffix=-4.5.1 --enable-threads --enable-languages=c++ Thread model: posix gcc version 4.5.1 (GCC) I found that gcc was difficult to build on this platform. I started from the patches included with my OpenBSD 4.8 distribution's ports tree for gcc 4.3. Many of these patches do not apply cleanly to the source code of 4.5.1 (due to code drift since 4.3) and I had to make many of the changes manually. The most important patches were to gcc/config.gcc and libgcc/config.host so that my platform was recognized, and several changes in gcc/config/, but the patches from the ports tree got me most of the way through. Finally, I hit this bug while building: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 ... but killing the process (as recommended at that link) let me proceed. I don't think I have the expertise necessary to help maintain the health of gcc on OpenBSD for the long run, but I am interested in helping to make it easier to build on this platform. Please let me know what I can do. -- Kyle Markley
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On 03/02/12 05:44, Richard Guenther wrote: GCC 4.7.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.7.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 and shortly its mirrors. It has been generated from SVN revision 184777. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.7.0 in about three weeks. I've been trying to build this on the (unsupported) x86_64 OpenBSD platform, but hit an ICE that I have been unable to work around: internal compiler error: vector VEC(dw_cfi_ref,gc) grow domain error, in update_row_reg_save at dwarf2cfi.c:454 I filed this problem, but I'm the only person who has updated it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52471 As I don't know anything about gcc internals, I'm ill-suited to debug this. -- Kyle Markley
Built gcc 4.7.0 on OpenBSD x86_64
fig.host (working copy)
@@ -538,6 +538,8 @@
;;
i[34567]86-*-openbsd*)
;;
+x86_64-*-openbsd*)
+ ;;
i[34567]86-*-linux*)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm
i386/t-crtstuff t-dfprules"
Index: gcc/dwarf2cfi.c
===
--- gcc/dwarf2cfi.c (revision 185724)
+++ gcc/dwarf2cfi.c (working copy)
@@ -2904,9 +2904,11 @@
create_pseudo_cfg ();
/* Do the work. */
+/*
create_cfi_notes ();
connect_traces ();
add_cfis_to_fde ();
+*/
/* Free all the data we allocated. */
{
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 185724)
+++ gcc/config.gcc (working copy)
@@ -1225,6 +1225,13 @@
gas=yes
gnu_ld=yes
;;
+x86_64-*-openbsd*)
+ tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h"
+ tm_file="${tm_file} openbsd.h openbsd-stdint.h
openbsd-libpthread.h i386/openbsdelf.h"
+ extra_options="${extra_options} openbsd.opt"
+ gas=yes
+ gnu_ld=yes
+ ;;
i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu |
i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* |
i[34567]86-*-kopensolaris*-gnu)
# Intel 80386's running GNU/*
# with ELF format using glibc 2
--
Kyle Markley
