mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Michael McConville <mmcco@mykolab.com>
To: musl@lists.openwall.com
Subject: Re: Add support for amd64 target
Date: Thu, 17 Mar 2016 23:54:47 -0400	[thread overview]
Message-ID: <20160318035447.GB19612@thinkpad.swarthmore.edu> (raw)
In-Reply-To: <20160318034622.GM21636@brightrain.aerifal.cx>

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.


  reply	other threads:[~2016-03-18  3:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18  2:33 Michael McConville
2016-03-18  3:46 ` Rich Felker
2016-03-18  3:54   ` Michael McConville [this message]
2016-03-18  5:08     ` Isaac Dunham
2016-03-19  4:32       ` Michael McConville
2016-03-18  4:02   ` Michael McConville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160318035447.GB19612@thinkpad.swarthmore.edu \
    --to=mmcco@mykolab.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).