From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9680 Path: news.gmane.org!not-for-mail From: Michael McConville Newsgroups: gmane.linux.lib.musl.general Subject: Re: Add support for amd64 target Date: Thu, 17 Mar 2016 23:54:47 -0400 Message-ID: <20160318035447.GB19612@thinkpad.swarthmore.edu> References: <20160318023341.GB71208@thinkpad.swarthmore.edu> <20160318034622.GM21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1458273310 8674 80.91.229.3 (18 Mar 2016 03:55:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Mar 2016 03:55:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9693-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 18 04:55:06 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aglVB-0004Si-T7 for gllmg-musl@m.gmane.org; Fri, 18 Mar 2016 04:55:05 +0100 Original-Received: (qmail 27882 invoked by uid 550); 18 Mar 2016 03:55:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 27849 invoked from network); 18 Mar 2016 03:55:03 -0000 X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.31 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Content-Disposition: inline In-Reply-To: <20160318034622.GM21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9680 Archived-At: 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.