Armin K. wrote:
> On 12/11/2013 11:33 PM, Matt Burgess wrote:
>> Hi all,
>>
>> Those of you who follow lfs-book will have seen some commits fly by from
>> Armin, who asked to be granted access to work on the systemd branch. As
>> I've been lacking time recently, and lost a bit of motivation for
>>
>> Now I need to build binutils and make sure that it sees the correct
>> toolchain -
>
> You have it backwards. Binutils, then gcc, then glibc. Not glibc,
> then binutils.
>
> What exactly are you going after.
It's an experiment. I wondered whether one could build the four core packages
in the
On 12/11/2013 11:33 PM, Matt Burgess wrote:
> Hi all,
>
> Those of you who follow lfs-book will have seen some commits fly by from
> Armin, who asked to be granted access to work on the systemd branch. As
> I've been lacking time recently, and lost a bit of motivation for
> maintaining the branch
Hi all,
Those of you who follow lfs-book will have seen some commits fly by from
Armin, who asked to be granted access to work on the systemd branch. As
I've been lacking time recently, and lost a bit of motivation for
maintaining the branch myself, I was happy to accept the offer of help.
Welco
On Wed, 2013-12-11 at 15:30 -0600, Bruce Dubbs wrote:
> Is it useful to update using all of this? The last four elements are
> not strictly needed for LFS. We could approach this in other ways
> though. We could create a custom Makefile or a patch for everything.
>
> What do you think?
Nice
Slowly and surely, the programs in sysvinit are being duplicated by
other packages. The latest is pidof is now in procps-ng. Playing
around with sysvinit, I came up with a set of seds:
# In the book for some time to clarify a message
sed -i 's@Sending processes@& configured via /etc/inittab@g'
On Dec 10, 2013, at 12:00 PM, John Burrell wrote:
> Now I need to build binutils and make sure that it sees the correct
> toolchain -
You have it backwards. Binutils, then gcc, then glibc. Not glibc,
then binutils.
What exactly are you going after.
If you are after building a kernel only
.
> As how to automate the setting of rpath under gcc, I guess you can with
> the specs, but I have never done it.
these lines in the specs file:
*link_libgcc:
%D
can be changed to:
*link_libgcc:
%D -rpath /lib/%M
Apparently %M expands to either ../lib or ../lib64 depending on 32 or 64 bit
ar
Le 10/12/2013 23:38, John Burrell a écrit :
> .
>> I do not quite understand what you have done. Your first build was linux
>> headers then glibc? Without doing anything with gcc?
> Well I'm building the archive files using a machine running LFS so gcc is
> version 4.8.2
>
>> If so, you cannot exp
