Bryan Kadzban wrote:
> echo "slibdir=/lib64" >>configparms
>
> before building (not sure why).
>
If you dont put that in it places all the output from the glibc build
into /usr/lib64
Best Regards
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.o
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> (I have a fairly large collection of build64 scripts that hold what
>> I've done for various packages to get their libs into the right
>> directory. This is for LFS, chunks of BLFS, and several beyond-BLFS
>> packages. The *vast* majority needed not
Greg Schafer wrote:
> Ryan Oliver wrote:
>
>
>> LFS not affected in regards to the fact we can set any of
>> md_startfile_prefix{,_1} or startfile_prefix_spec in the specs file and
>> have it work because we DO use a standard specs file in the appropriate
>> place.
>>
>
> I'll restate in
On Dec 17, 2008, at 4:06 PM, Greg Schafer wrote:
>
> Sorry dude. You can't just blow back in here years after being MIA and
> expect folks to listen to your idle speculation. Folks will take
> notice
> when you have something concrete to offer i.e. well thought out,
> tested
> and published fo
Ryan Oliver wrote:
> LFS not affected in regards to the fact we can set any of
> md_startfile_prefix{,_1} or startfile_prefix_spec in the specs file and
> have it work because we DO use a standard specs file in the appropriate
> place.
I'll restate in clear terms. You're modifying/creating fil
Jeremy Huntwork wrote:
> Ryan Oliver wrote:
>
> [snip]
>
>
>> Just some thoughts
>>
>
> Ryan, thanks for the feedback. I don't have anything specific to say in
> connection with any of your points yet (I guess no one else does
> either), but I will be looking them over in more detail as I
Greg Schafer wrote:
> Ryan Oliver wrote:
>
>> LFS isn't affected by the "-specs handling bug" as we do not pass
>> -specs=/some/specfile on the gcc command line
>>
>
> ??? Not affected? LFS doesn't have the clean split between the 2 phases
> like DIY does. I can simply wipe the chroot pha
Ryan Oliver wrote:
> Couple of minor things
>
> 1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be
> using the newly created binutils to build your new gcc.
Correct. DIY takes care of this with the `-B/usr/bin/' thing. Whether it
actually matters much is questionable. As pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Huntwork wrote:
> Bryan Kadzban wrote:
>> The dynamic linker *must* be /lib64/ld-linux-x86-64.so.2 for a 64-bit
>> executable, and *must* be /lib/ld-linux.so.2 for a 32-bit executable.
>> Otherwise binaries that weren't built on the system won't
Bryan Kadzban wrote:
> ABI issues. Or at least, last time I remember seeing this idea on some
> list or other (perhaps it was CLFS? perhaps DIY? can't remember for
> sure), this was the reason for keeping /lib64 and /lib.
>
> The dynamic linker *must* be /lib64/ld-linux-x86-64.so.2 for a 64-bit
Jeremy Huntwork wrote:
> Specifically, DIY currently has 64-bit libs in /lib64 and /usr/lib64 and
> 32-bit libs in /lib, /usr/lib.
As does *every* normal distro I've seen that supports multilib...
(...)
> This way, both libraries are clearly identified and the default location
> of lib agrees
Ryan Oliver wrote:
[snip]
> Just some thoughts
Ryan, thanks for the feedback. I don't have anything specific to say in
connection with any of your points yet (I guess no one else does
either), but I will be looking them over in more detail as I have a free
moment, so I'm bookmarking this thre
Ryan Oliver wrote:
> STARTFILE_PREFIX_SPEC is unpalatable to some for whatever reason, yet it
> still exists in the gcc code to provide the only mechanism to override
> the search path used for finding startfiles when cross-compiling (see
> gcc.c line 6332, read the code and comments)
>
> You sh
Jeremy Huntwork wrote:
> ...Mostly.
>
> With revision 8755, the new build method from DIY is in place with the
> exception of support for multilib. (More on that in a second.)
>
> I tried to make as many textual changes as I could to keep the accuracy
> of the book on a high level, but I'm sure I
Bruce Dubbs wrote:
> In academia, the accepted method of using other authors' ideas is to just
> create
> a bibliographic entry. In BLFS, the first section of the Introduction is
> Acknowledgments, but there is no similar section in LFS. Perhaps a similar
> section should be added to the LFS
Olaf wrote:
> Bruce Dubbs wrote:
>> In academia, the accepted method of using other authors' ideas is to just
>> create
>> a bibliographic entry. In BLFS, the first section of the Introduction is
>> Acknowledgments, but there is no similar section in LFS. Perhaps a similar
>> section should b
Bruce Dubbs wrote:
> In academia, the accepted method of using other authors' ideas is to just
> create
> a bibliographic entry. In BLFS, the first section of the Introduction is
> Acknowledgments, but there is no similar section in LFS. Perhaps a similar
> section should be added to the LFS
Bruce Dubbs wrote:
> In BLFS, the first section of the Introduction is
> Acknowledgments, but there is no similar section in LFS. Perhaps a similar
> section should be added to the LFS Preface.
>
I have suggested this a few times off list. I think it would be a good
addition. It's right up
Jim Gifford wrote:
> Jeremy Huntwork wrote:
>> Jim, you have not yet said how you would like CLFS to be credited.
> The license specifies the terms.
> http://cross-lfs.org/view/1.1.0/x86/appendices/license.html
Jim,
I took a look at the page and am having a bit of difficulty in determining how
Jeremy Huntwork wrote:
> Bruce Dubbs wrote:
>
>> Jim Gifford wrote:
>>
>>> Your violating his license if you don't put it in. Why play these petty
>>> games, you need to include his license and the terms of his license,
>>> since you have fully stated that your borrowed from his work.
>>>
Bruce Dubbs wrote:
> Jim Gifford wrote:
>> Your violating his license if you don't put it in. Why play these petty
>> games, you need to include his license and the terms of his license,
>> since you have fully stated that your borrowed from his work.
>
> Jeremy's request is reasonable, Jim. I
Jim Gifford wrote:
> Enough on that subject,
OK. Time to move on.
> As far as LFS Dev privs, thanx but no thanx. You can delete them, not to
> mention, someone changed by password on me a while back, because they
> were afraid when CLFS moved away to it's own servers. I have no interest
> i
Bruce Dubbs wrote:
> Jeremy's request is reasonable, Jim. I don't think there was ever any
> thought
> of not giving proper attribution to either Greg or CLFS.
>
> Please give us a break here. The changes are reasonably large and everything
> wasn't perfect on the first commit. All this will
On Dec 6, 2008, at 11:49 PM, Bruce Dubbs wrote:
> William Harrington wrote:
>
>> It's a community endeavor and each project with it's own goal. Each
>> project
>> may borrow from another, and each project needs to give credit to
>> the source.
>> If any part of the source is used credit needs
William Harrington wrote:
> It's a community endeavor and each project with it's own goal. Each project
> may borrow from another, and each project needs to give credit to the source.
> If any part of the source is used credit needs to be given. It's a black and
> white line.
William,
While I
Enough!
If someone is going to borrow someone's work credit needs to be made.
I don't care the degree of the final product.
Impressing people cause of the work they claim they do without credit
to the author is worse
than throwing 3 strikes in a row at a bowling alley with Uncle
Knicknak's a
Jim Gifford wrote:
> Jeremy Huntwork wrote:
>> Greg Schafer wrote:
>>
>>> the Acknowledgments page will suffice. "... Technical Writer and Architect
>>> of the Next Generation 64-bit-enabling Build Method" or similar.
>>>
>> I'll give you a day or so to decide on the exact wording you prefe
Jeremy Huntwork wrote:
> Greg Schafer wrote:
>
>> the Acknowledgments page will suffice. "... Technical Writer and Architect
>> of the Next Generation 64-bit-enabling Build Method" or similar.
>>
>
> I'll give you a day or so to decide on the exact wording you prefer, or
> for someone else
Greg Schafer wrote:
> the Acknowledgments page will suffice. "... Technical Writer and Architect
> of the Next Generation 64-bit-enabling Build Method" or similar.
I'll give you a day or so to decide on the exact wording you prefer, or
for someone else to offer a suggestion. Then I'll add this in
Greg Schafer wrote:
> Jeremy Huntwork wrote:
>
>> Knock it off. I don't come to DIY and disparage your work.
>
> Huh? Get over yourself dude. You've *always* taken things so personally.
> Grow a thick skin.
I'm not personally bothered in the least.
> Remember I'm trying to support *you* impleme
Jeremy Huntwork wrote:
> Knock it off. I don't come to DIY and disparage your work.
Huh? Get over yourself dude. You've *always* taken things so personally.
Grow a thick skin.
Remember I'm trying to support *you* implementing *my* work. Watch your
tone and focus on the task at hand. Thanks.
Reg
Greg Schafer wrote:
> No. You've also omitted perhaps the most interesting feature of the whole
> thing - the ability to migrate from a 32-bit system to a 64-bit system. As
> it currently stands, you're forcing folks to start from a 64-bit system if
> they want 64-bit. Useless.
Greg, c'mon. You kn
Greg Schafer wrote:
> The other thing you've omitted is proper attribution. A simple "Thanks,
> me" is not good enough for something this big. The LFS changelog is not
> perpetual. You of all people should know how much time and effort goes
> into engineering this stuff. Some extra words next to my
Jeremy Huntwork wrote:
> With revision 8755, the new build method from DIY is in place with the
> exception of support for multilib. (More on that in a second.)
No. You've also omitted perhaps the most interesting feature of the whole
thing - the ability to migrate from a 32-bit system to a 64-bi
Matthew Burgess wrote:
> Oh, how trivial! Thanks muchly, the build had only gotten part way through
> gcc-pass1, so I didn't lose too time thanks to your quick reply!
Glad to help. :) Looking forward to seeing how the build goes.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FA
On Sat, 06 Dec 2008 07:37:38 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>> On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork
> <[EMAIL PROTECTED]> wrote:
>>
>>> Another side note, jhalfs can't currently handle the new build method
>>> becuase it hard-codes the buil
Matthew Burgess wrote:
> On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> Another side note, jhalfs can't currently handle the new build method
>> becuase it hard-codes the build user's .bashrc file. A slight tweak in
>> jhalfs to match what is now in Chapter 4 s
On Fri, 05 Dec 2008 15:58:24 -0500, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Another side note, jhalfs can't currently handle the new build method
> becuase it hard-codes the build user's .bashrc file. A slight tweak in
> jhalfs to match what is now in Chapter 4 should take care of it. CCing
>
On Fri, Dec 05, 2008 at 06:54:51PM -0800, Bryan Kadzban wrote:
> Ken Moffat wrote:
> > Last time this was discussed, the general view seemed to be that
> > pure64 was a step far enough. Care to remind me what the advantages
> > of multilib builds are ?
>
> For me: Flash. Either "standard" flash
Ken Moffat wrote:
> Last time this was discussed, the general view seemed to be that
> pure64 was a step far enough. Care to remind me what the advantages
> of multilib builds are ?
For me: Flash. Either "standard" flash, or nspluginwrapper-flash --
both require 32-bit libs somewhere. (nsplugi
On Dec 5, 2008, at 6:56 PM, Ken Moffat wrote:
Last time this was discussed, the general view seemed to be that
pure64 was a step far enough. Care to remind me what the advantages
of multilib builds are ? I'm looking at the "whole system" here,
most of which is in BLFS (or, for existing multil
On Fri, Dec 05, 2008 at 03:58:24PM -0500, Jeremy Huntwork wrote:
>
> http://www.linuxfromscratch.org/~jhuntwork/lfs-trunk
>
> There is no technical hindrance to bringing in multilib, the changes are
> minimal. The effect is not so minimal. I would like to know people's
> thoughts on how to deal
Jeremy Huntwork wrote:
> There is no technical hindrance to bringing in multilib, the changes are
> minimal. The effect is not so minimal. I would like to know people's
> thoughts on how to deal with multilib in LFS. Specifically, how do we
> handle for x86, where multilib is not an option? Do w
...Mostly.
With revision 8755, the new build method from DIY is in place with the
exception of support for multilib. (More on that in a second.)
I tried to make as many textual changes as I could to keep the accuracy
of the book on a high level, but I'm sure I missed some things that
reference
44 matches
Mail list logo
