Le 20/03/2012 22:53, g@free.fr a écrit :
> Would not using something like
> export GZIP='-n'
> solve the include timestamp issue?
>
> Gilles
Well, anyway, unzipping files allows to compare them more easily.
And I think it would not be safe to change book instructions just for the
purpose of doi
- Mail original -
> De: "Pierre Labastie"
> À: "LFS Developers Mailinglist"
> Envoyé: Mardi 20 Mars 2012 22:26:32
> Objet: Re: [lfs-dev] Build method revisions
>
> - Gunzip all the .gz files (gzip puts a time stamp)
Would not using something l
Le 20/03/2012 05:24, Bryan Kadzban a écrit :
> That's weird. There are no differences in the strip binaries (when you
> do strip the libraries), right? Or in libbfd.so.whatever-it-is?
Actually, in the book, the binaries in {,/usr}{/bin,/sbin} are stripped,
and the
libraries in {,/usr}lib from de
Pierre Labastie wrote:
> Le 18/03/2012 23:56, Bryan Kadzban a écrit :
>>> I am not sure I fully understand this story of relocation data...
>>>
>> I'd have to guess different flags sent to the linker. As for *why*
>> those flags are being sent differently... no idea yet. :-) I
>> should get so
Le 18/03/2012 23:56, Bryan Kadzban a écrit :
>
>> I am not sure I fully understand this story of relocation data...
> I'd have to guess different flags sent to the linker. As for *why*
> those flags are being sent differently... no idea yet. :-) I should
> get some hardware and start rebuilding
On 3/18/12 6:44 PM, Bryan Kadzban wrote:
> Well, from the comments in the book, it's not libc; it's crt1/crt0/crtn,
> or whatever the files are named these days.
Yes, you are correct, it's the start files it can't find. I was just
being imprecise.
> One other thing I'm concerned about is enablin
Pierre Labastie wrote:
> Now I have done it, but I do not fully understand what is going on.
> The comparison between current build and Jeremy's is done in ICA style:
> First remove all symlinks,
> Then extract archives into a directory with the same name
> Then stripping ".o" files from debug symb
Jeremy Huntwork wrote:
> On 3/16/12 3:22 AM, Bryan Kadzban wrote:
>> That being said, is editing the pass1 gcc sources with sed (editing
>> the STANDARD_STARTFILE_PREFIX_? values, and the header directories)
>> better, or worse, than reverting upstream changes in pass2? I
>> don't suppose there's
Jeremy Huntwork wrote:
> On 3/14/12 11:32 PM, Bryan Kadzban wrote:
>> It *almost* looks like sysroot is the equivalent of a DESTDIR
>> install, where all the libs are installed into> prefix>/whatever/path, but ask for /whatever/path at runtime (e.g.
>> when ld.so is looking for DT_NEEDED entries, o
On Fri, 16 Mar 2012 22:29:29 -0400, Jeremy Huntwork wrote:
> Greg, there's no need to make this personal.
No worries dude. Not trying to cause trouble so my apologies if you've
taken any offence. I just tend to get passionate about build method
matters.
> It was mostly reading those (and bits
On 3/17/12 8:25 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> I killed the jh branch some weeks back (I don't think I had touched it
>> since 2008) but we could re-create it again, if you like.
>
> Sure. I just re-created it.
Great, thanks.
> Do you want me to set up a daily build?
Not jus
Qrux wrote:
> On Mar 17, 2012, at 2:38 PM, Bruce Dubbs wrote:
>
>>> Bruce Dubbs wrote:
>>>
Matt and I are very reluctant to change a working
implementation.
>>> ...
>> Until gcc-4.7 comes out I'm recommending we use the exiting jh
> -->
Jeremy Huntwork wrote:
> On 3/17/12 5:38 PM, Bruce Dubbs wrote:
>> Until gcc-4.7 comes out I'm recommending we use the exiting jh branch of
>> lfs and go ahead and put in these changes now with the release candidate
>> packages. Then we can do some jhalfs style builds and test things out
>> from t
On Mar 17, 2012, at 2:38 PM, Bruce Dubbs wrote:
>> Bruce Dubbs wrote:
>>
>>> Matt and I are very reluctant to change a working
>>> implementation.
>> ...
> Until gcc-4.7 comes out I'm recommending we use the exiting jh
--> ^^^
> branch of lf
On 3/17/12 5:38 PM, Bruce Dubbs wrote:
> Until gcc-4.7 comes out I'm recommending we use the exiting jh branch of
> lfs and go ahead and put in these changes now with the release candidate
> packages. Then we can do some jhalfs style builds and test things out
> from there. When the new tool chai
Qrux wrote:
> On Mar 17, 2012, at 2:38 PM, Bruce Dubbs wrote:
>
>>> Bruce Dubbs wrote:
>>>
Matt and I are very reluctant to change a working
implementation. From what we can gather, gcc-4.7/glibc-2.15(?)
changes things and will require some LFS changes. We need to
be concent
On Mar 17, 2012, at 2:38 PM, Bruce Dubbs wrote:
>> Bruce Dubbs wrote:
>>
>>> Matt and I are very reluctant to change a working implementation.
>>> From what we can gather, gcc-4.7/glibc-2.15(?) changes things and will
>>> require some LFS changes. We need to be concentrating on that.
>>
>
Le 16/03/2012 07:45, Bryan Kadzban a écrit :
> Pierre Labastie wrote:
>> Le 15/03/2012 04:32, Bryan Kadzban a écrit :
>>> This may have been covered in this thread already, but I don't
>>> recall anymore -- did you do an ICA run with this change?
>> I have not taken the time to directly compare the
Andrew Benton wrote:
> On Sat, 17 Mar 2012 16:27:34 +
> Bruce Dubbs wrote:
>
>>Matt and I are very reluctant to change a working implementation.
>> From what we can gather, gcc-4.7/glibc-2.15(?) changes things and will
>> require some LFS changes. We need to be concentrating on that.
On Sat, 2012-03-17 at 21:12 +, Andrew Benton wrote:
> On Sat, 17 Mar 2012 16:27:34 +
> Bruce Dubbs wrote:
>
> >Matt and I are very reluctant to change a working implementation.
> > From what we can gather, gcc-4.7/glibc-2.15(?) changes things and will
> > require some LFS changes.
On Sat, 17 Mar 2012 16:27:34 +
Bruce Dubbs wrote:
>Matt and I are very reluctant to change a working implementation.
> From what we can gather, gcc-4.7/glibc-2.15(?) changes things and will
> require some LFS changes. We need to be concentrating on that.
In my experience Jeremy's bui
On 3/16/12 3:22 AM, Bryan Kadzban wrote:
> Removing the need for adjusting the toolchain does seem to hurt
> teaching; we're using some magic flags instead of editing the specs
> file. (OTOH the specs file is now more of a builtin thing in the gcc
> driver. I do still think it's useful to know ab
On 3/14/12 11:32 PM, Bryan Kadzban wrote:
> It *almost* looks like sysroot is the equivalent of a DESTDIR install,
> where all the libs are installed into/whatever/path,
> but ask for /whatever/path at runtime (e.g. when ld.so is looking for
> DT_NEEDED entries, or in DT_RPATH entries in libs thems
On 3/17/12 12:26 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> Everyone else, please do review all of the links and posts that Greg
>> provided. It was mostly reading those (and bits of the source) as well
>> as the tests/experimentation that convinced me that the proposed method
>> is solid
Jeremy Huntwork wrote:
> Everyone else, please do review all of the links and posts that Greg
> provided. It was mostly reading those (and bits of the source) as well
> as the tests/experimentation that convinced me that the proposed method
> is solid.
Jeremy,
Matt and I are very reluctant
On 3/15/12 4:51 PM, Greg Schafer wrote:
> On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote:
>
>> It seems that Greg never got the time to comment any more thoroughly on
>> the modifications, either. I'd kinda like to hear what he has to say,
>
> Well, I've been doing a lot of reading in ord
Greg Schafer wrote:
> The sysroot infrastructure is clearly designed for a $SYSROOT/usr
> layout which we DO NOT HAVE in the temporary phase!
Yeah, that's why my previous message was more or less comparing it to a
DESTDIR type installation. That may not be accurate, but it seems
vaguely similar.
Pierre Labastie wrote:
> Le 15/03/2012 04:32, Bryan Kadzban a écrit :
>> This may have been covered in this thread already, but I don't
>> recall anymore -- did you do an ICA run with this change?
> What I have done:
> http://linuxfromscratch.org/pipermail/lfs-dev/2012-March/065866.html
OK, yeah,
On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote:
> It seems that Greg never got the time to comment any more thoroughly on
> the modifications, either. I'd kinda like to hear what he has to say,
Well, I've been doing a lot of reading in order to get back up-to-speed.
One of the reasons
On Thu, 15 Mar 2012 02:05:49 +
Jeremy Huntwork wrote:
> Has anyone else had a chance to try out the build fully and compare? I'm
> waiting to hear more of a consensus from others who have tested it
> before I drop this in, although I'm confident it's sound.
It works for me. I've integrated
Le 15/03/2012 04:32, Bryan Kadzban a écrit :
> Jeremy Huntwork wrote:
>> On 3/8/12 4:24 PM, Bruce Dubbs wrote:
>>> Jeremy Huntwork wrote:
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
> Yes, I saw that. Reviewing.
How is that coming along?
>>> Not well, sorry. I've got some personal things
On Wed, Mar 14, 2012 at 8:32 PM, Bryan Kadzban
wrote:
> Jeremy Huntwork wrote:
>> On 3/8/12 4:24 PM, Bruce Dubbs wrote:
>>> Jeremy Huntwork wrote:
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
> Yes, I saw that. Reviewing.
How is that coming along?
>>> Not well, sorry. I've got some perso
Jeremy Huntwork wrote:
> On 3/8/12 4:24 PM, Bruce Dubbs wrote:
>> Jeremy Huntwork wrote:
>>> On 3/2/12 11:10 AM, Bruce Dubbs wrote:
Yes, I saw that. Reviewing.
>>> How is that coming along?
>> Not well, sorry. I've got some personal things going on right now
>> and can't get to it. I'll loo
On 3/8/12 4:24 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> On 3/2/12 11:10 AM, Bruce Dubbs wrote:
--- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
23:31:31.789317951 -0500
+++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
00:29:16.11769736
Jeremy Huntwork wrote:
> On 3/2/12 11:10 AM, Bruce Dubbs wrote:
>>> --- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
>>> 23:31:31.789317951 -0500
>>> +++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
>>> 00:29:16.117697363 -0500
>> Yes, I saw that. Reviewing.
>
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
>> --- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
>> 23:31:31.789317951 -0500
>> +++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
>> 00:29:16.117697363 -0500
>
> Yes, I saw that. Reviewing.
How is that coming along?
J
On 3/5/12 6:57 PM, Qrux wrote:
>
> On Mar 4, 2012, at 7:10 AM, Jeremy Huntwork wrote:
>
>> On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
>>> And because of the pre-adjusting there's even less chance to bring in
>>> something from the host system. The limits.h file is an example. The
>>> first pass of G
On Mar 4, 2012, at 7:10 AM, Jeremy Huntwork wrote:
> On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
>> And because of the pre-adjusting there's even less chance to bring in
>> something from the host system. The limits.h file is an example. The
>> first pass of GCC doesn't install a full-featured limi
On 3/4/12 10:10 AM, Jeremy Huntwork wrote:
> For the proposed build method, this does not appear to be the case:
>
> Fixing headers into /mnt/lfs/sources/gcc-build/gcc/include-fixed for
> x86_64-unknown-linux-gnu target
> Forbidden identifiers: linux unix
> Finding directories and links to director
On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
> And because of the pre-adjusting there's even less chance to bring in
> something from the host system. The limits.h file is an example. The
> first pass of GCC doesn't install a full-featured limits.h file because
> it can't find one in the include paths
Ken Moffat wrote:
> On Fri, Mar 02, 2012 at 10:07:26PM -0600, Bruce Dubbs wrote:
>> Qrux wrote:
>>> *whew* I was starting to think I was the only one who'd ever
>>> considered running LFS (or a very close derivative) in production.
>> I've been doing that since 2004. And the lfs servers are runni
On Fri, Mar 02, 2012 at 10:07:26PM -0600, Bruce Dubbs wrote:
> Qrux wrote:
> >
> > *whew* I was starting to think I was the only one who'd ever
> > considered running LFS (or a very close derivative) in production.
>
> I've been doing that since 2004. And the lfs servers are running lfs.
> I'd
On Mar 2, 2012, at 8:07 PM, Bruce Dubbs wrote:
> Qrux wrote:
>> On Mar 2, 2012, at 4:26 PM, James Robertson wrote:
>>> On Mar 1, 2012 2:49 PM, "Ken Moffat"
>>> wrote:
Actually, we used to have a guy who did run production servers -
>>> LOL. I still do. I am much more efficient than in years
Qrux wrote:
> On Mar 2, 2012, at 4:26 PM, James Robertson wrote:
>> On Mar 1, 2012 2:49 PM, "Ken Moffat"
>> wrote:
>>> Actually, we used to have a guy who did run production servers -
>>> but he spent a lot of time keeping them up to date, and he built
>>> on one machine and then rolled the binari
On Mar 2, 2012, at 4:26 PM, James Robertson wrote:
> On Mar 1, 2012 2:49 PM, "Ken Moffat" wrote:
> >
> > Actually, we used to have a guy who did run production
> > servers - but he spent a lot of time keeping them up to date, and he
> > built on one machine and then rolled the binaries out to the
On Mar 1, 2012 2:49 PM, "Ken Moffat" wrote:
>
> Actually, we used to have a guy who did run production
> servers - but he spent a lot of time keeping them up to date, and he
> built on one machine and then rolled the binaries out to the others
> after testing.
LOL. I still do. I am much more effi
Jeremy Huntwork wrote:
> On 3/2/12 12:44 AM, Jeremy Huntwork wrote:
>> when using sysroot as opposed to not. The "+"s are with sysroot.
>
> Sorry, that's backwards - I made one patch originally the other way and
> then regdiffed it a second time later.
>
> The top line of the diff should be desc
On 3/2/12 12:44 AM, Jeremy Huntwork wrote:
> when using sysroot as opposed to not. The "+"s are with sysroot.
Sorry, that's backwards - I made one patch originally the other way and
then regdiffed it a second time later.
The top line of the diff should be descriptive enough:
--- binutils-build-
On 3/1/12 6:49 PM, Bruce Dubbs wrote:
You propose adding
--with-sysroot=$LFS\
--with-lib-path=/tools/lib \
The idea of sysroot is that its supposed to configure your compiler and
linker to consider DIR as the root location where resources for your
cross target live.
~/bi
Jeremy Huntwork wrote:
> On 3/1/12 3:48 PM, Bruce Dubbs wrote:
>> Could you please explain (again) the advantages of your proposal over
>> the current process.
>
> The biggest advantages are that we don't have to maintain a patch that
> reverts upstream changes to make our build system work (the
On 3/1/12 5:22 PM, Greg Schafer wrote:
> Instead of vague assertions about "upstream intentions" and the like, I'd
> really appreciate it (if you are going to meddle with the toolchain build
> method) that you at least do what I have done for years and offer
> detailed analysis and testing and full
Greg Schafer wrote:
> On Thu, 01 Mar 2012 16:27:31 -0500, Jeremy Huntwork wrote:
>
>> And that's it. It's cleaner, more direct, and more closely tracks what
>> upstream has provided.
>
> I'm sorry to say this but your whole premise is based on hearsay and
> personal opinion.
>
> Instead of vagu
On Thu, 01 Mar 2012 16:27:31 -0500, Jeremy Huntwork wrote:
> And that's it. It's cleaner, more direct, and more closely tracks what
> upstream has provided.
I'm sorry to say this but your whole premise is based on hearsay and
personal opinion.
Instead of vague assertions about "upstream intenti
Qrux wrote:
> I assume LFS is often not used -as is-, unless it's being run
> console-only (which is usable, but seems like a harsh working
> environment). I'm guessing that use-case is rare. I would also
> guess most people either run it headless but connect via SSH, or run
> it with X; the poi
On 3/1/12 4:10 PM, Bruce Dubbs wrote:
>> 3) Commit-triggered build would require something that pulls the
>> scripts out of the book pages and assembles them in a build-able
>> format. Does that exist?
>
> Yes, we have a script that downloads the xml and rebuilds the book and
> puts it into place.
On 3/1/12 3:58 PM, Ken Moffat wrote:
> Apologies to JH for allowing myself to be drawn OT now that he's
> pulled that branch.
:) No worries. It's good to hear where everyone stands. And perhaps we
can revisit it in the not too distant future.
JH
--
http://linuxfromscratch.org/mailman/listinf
On 3/1/12 3:47 PM, Qrux wrote:
> That's good. Smells like common ground.
>
> So, what are you advocating as far as testing goes? Bruce just brought up a
> good point about ownership and accountability. It does seem unclear who
> should be testing. What are your thoughts about that, especially
On 3/1/12 3:48 PM, Bruce Dubbs wrote:
> Could you please explain (again) the advantages of your proposal over
> the current process.
The biggest advantages are that we don't have to maintain a patch that
reverts upstream changes to make our build system work (the pass2
startfiles fix patch) and
On Mar 1, 2012, at 12:38 PM, Ken Moffat wrote:
> On Thu, Mar 01, 2012 at 11:30:00AM -0800, Qrux wrote:
>>
>> You're point seems to boil down to: "Don't overreact. 95% of stuff will
>> work."
>
> You could, with equal justification, have said the same about
> changes in many previous LFS relea
Qrux wrote:
> On Mar 1, 2012, at 11:55 AM, Bruce Dubbs wrote:
>
>> Qrux wrote:
>>
>>> I'm not sure why there's so much opposition to it.
>> There isn't opposition to testing, but who is going to do all the
>> testing needed?
>
> If we're asking buy questions, we'd also have to include some wher
On Thu, Mar 01, 2012 at 08:38:03PM +, Ken Moffat wrote:
>
> If you *can* test the new build method, noting what breaks might
> be helpful. Personally, I have no 32-bit binaries to care about, nor
> any nvidia/ati kernel modules, so I dislike /lib64 (it's unnecessary
> for me, and perhaps cau
On Thu, Mar 01, 2012 at 12:33:21PM -0800, Qrux wrote:
>
> 3) Commit-triggered build would require something that pulls the scripts out
> of the book pages and assembles them in a build-able format. Does that exist?
>
For LFS, the editors normally build the whole of LFS before
committing, altho
Jeremy Huntwork wrote:
> This discussion isn't about
> trying to get lib64 changes into the book in the very near future. It
> should be about how sysroot affects the bootstrap process,
OK, let's start over. I tried to follow what you are saying, but wasn't
able to understand it completely.
On Mar 1, 2012, at 12:18 PM, Jeremy Huntwork wrote:
> On 3/1/12 2:30 PM, Qrux wrote:
>
>> Why not pursue a course more like: "Let's get some downstream (e.g., BLFS,
>> CLFS) people to see what the actual impact of my proposed changes will be to
>> actual consumers of LFS."
>
> That has always
On Thu, Mar 01, 2012 at 11:30:00AM -0800, Qrux wrote:
>
> You're point seems to boil down to: "Don't overreact. 95% of stuff will
> work." And, you seem to be implying: "Meh--downstream stuff...whatever.
> Your problem." Do you not see the value to other people who think:
> "Currently, 100%
On Mar 1, 2012, at 11:55 AM, Bruce Dubbs wrote:
> Qrux wrote:
>
>> I'm not sure why there's so much opposition to it.
>
> There isn't opposition to testing, but who is going to do all the
> testing needed?
If we're asking buy questions, we'd also have to include some where and how
questions
On 3/1/12 2:30 PM, Qrux wrote:
> You seem to be saying: "Okay...We break the not-fixable stuff--BUT,
> HEY--that's the only thing that prevents this from being the right thing to
> do."
No, that's not what I am saying. I'm saying everything is fixable and
the unknown issues this will bring up
Qrux wrote:
> It's not about whether or not it's "fixable".
>
> The point is the time.
>
> It takes time to figure these things out. This one small
> issue--originally intended as a potential alert to the impact that these
> changes might have--has already involved 3 people and several hou
On Mar 1, 2012, at 9:32 AM, Jeremy Huntwork wrote:
> I'm saying that if you are compiling the libs and binaries, it should
> conform to the configuration of your toolchain. I say 'should'
I never said your way of building the toolchain is wrong--I haven't even
looked. I'm sure it's great. I'
On Mar 1, 2012, at 10:40 AM, Andrew Benton wrote:
> On Thu, 1 Mar 2012 08:43:05 -0800
> Qrux wrote:
>
>> [~/lfs/src/openssl-1.0.0e] # grep ENGINESDIR $(find . -name "*.c" -o -name
>> "*.h")
>> ./crypto/engine/eng_list.c: if((load_dir =
>> getenv("OPENSSL_ENGINES")) == 0) load_dir = E
On Thu, 1 Mar 2012 08:43:05 -0800
Qrux wrote:
> [~/lfs/src/openssl-1.0.0e] # grep ENGINESDIR $(find . -name "*.c" -o -name
> "*.h")
> ./crypto/engine/eng_list.c: if((load_dir =
> getenv("OPENSSL_ENGINES")) == 0) load_dir = ENGINESDIR;
> ./crypto/opensslconf.h:#define ENGINESDIR "/usr/
On 3/1/12 11:43 AM, Qrux wrote:
> What, specifically, are you addressing when you say "shouldn't care"? Are
> you speaking theoretically about how BIND should be designed? Or
> practically, based on knowledge of the source? Just to be clear, I'm
> specifically talking about the ssl-engine/lib
On Feb 29, 2012, at 10:46 PM, Jeremy Huntwork wrote:
> Just to be clear - the BIND code itself shouldn't care about lib or
> lib64.
What, specifically, are you addressing when you say "shouldn't care"? Are you
speaking theoretically about how BIND should be designed? Or practically,
based o
On 2/29/12 11:33 PM, Qrux wrote:
> Irony aside, I think it's fine to ask people to clarify, to prevent confusion
> and save the time spent down rabbit holes.
Absolutely, that's what learning and sharing knowledge is all about. It
sounded to me as if you were expressing frustration with Andy and
On Wed, 29 Feb 2012 20:33:49 -0800
Qrux wrote:
> Back to the unanswered question (2): Andrew, does your machine (pure-64
> build) have the LFS-7.0-release toolchain,
It's more like current LFS svn, there are few packages that are not up
to date in my scripts but not many. With kmod I'm actually
On Feb 29, 2012, at 7:03 PM, Jeremy Huntwork wrote:
> On 2/29/12 8:21 PM, Qrux wrote:
>>> It was me that put that in the BLFS page. Thanks for your email to BLFS
>>> dev about the problem with Bind.
>>
>> Why did we go in this circle?
>
> Because he was kindly answering your questions.
Andrew'
Guys, lets be careful with our wording. These are complex things and
it's easy to misunderstand the technical aspects of what is going on and
we don't want to say anything that someone might misread and take offense.
There are a lot of things going on in the Linux world right now. Some
want t
Qrux wrote:
> I would add 3rd party hardware drivers and control programs that
> might be dynamically linked
Oh. Right. Duh.
nvidia-settings, and probably nvidia-installer, are precompiled 64-bit
binaries that still need to work for people that use the nvidia drivers.
:-)
signature.asc
Desc
On 2/29/12 8:21 PM, Qrux wrote:
>> It was me that put that in the BLFS page. Thanks for your email to BLFS
>> dev about the problem with Bind.
>
> Why did we go in this circle?
Because he was kindly answering your questions.
You've been operating on a misunderstanding. There's nothing inherent in
On Feb 29, 2012, at 12:30 PM, Andrew Benton wrote:
> It was me that put that in the BLFS page. Thanks for your email to BLFS
> dev about the problem with Bind.
Why did we go in this circle?
I said BIND needed, minimally, a symlink at /lib64 to work. I realize that
that case is somewhat minor,
On Wed, 29 Feb 2012 04:27:17 -0800
Qrux wrote:
>
> On Feb 29, 2012, at 3:59 AM, Andrew Benton wrote:
>
> > On Tue, 28 Feb 2012 17:02:59 -0800
> > Qrux wrote:
> >
> >> I don't think anyone referred to precomp bins. I presume all discussions
> >> here are about source builds.
> >>
> >> 1) Wh
On Feb 29, 2012, at 3:59 AM, Andrew Benton wrote:
> On Tue, 28 Feb 2012 17:02:59 -0800
> Qrux wrote:
>
>> I don't think anyone referred to precomp bins. I presume all discussions
>> here are about source builds.
>>
>> 1) Which BLFS version?
>
> Current.
That's not precise enough of an answ
On Tue, 28 Feb 2012 17:02:59 -0800
Qrux wrote:
> I don't think anyone referred to precomp bins. I presume all discussions
> here are about source builds.
>
> 1) Which BLFS version?
Current.
> 2) Are you on a 64-bit only platform?
My 64 bit systems are pure x86_64 with everything in /lib.
>
Andrew Benton wrote:
> On Mon, 27 Feb 2012 20:10:28 -0800 Bryan Kadzban
> wrote:
>>
>> Specifically, section 5.2.1.
>
> In practice it works fine and causes no problems. I have everything
> in /lib with no lib64 symlinks. It makes a simpler and more
> straightforward directory structure.
See,
On Feb 28, 2012, at 4:43 PM, Andrew Benton wrote:
> On Tue, 28 Feb 2012 15:15:27 -0800
> Qrux wrote:
>
>> As for the "64-bit" works in practice...BIND is an example of a downstream
>> app that seems to want to look in /lib64. Whether it's looking for
>> ld64.so.1, ld-linux-x86-64.so.2, or so
On Tue, 28 Feb 2012 15:15:27 -0800
Qrux wrote:
> As for the "64-bit" works in practice...BIND is an example of a downstream
> app that seems to want to look in /lib64. Whether it's looking for
> ld64.so.1, ld-linux-x86-64.so.2, or something else even, I can't say. I do
> know that it doesn't
On Feb 28, 2012, at 8:29 AM, Jeremy Huntwork wrote:
> On 2/28/12 10:42 AM, Andrew Benton wrote:
>> Multilib is only of use if you want to run legacy binaries such as
>> windows programs with wine.
>
> Building Xen from source also required a 32bit libc, presumably for
> supporting 32-bit hosts,
On 2/28/12 11:43 AM, Bruce Dubbs wrote:
> I agree that it looks funny. Also, I use an Intel 64 bit system, not
> AMD. What should it be for me?
>
> That said, I think /lib64/ld-linux-x86-64.so.2 is hard coded into
> binutils and changing that would have unknown consequences.
Anything hard coded
Jeremy Huntwork wrote:
> On 2/27/12 11:10 PM, Bryan Kadzban wrote:
>> The 64-bit x86 SysV ABI *REQUIRES* /lib64/ld-linux-x86-64.so.2 to be the
>> runtime linker path. (This is a far more fundamental standard than LSB,
>> as well.) See the (google-docs-import-from-PDF) version of the ABI
>> standa
On 2/28/12 10:42 AM, Andrew Benton wrote:
> Multilib is only of use if you want to run legacy binaries such as
> windows programs with wine.
Building Xen from source also required a 32bit libc, presumably for
supporting 32-bit hosts, although I didn't dig very far to determine why
specifically.
On 2/27/12 11:10 PM, Bryan Kadzban wrote:
> The 64-bit x86 SysV ABI *REQUIRES* /lib64/ld-linux-x86-64.so.2 to be the
> runtime linker path. (This is a far more fundamental standard than LSB,
> as well.) See the (google-docs-import-from-PDF) version of the ABI
> standard:
>
> https://docs.google.c
Fernando de Oliveira wrote:
> Em 28-02-2012 01:25, Bruce Dubbs escreveu:
>> Jeremy Huntwork wrote:
>>
>>> I'd like to commit this to trunk, but I want to hear opinions first.
>> Whoa. We've released lfs-7.1-rc1 and need to keep svn in sync until the
>> 7.1 release is made.
>>
>>-- Bruce
>
>
On 2/28/12 11:10 AM, Matt Burgess wrote:
> It's a shame that configure switch is so-called. It sounds from your
> description as if it really should be called '--without-libc' or
> something similar, as it doesn't actually try to determine/use newlib.
Agreed. I almost prefer modifying gcc/Makefil
On 2/28/12 10:58 AM, Andrew Benton wrote:
> On Mon, 27 Feb 2012 23:31:26 -0500
> Jeremy Huntwork wrote:
>
>> I'll revert the 64-bit stuff and regen the diff.
>
> Sigh...
I know... my experience is like yours, that it does work in practice,
and it just feels simpler and more straightforward. But
On Tue, 2012-02-28 at 10:39 -0500, Jeremy Huntwork wrote:
> On 2/28/12 9:11 AM, Jeremy Huntwork wrote:
> > On 2/28/12 2:10 AM, Greg Schafer wrote:
> >> IMHO
> >> sysroot is fine for real cross compilation
> >> sysroot not fine for hybrid cross/native scenarios a'la current LFS
> >
> > When you disc
On Mon, 27 Feb 2012 23:31:26 -0500
Jeremy Huntwork wrote:
> I'll revert the 64-bit stuff and regen the diff.
Sigh...
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On Mon, 27 Feb 2012 20:10:28 -0800
Bryan Kadzban wrote:
> Jeremy Huntwork wrote:
> > 5. Since we don't support multilib, remove all toolchain uses of
> > lib64. No need for those symlinks any more. Everything goes to lib.
>
> I don't think this is a good idea.
>
> The 64-bit x86 SysV ABI *REQU
On 2/28/12 9:11 AM, Jeremy Huntwork wrote:
> On 2/28/12 2:10 AM, Greg Schafer wrote:
>> IMHO
>> sysroot is fine for real cross compilation
>> sysroot not fine for hybrid cross/native scenarios a'la current LFS
>
> When you discussed the situation requiring the startfiles revert patch
> with upstrea
On Mon, 27 Feb 2012 22:49:07 -0500
Jeremy Huntwork wrote:
> Please review and test the actual changes. I'd like to commit this to
> trunk, but I want to hear opinions first. The rendered book is here:
> http://linuxfromscratch.org/~jhuntwork/sysroot/
>
> And a full diff of the changes is here:
On 2/28/12 8:41 AM, Jeremy Huntwork wrote:
> Indeed. newlib isn't shipped with GCC, the switch appears to just prep
> GCC to expect the functions newlib has. When Ryan first suggested this
> one, he may have intended it to force inhibit_libc variable to be true
> as per http://sourceware.org/ml/cro
1 - 100 of 112 matches
Mail list logo
