Jeremy Huntwork wrote:
> Here's the results from what is currently in the branch:
>
> http://linuxfromscratch.org/~jhuntwork/test.log
> http://linuxfromscratch.org/~jhuntwork/search_dirs.log
One last thing dude. Could you please advise exactly what host system
you're using and also show the outp
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Ken Moffat wrote:
> ip/routef lifesaver
This sounds fairly important, but I have no idea if it actually is...
> incorrect initialization
Depending on whether this would get hit by any of our users, it may be
important. Probably not critical th
On Mon, Jul 23, 2007 at 10:06:03PM -0500, Bruce Dubbs wrote:
> Randy McMurchy wrote:
>
> The other, iproute2-2.6.22-070710, is something we need to discuss. The
> problem is with the packaging. The package expands to the current
> directory. The issue is what to do. Here is what I see as the o
- Original Message -
From: "Jeremy Huntwork" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Monday, July 23, 2007 8:51 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
>
> That's what bringing x86_64 into LFS would b
Jeremy Huntwork wrote:
> It does seem that there are still locations in /usr showing up in the
> search dirs. They are later in the list, but still, it seems the
> potential is there to pull in unwanted libs from the host.
Actually, they show up on x86 too so they're not the problem. The specif
Bruce Dubbs wrote these words on 07/23/07 22:06 CST:
> The other, iproute2-2.6.22-070710, is something we need to discuss. The
> problem is with the packaging. The package expands to the current
> directory. The issue is what to do. Here is what I see as the options:
>
> 1. Ignore the update
Randy McMurchy wrote:
> You are too sensitive.
Yes, you're probably right. :/
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Jeremy Huntwork wrote these words on 07/23/07 13:51 CST:
> And yet people blast me for what I'm doing? What gives?
You are too sensitive. I've not seen anyone "blast" you. I've
only seen people be critical of the ideas you have. That is okay.
This is a discussion forum where folks are expected to
Greg Schafer wrote:
> Greg Schafer wrote:
>
>> Preferably on an Ubuntu64 host, please post the verbose output
>> of gcc-pass2 so we can what is going on ie:
>>
>> echo 'main(){}' | gcc -xc -o /dev/null -v -
>
> Actually, that may not be enough. Would also need to see the output of:
>
> gcc -prin
Bruce Dubbs wrote:
> 1. Ignore the update for now.
> 2. Use our own repackaged version.
> 3. Add a note or other comments to to the iptables page
I'd opt for either 1 or 2. If we did number 3, I'm sure many people
would see the message after they've already unpacked it.
What's included in the
Randy McMurchy wrote:
> Besides, wouldn't your efforts be better spent getting LFS-6.3 out
> the door
Jeremy is getting a head start on a potential LFS-7.0.
I am about to cut a lfs-6.3-rc1. Right now there are two outstanding
tickets. One, man-pages-2.63, it pretty trivial and I'll make that
c
Randy McMurchy wrote:
> I ditto these sentiments. Jeez, Jeremy, why invent the wheel?
Actually, I was trying to avoid that. The simple fact is that I rarely
consult DIY. For reference, I looked at what I was already familiar
with: CLFS. I didn't even remember that DIY had a native x86_64 build
Greg Schafer wrote:
> Dude, it's fairly simple.
I'm not sure if you meant to sound condescending here; I'll give you the
benefit of the doubt and assume you didn't. It does appear, however,
that you missed the point of my request. I wasn't asking you to explain
to me your method; I get it. I w
Greg Schafer wrote these words on 07/23/07 20:44 CST:
> None of the CLFS gunk you're currently adding is needed. If
> you're going to borrow bits of CLFS stuff then IMHO you may as well just
> forget the whole thing and point folks to CLFS.
I ditto these sentiments. Jeez, Jeremy, why invent the wh
Jeremy Huntwork wrote:
> Greg, care to explain in more detail the {dis,}advantages of the
> symlinks a bit more?
Dude, it's fairly simple. The symlinks keep the `-disable-multilib' build
very much compatible with x86 ie: very little changes are required, and
this is a *MASSIVE* maintenance advan
Greg Schafer wrote:
> Umm, you appear to have missed the point completely. Please re-read the
> info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
> around the surprising (buggy?) GCC behavior I'm talking about.
I didn't miss the point, I understood all of what you wrote. I
Greg Schafer wrote:
> Preferably on an Ubuntu64 host, please post the verbose output
> of gcc-pass2 so we can what is going on ie:
>
> echo 'main(){}' | gcc -xc -o /dev/null -v -
Actually, that may not be enough. Would also need to see the output of:
gcc -print-search-dirs | sed 's/:/\n/g'
Reg
Jeremy Huntwork wrote:
> Thanks. This was just an oversight. I meant to include the contents of the
> pure64 patch for gcc pass2, but overlooked it due to the similarly named
> pure64_specs patch. Here's what the pure64 patch would give us (Approximately.
> The following is a faux diff due to line
On Mon, Jul 23, 2007 at 03:39:21PM -0600, Jeremy Huntwork wrote:
> On Mon, Jul 23, 2007 at 10:34:45PM +0100, Ken Moffat wrote:
> > The pure64 patch is usually thought to be needed in chapter 6 as
> > well as pass 2 ;)
>
> The problem I ran into is that the pure64 patch (at least the one I
> found
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote:
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_DIRNAMES = 64 32
> -MULTILIB_OSDIRNAMES = ../lib64 ../lib
> +MULTILIB_OSDIRNAMES = ../lib ../lib32
And, I suppose if I'm going to be adding this to the specs patch, it
would be safer to have
On Mon, Jul 23, 2007 at 10:34:45PM +0100, Ken Moffat wrote:
> The pure64 patch is usually thought to be needed in chapter 6 as
> well as pass 2 ;)
The problem I ran into is that the pure64 patch (at least the one I
found that's usable for gcc-4.1.1) won't apply once the specs patch has
been appli
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote:
>
> Since the specs patch is already set up for pure64 and modifies the 64-bit
> linker to be in /tools/lib, I'm thinking to merge these small changes above to
> the pure64_specs patch and call it done. Any objections to that?
>
Th
Greg Schafer zip.com.au> writes:
> It appears you haven't allowed for a surprising gotcha that means
> GCC-Pass2 will search for libs on the host thus rendering the build method
> ineffective. This (and the fix) is all documented in the DIY Refbuild.
Thanks. This was just an oversight. I meant to
Bryan Kadzban wrote:
> Right. (Actually I'm not sure you can access more than 1MB of memory
> even if you *do* pull your hair out. The memory model is 16-bit
> segments and 16-bit offsets, but the physical address mapping is "shift
> the segment number by 4 bits and add the offset" -- so the max
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Joe Ciccone wrote:
> Grub legacy sets up protected mode.
...Well never mind that then. Apparently the part of boot/setup.S in
the kernel that I was reading isn't actually executed. Figures. :-P
So it starts in protected mode, but (presumably)
- Original Message -
From: "Bryan Kadzban" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Saturday, July 21, 2007 2:49 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
> According to their site, it is maintained, just no n
Bryan Kadzban wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Luca wrote:
>
>> Grub-0.9x is old Grub legacy and no-more maintained.
>>
>
> According to their site, it is maintained, just no new features are
> being added. (Though I'm not sure what sense of the word "maint
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Luca wrote:
> Grub-0.9x is old Grub legacy and no-more maintained.
According to their site, it is maintained, just no new features are
being added. (Though I'm not sure what sense of the word "maintained"
they're using then... but whatever. Pre
- Original Message -
From: "Jeremy Huntwork" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Friday, July 20, 2007 10:54 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
> Indeed. I meant to drop something in, but forgot
Ken Moffat wrote:
>
>>
>>
> I'll give you java, so I have to accept there are binary 64-bit
> applications. But I can't find any 64-bit binaries for firefox or
> opera.
>
>
>
I could have sworn they existed but I just checked and couldn't find
them either. So strike two more off the list
On Fri, Jul 20, 2007 at 07:10:59PM -0400, Joe Ciccone wrote:
> Ken Moffat wrote:
> >
> > "all those nice 64 binary packages" - I suppose that means nvidia
> > or ati kernel modules ? I don't know of anything else that comes as
> > 64-bit without source.
> >
> >
> I know a few people use Opera
On 7/20/07, Joe Ciccone <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> >
> > The 1.9.x versions, too?
> >
> I'll have to check on the more recent versions. I know that 1.9.2 (the
> last time I tried) still needed a 32bit glibc. I don't have a pure64
> build around but I think the new one (1.9.
Jeremy Huntwork wrote:
> but I figured I'd show what I have and give someone else the opportunity
> to build it if they like and/or look for any obvious errors.
It appears you haven't allowed for a surprising gotcha that means
GCC-Pass2 will search for libs on the host thus rendering the build me
Ken Moffat wrote:
>
> "all those nice 64 binary packages" - I suppose that means nvidia
> or ati kernel modules ? I don't know of anything else that comes as
> 64-bit without source.
>
>
I know a few people use Opera too. I personally use a binary JDK if I
need java. If someone wanted to use
Dan Nicholson wrote:
> On 7/20/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote:
>>
>>> Here's the rendered book:
>>> http://linuxfromscratch.org/~jhuntwork/lfs-x86_64
>>>
>>>
>> You have correctly dropped grub from the l
On Fri, Jul 20, 2007 at 02:06:00PM -0700, Dan Nicholson wrote:
> On 7/20/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote:
> > >
> > > Here's the rendered book:
> > > http://linuxfromscratch.org/~jhuntwork/lfs-x86_64
> > >
> > You have c
El Viernes, 20 de Julio de 2007 22:54, Jeremy Huntwork escribió:
> Indeed. I meant to drop something in, but forgot about it. bin86/lilo
> would probably be alright. Anyone tried grub2?
IMHO, for now lilo should be used due that the build commands could be copied
from CLFS.
For the future, see
On 7/20/07, Ken Moffat <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote:
> >
> > Here's the rendered book:
> > http://linuxfromscratch.org/~jhuntwork/lfs-x86_64
> >
> You have correctly dropped grub from the list of packages (nobody
> has managed to buil
On Fri, Jul 20, 2007 at 10:47:16PM +0200, M.Canales.es wrote:
> Depends on how the changes are applied in the branch.
>
> If the branch will contains only x86_64 pure64 libs commands for now (i.e.
> replacing the needed x86 trunk commands by the ones for pure64), current
> jhalfs should work fin
On Fri, Jul 20, 2007 at 09:51:48PM +0100, Ken Moffat wrote:
> A slightly bigger problem might be that you don't seem to have a
> replacement for it.
Indeed. I meant to drop something in, but forgot about it. bin86/lilo
would probably be alright. Anyone tried grub2?
--
JH
--
http://linuxfromscra
On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote:
>
> Here's the rendered book:
> http://linuxfromscratch.org/~jhuntwork/lfs-x86_64
>
You have correctly dropped grub from the list of packages (nobody
has managed to build it successfully on a pure64 system), but it's
still referenc
El Viernes, 20 de Julio de 2007 22:29, George Boudreau escribió:
> Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months?
> I assume there will be a multi-lib version after all objections/ideas
> have been aired. (planning ahead for jhalfs)
Depends on how the changes are applied
Jeremy Huntwork wrote:
> On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote:
>> Thanks for the info. I think just to get started on handling multiple
>> arches in LFS, we should focus on non-multilib 64 and just symlink
>> /lib -> /lib64. Hopefully it doesn't bite elsewhere, but I think
On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote:
> Thanks for the info. I think just to get started on handling multiple
> arches in LFS, we should focus on non-multilib 64 and just symlink
> /lib -> /lib64. Hopefully it doesn't bite elsewhere, but I think it's
> the fastest way to ge
On 7/20/07, Joe Ciccone <[EMAIL PROTECTED]> wrote:
> Jeremy Huntwork wrote:
> > On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote:
> >
> >> LFS could be made to accommodate x86_64 (multilib) with very few changes
> >> and a bunch of new pages. Where multilib gets tricky is where lfs stops
On Fri, Jul 20, 2007 at 12:45:37PM -0400, Joe Ciccone wrote:
> There is even a bigger problem with non-multilib builds. The way clfs
> does it, all the 64bit libs go into /lib and such. FHS specifies ld.so
> for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in
> /lib, all those
Jeremy Huntwork wrote:
> On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote:
>
>> LFS could be made to accommodate x86_64 (multilib) with very few changes
>> and a bunch of new pages. Where multilib gets tricky is where lfs stops
>> and blfs begins. With the introduction of pkg-config
On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote:
> LFS could be made to accommodate x86_64 (multilib) with very few changes
> and a bunch of new pages. Where multilib gets tricky is where lfs stops
> and blfs begins. With the introduction of pkg-config and all those fun
> *-config pr
Gerard Beekmans wrote:
>
> A few people have already expressed the fact that platforms like x86_64
> are becoming more and more standard. We simply have to keep up with the
> times. Adopting some/all of CLFS' methods into mainstream LFS will
> happen sooner or later.
>
> Back in the day, LFS' chapt
On Tue, 17 Jul 2007 17:36:40 -0600, Gerard Beekmans wrote:
> Or it will end up in an LFS Hint. Or we'll defer completely to CLFS.
Long live pureLFS!
When I was first introduced to CLFS it was indicated that some people
indeed anticipated that, eventually, the cross method would become The
Book
On Tue, Jul 17, 2007 at 05:36:40PM -0600, Gerard Beekmans wrote:
>
> But first are summer holidays. I imagine lots of us will be gone (myself
> included starting end of next week) so this probably isn't the right
> time to start an in-depth discussion with people not paying attention
> anymore or
I agree with those statements, Craig.
Every now and then the old past still rears its ugly head. A few things
happened that hurt a number of people (professional and personal pride)
and those things are typically hard to get over.
I, too, have always thought it to be a good idea to merge CLFS wit
> > That said, for (B)LFS devs who weren't envited to join CLFS, they will
> > never be able to, if what I've been told is true. Recently, I've
> > been away from the project, some of it due to the fact that I'm using
> > 64 bit arch's and my work on these platforms is now of no value to
> > BLFS,
Randy McMurchy wrote:
> This should not spark a flame war, you make a very concise and to the
> point statement/question that deserves discussion. However, the CLFS
> fork was mostly due to some dev's dissatisfaction with the decisions
> that were made a *long* time ago. It's my belief there is sti
Craig Jackson wrote these words on 07/13/07 18:02 CST:
> I don't know how to say this
> delicately, so I will just say it.
And being one that appreciates such candor, I applaud your message.
> It seems futile for me to attempt
> to test for LFS for the simple fact that the x86 architecture's da
55 matches
Mail list logo
