* Add support for amd64 target @ 2016-03-18 2:33 Michael McConville 2016-03-18 3:46 ` Rich Felker 0 siblings, 1 reply; 6+ messages in thread From: Michael McConville @ 2016-03-18 2:33 UTC (permalink / raw) To: musl 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. For what it's worth, the build then survives until linking. I haven't had a chance to diagnose that problem yet. Thanks for your time, Michael diff --git a/configure b/configure index 213a825..e961800 100755 --- a/configure +++ b/configure @@ -306,7 +306,7 @@ i?86-nt32*) ARCH=nt32 ;; i?86*) ARCH=i386 ;; x86_64-x32*|x32*|x86_64*x32) ARCH=x32 ;; x86_64-nt64*) ARCH=nt64 ;; -x86_64*) ARCH=x86_64 ;; +x86_64*|amd64*) ARCH=x86_64 ;; mips64*) ARCH=mips64 ;; mips*) ARCH=mips ;; microblaze*) ARCH=microblaze ;; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add support for amd64 target 2016-03-18 2:33 Add support for amd64 target Michael McConville @ 2016-03-18 3:46 ` Rich Felker 2016-03-18 3:54 ` Michael McConville 2016-03-18 4:02 ` Michael McConville 0 siblings, 2 replies; 6+ messages in thread From: Rich Felker @ 2016-03-18 3:46 UTC (permalink / raw) To: musl 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? > 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. Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add support for amd64 target 2016-03-18 3:46 ` Rich Felker @ 2016-03-18 3:54 ` Michael McConville 2016-03-18 5:08 ` Isaac Dunham 2016-03-18 4:02 ` Michael McConville 1 sibling, 1 reply; 6+ messages in thread From: Michael McConville @ 2016-03-18 3:54 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add support for amd64 target 2016-03-18 3:54 ` Michael McConville @ 2016-03-18 5:08 ` Isaac Dunham 2016-03-19 4:32 ` Michael McConville 0 siblings, 1 reply; 6+ messages in thread From: Isaac Dunham @ 2016-03-18 5:08 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add support for amd64 target 2016-03-18 5:08 ` Isaac Dunham @ 2016-03-19 4:32 ` Michael McConville 0 siblings, 0 replies; 6+ messages in thread From: Michael McConville @ 2016-03-19 4:32 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Add support for amd64 target 2016-03-18 3:46 ` Rich Felker 2016-03-18 3:54 ` Michael McConville @ 2016-03-18 4:02 ` Michael McConville 1 sibling, 0 replies; 6+ messages in thread From: Michael McConville @ 2016-03-18 4:02 UTC (permalink / raw) To: musl Rich Felker wrote: > On Thu, Mar 17, 2016 at 10:33:41PM -0400, Michael McConville wrote: > > 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. To clarify: I thought the platform-specific bits would cause more problems at runtime than at compile-time, but the more I think about that the less it makes sense. You're definitely right - getting a reliably working port will take a good deal of work (hence it being offered as a three-month project). It's just nice to know that the actual C code is reasonably portable. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-19 4:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-18 2:33 Add support for amd64 target Michael McConville 2016-03-18 3:46 ` Rich Felker 2016-03-18 3:54 ` Michael McConville 2016-03-18 5:08 ` Isaac Dunham 2016-03-19 4:32 ` Michael McConville 2016-03-18 4:02 ` Michael McConville
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).