Re: Add support for amd64 target

[Michael McConville <mmcco@mykolab.com>]

Isaac Dunham wrote:
> > On what seems to be the final link command (judged from the number of
> > object files involved), I get this:
> > 
> > > obj/src/aio/aio.lo: In function `aio_cancel64':
> > > aio.c:(.text.aio_cancel+0x19): undefined reference to `__guard_local'
> > > /usr/bin/ld: obj/src/aio/aio.lo: relocation R_X86_64_PC32 against `__guard_local' can not be used when making a shared object; recompile with -fPIC
> > > /usr/bin/ld: final link failed: Bad value
> > > collect2: ld returned 1 exit status
> > > Makefile:163: recipe for target 'lib/libc.so' failed
> > > gmake: *** [lib/libc.so] Error 1
> > 
> > We have some unique PIE features on by default, so this doesn't surprise
> > me.
> 
> This means that you've got OpenBSD SSP turned on.
> 
> It's no surprise that this doesn't work; for an overview of some trouble
> spots, I'll mention this link:
> 
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130603/176378.html
> 
> Try turning it off (-fno-stack-protector or equivalent) for starters.
> Long-term, a proper port might require patching musl to support OpenBSD
> SSP.

Thanks for the input! The LLVM mail is very useful.

musl links and completes the build successfully with
-fno-stack-protector. I was hesitant to even try that because (IIUC) a
libc port with the stack protector disabled definitely wouldn't fly. A
cursory grep suggests that we only build four ports with
-fno-stack-protector.

> By the way, is this the stock OpenBSD GCC 4.2?

It is. For ports, we use it whenever possible, switching to the Clang or
GCC 4.9 port when something build no longer works with the base
compiler.