[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160318035447.GB19612@thinkpad.swarthmore.edu>
Date: Thu, 17 Mar 2016 23:54:47 -0400
From: Michael McConville <mmcco@...olab.com>
To: musl@...ts.openwall.com
Subject: Re: Add support for amd64 target
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.
I can share a full build log if you're interested.
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.
