Jeremy Huntwork wrote:
> But if that's the case, headers_check re-runs everything you
> just did in 'headers_install', which makes the 'headers_install' kind of
> pointless. To me, it seems more like 'headers_check' is an extension of
> 'headers_install', adding an extra step of verification.
Greg Schafer wrote:
FFS, this whole new way of obtaining sanitized headers has become known as
the "make headers_install" method and you've gone and removed that very
command! Not very educational IMHO. Hope it's clearer now.
Alright, I can see where you're coming from. So ideally, to make use
Jeremy Huntwork wrote:
> Have you actually studied the Makefile contents? The results of the
> current commands would be the same as if you ran (which, btw, would also
> avoid the problem with removing /tools/include):
>
> make mrproper
> make headers_check
> make headers_install
> cp -av usr/
Greg Schafer wrote:
Ummm, you completely missed the point. The /tmp removal stuff is fine. The
removal of `make headers_install' is what's questionable.
Have you actually studied the Makefile contents? The results of the
current commands would be the same as if you ran (which, btw, would also
Jeremy Huntwork wrote:
> This has nothing to do with the way other packages work. This is *only*
> applicable with this particular package and its Makefile. Why make a
> temporary directory outside the build tree, install it there first, and
> then manually move it to its final location when it
Greg Schafer wrote:
Jeremy Huntwork wrote:
This is because the target 'headers_check' includes 'headers_install' as
a dependency, and therefore runs that first:
You're obfuscating here for no good reason. In fact, your logic is flawed.
Taking your view to extremes, why even specify "make" when
Jeremy Huntwork wrote:
> Actually, after looking through the Linux Makefile a bit, I think our
> commands for chapter 5 linux-headers can be simplified to the following:
>
> patch -Np1 -i ../linux-2.6.18.1-unifdef-1.patch
> make mrproper
> make headers_check
> cp -Rv usr/include/* /tools/include
Bruce Dubbs wrote:
Can't keep away, eh?
Yeah, it's a sickness. There should be a LFS rehab center somewhere...
Any help is appreciated. You are good to go.
Thanks, looks like it works.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Bruce Dubbs wrote:
Jeremy Huntwork wrote:
Hey All,
Would anyone mind if I helped out a bit with the development here again?
If not, I would require svn access. If so, well, fair enough. :)
Can't keep away, eh?
Any help is appreciated. You are good to go.
-- Bruce
It's good to see you b
Jeremy Huntwork wrote:
> Hey All,
>
> Would anyone mind if I helped out a bit with the development here again?
> If not, I would require svn access. If so, well, fair enough. :)
Can't keep away, eh?
Any help is appreciated. You are good to go.
-- Bruce
--
http://linuxfromscratch.org/mailman
Alexander E. Patrakov wrote:
> Stef Bon wrote:
>> What do you think about unionfs?
>> The existing situation works, but this new construction looks good.
>>
>
> Unionfs was used with LFS-6.1 LiveCDs. It has been dropped then, for a
> reason: too buggy, especially on SMP. Try running "make chec
Stef Bon escribió:
> Hello all,
>
> well I've posted a howto on howtoforge with something about LFS:
>
> http://www.howtoforge.com/ihlfs_full_control_over_what_youre_installing
>
> It's about the control you can get over a installation (or everything that
> does modifications on your system) wit
Hey All,
Would anyone mind if I helped out a bit with the development here again?
If not, I would require svn access. If so, well, fair enough. :)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Stef Bon escribió:
> Alexander E. Patrakov wrote:
>
>> Stef Bon wrote:
>>> What do you think about unionfs?
>>> The existing situation works, but this new construction looks good.
>>>
>> Unionfs was used with LFS-6.1 LiveCDs. It has been dropped then, for a
>> reason: too buggy, especially on S
Stef Bon wrote:
>> /tools is also used instead of /usr to _separate_ the temporary
>> tools built in the ch.5 from the resulting ones built in the ch.6.
>
>
> Ok is this nesassary? It has to be seperate? I do not understand why.
Way back in version 3.something of the book (I think anyway), there
Alexander E. Patrakov wrote:
> Stef Bon wrote:
>> What do you think about unionfs?
>> The existing situation works, but this new construction looks good.
>>
>
> Unionfs was used with LFS-6.1 LiveCDs. It has been dropped then, for a
> reason: too buggy, especially on SMP. Try running "make chec
Stef Bon wrote:
What do you think about unionfs?
The existing situation works, but this new construction looks good.
Unionfs was used with LFS-6.1 LiveCDs. It has been dropped then, for a
reason: too buggy, especially on SMP. Try running "make check" for glibc
on unionfs. Or (for stress te
Vladimir A. Pavlov wrote:
> Hi, Stef!
>
> The idea is really great but I think there are several problems with
> it :(
>
> AFAIK UnionFS isn't in the mainline kernel at the time and we cannot
> force people to download, build and modprobe a third-party kernel
> module.
>
> Many people believe i
Vladimir A. Pavlov wrote:
> Hi, Stef!
>
> The idea is really great but I think there are several problems with
> it :(
>
> AFAIK UnionFS isn't in the mainline kernel at the time and we cannot
> force people to download, build and modprobe a third-party kernel
> module.
>
> Many people believe i
19 matches
Mail list logo
