[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Mar 2016 22:08:25 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Add support for amd64 target
On Thu, Mar 17, 2016 at 11:54:47PM -0400, Michael McConville wrote:
> Rich Felker wrote:
> > On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote:
> > > AMD64 and x86-64 are effectively interchangeable terms. BSDs use the
> > > prior while Linux uses the latter. The below patch therefore fixes
> > > configure on OpenBSD.
> >
> > I'm not opposed to adding this if you think it will help, but I'm
> > skeptical of whether a toolchain targeting OpenBSD can produce a
> > working musl build anyway. Are you trying to get something that runs
> > on OpenBSD or use the OpenBSD compiler as a makeshift cross compiler
> > to get a normal Linux build?
>
> FreeBSD and RISC-V (one an OS and the other an architecture, of course)
> both have Google Summer of Code projects for porting musl. This
> interests me, and because I'm on OpenBSD developer I thought I'd give it
> a try on OpenBSD.
>
> Whether or not I do either of the GSoC projects or follow through with
> an OpenBSD port, it's likely that someone will take up the FreeBSD
> project. In that case, this patch will have to be applied.
>
> I'm hopeful that BSD ports won't be invasive, considering how long the
> unpatched (ignoring the trivial configure patch) build ran.
>
> > > For what it's worth, the build then survives until linking. I haven't
> > > had a chance to diagnose that problem yet.
> >
> > What are the linker errors you hit? It's not surprising that compiling
> > would work since no files external to the musl source tree are
> > accessed during compiling, but linking could bring in lots of issues,
> > and runtime even more.
>
> 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.
By the way, is this the stock OpenBSD GCC 4.2?
HTH,
Isaac Dunham
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
