From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6615 Path: news.gmane.org!not-for-mail From: stephen Turner Newsgroups: gmane.linux.lib.musl.general Subject: Re: binutils odd compile behavior Date: Mon, 24 Nov 2014 19:26:31 -0500 Message-ID: References: <20141124234831.GO29621@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b343560764f090508a3f6b7 X-Trace: ger.gmane.org 1416875212 30316 80.91.229.3 (25 Nov 2014 00:26:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Nov 2014 00:26:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6628-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 25 01:26:45 2014 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 1Xt3xs-0002YK-H3 for gllmg-musl@m.gmane.org; Tue, 25 Nov 2014 01:26:44 +0100 Original-Received: (qmail 6095 invoked by uid 550); 25 Nov 2014 00:26:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6087 invoked from network); 25 Nov 2014 00:26:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5zBe+APOWYL8zWXNuShoHAwjl4lmzcTEk0DmVhRUEAo=; b=Ekez3aKwYu0biezz1qMkbxITZYUuzpAQOcZtZMazt1aixqhmSUQKBovKEgJZ9O8VQ+ DrKEEfLt7jBi6ekNDvsNuany5lJsicIQdlyjhTgWEJWThUCRaLQ0oU2DY6Ad/Xyf4nj0 4y5NZXKV1uCLOfEtNLDtVgu6rusXGlSS6nScZcaoJTXDwVe1g2Dpw2Dbj62mIjVcQV8d eXVmx79MyGjz3j6kkx+veR6DJjAfMBgTFPMlZuimv25bmCGGwp3UmrHgOK3BGq3Jvb3b 8vsCDV7uHOMznrbrOfmLOM1YqUvcGRv14zb8DEqQ2qf0fhmr0ifWLrFOhcLXSD8IIkrD XiDA== X-Received: by 10.220.116.197 with SMTP id n5mr13667935vcq.48.1416875191191; Mon, 24 Nov 2014 16:26:31 -0800 (PST) In-Reply-To: <20141124234831.GO29621@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6615 Archived-At: --047d7b343560764f090508a3f6b7 Content-Type: text/plain; charset=UTF-8 On Nov 24, 2014 6:48 PM, "Rich Felker" wrote: > > On Mon, Nov 24, 2014 at 03:18:42PM -0500, stephen Turner wrote: > > I dont know if im being filtered, ignored, or overlooked for the recent > > work on atomics but i found an oddity and if its a concern to anyone let me > > know and i will get you the info you want. > > Which particular message are you waiting for a reasponse to? > At present I havent recievied even a "its your fault" for the email on headers (which was my fault anyways) or several others, however fwiw I have moved past those issues. Everyone I think was overlooking it (understandably so) because they knew it was a id10t error and were focused on the atomics work coming through. > > I built a chroot environment using busybox, binutils 2.24 and gcc 4.2.1. > > While in the chroot i could not compile binutils. > > > > I keep a seperate code directory and build directory. When i build binutils > > outside of the code directory it normally builds fine until i enter the > > newly built musl chroot and then it starts to have errors with bfd. If > > however i go into the binutils directory and compile (against > > recommendations on lfs etc) it works fine. > > Without actually describing the errors you're getting and the > procedure that led to them, there's not much hope to guess what the > cause is. > > > I have the same issue when building musl only it works that way on debian > > or my musl system. If i compile musl in a seperate build folder it errors > > out but running the build from within the source folder works fine. > > musl does not support out-of-tree builds. That should probably be > documented explicitly somewhere, but I don't think it is. Sorry. We'd > like to add support for this at some point but there were buggy corner > cases when nsz tried, and the work on this has been put aside for the > time being. So for now you need to build it in-tree. You can duplicate > your tree before building if you want to keep a clean tree, but "make > distclean" should return your build tree to a clean state too. > > Rich I just found out about the musl out of tree issue from another member. Not sure why I would see the same behavior from binutils however. Per the advice of the other list member im cleaning up my build process by not specifying the include and lib dir's to see if that in some way helps with binutils. Thanks, Stephen --047d7b343560764f090508a3f6b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 24, 2014 6:48 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Mon, Nov 24, 2014 at 03:18:42PM -0500, stephen Turner wrote:
> > I dont know if im being filtered, ignored, or overlooked for the = recent
> > work on atomics but i found an oddity and if its a concern to any= one let me
> > know and i will get you the info you want.
>
> Which particular message are you waiting for a reasponse to?
>

At present I havent recievied even a "its your fault&qu= ot; for the email on headers (which was my fault anyways) or several others= , however fwiw I have moved past those issues.

Everyone I think was overlooking it (understandably so) beca= use they knew it was a id10t error and were focused on the atomics work com= ing through.

> > I built a chroot environment using busybox, binuti= ls 2.24 and gcc 4.2.1.
> > While in the chroot i could not compile binutils.
> >
> > I keep a seperate code directory and build directory. When i buil= d binutils
> > outside of the code directory it normally builds fine until i ent= er the
> > newly built musl chroot and then it starts to have errors with bf= d. If
> > however i go into the binutils directory and compile (against
> > recommendations on lfs etc) it works fine.
>
> Without actually describing the errors you're getting and the
> procedure that led to them, there's not much hope to guess what th= e
> cause is.
>
> > I have the same issue when building musl only it works that way o= n debian
> > or my musl system. If i compile musl in a seperate build folder i= t errors
> > out but running the build from within the source folder works fin= e.
>
> musl does not support out-of-tree builds. That should probably be
> documented explicitly somewhere, but I don't think it is. Sorry. W= e'd
> like to add support for this at some point but there were buggy corner=
> cases when nsz tried, and the work on this has been put aside for the<= br> > time being. So for now you need to build it in-tree. You can duplicate=
> your tree before building if you want to keep a clean tree, but "= make
> distclean" should return your build tree to a clean state too. >
> Rich

I just found out about the musl out of tree issue from anoth= er member. Not sure why I would see the same behavior from binutils however= . Per the advice of the other list member im cleaning up my build process b= y not specifying the include and lib dir's to see if that in some way h= elps with binutils.

Thanks,
Stephen

--047d7b343560764f090508a3f6b7--