Hello all,
Since a couple of weeks I am trying to use the LFS project to start
building my own base system. I grew tiered of modifying existing
distributions.
So far so good, but as is mentioned many times over the Internet by
others, compiling glibc-2.17 (or .16) runs into the gperf obstacle.
On 02/22/2013 06:55 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Hello all,
>>
>> Since a couple of weeks I am trying to use the LFS project to start
>> building my own base system. I grew tiered of modifying existing
>> distributions.
>>
>> So far
On 02/22/2013 11:12 PM, Ken Moffat wrote:
> On Fri, Feb 22, 2013 at 10:50:01PM +0100, Frans de Boer wrote:
>> On 02/22/2013 06:55 PM, Bruce Dubbs wrote:
>>>
>>> If you follow the book, gperf is not required. Lately texinfo-5.0
>>> breaks the build for gcc, b
On 02/22/2013 11:21 PM, Tobias Gasser wrote:
> Am 22.02.2013 22:50, schrieb Frans de Boer:
>> I understand that gperf is not required - it would be mentioned
>> otherwise does it?
>
> yes. gperf is NOT required for glibc (or any other package in lfs)
> and yes, all req
On 02/23/2013 06:03 AM, William Harrington wrote:
>
> On Feb 22, 2013, at 8:44 PM, William Harrington wrote:
>
>> And texinfo for when changing any of that related portion. GCC will
>> use it when modifying gperf input files to regenerate associated
>> header files. So may GNU C Library will use it
Dear all,
Below is the output I get when I try to compile grep, with similar
result in gzip. Before, I solved it by substituting all occurrences of
1.12a into 1.12 or 1.13.1. The compile then went on without problem.
I wonder why there is nothing in the book about it. I encounter this
problem
On 02/24/2013 06:02 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Dear all,
>>
>> Below is the output I get when I try to compile grep, with similar
>> result in gzip. Before, I solved it by substituting all occurrences of
>> 1.12a into 1.12 or 1.13.1. The com
On 02/24/2013 07:45 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>
>
>> The contents of the lfs .bashrc is:
>>
>> set +h; umask 022
>> LFS=/mnt/lfs
>> LC_ALL=POSIX
>> LFS_TGT=$(uname -m)-lfs-linux-gnu
>> PATH=/tools/bin:/bin:/usr/bin
>> exp
On 02/25/2013 12:18 AM, Bruce Dubbs wrote:
Frans de Boer wrote:
On 02/24/2013 07:45 PM, Bruce Dubbs wrote:
Frans de Boer wrote:
The contents of the lfs .bashrc is:
set +h; umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL
On 02/25/2013 06:30 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>
>> Attached are two files as requested. In order to capture the warnings
>> too, I placed the 2>&1 operator at the end like make > grep-make.log
>> 2>&1, you would otherwise only get the st
Dear all,
The book allows creation if 32-bit systems as well as 64-bit. However,
on 64-bit systems the library directory is still called /usr/lib pointed
to from the symlink /usr/lib64.
I case I want a system which can handle mainly 64-bit programs and on
occasion a 32-bit program, I need the
On 02/27/2013 07:29 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Dear all,
>>
>> The book allows creation if 32-bit systems as well as 64-bit. However,
>> on 64-bit systems the library directory is still called /usr/lib pointed
>> to from the symlink /usr/li
On 02/27/2013 08:04 PM, Armin K. wrote:
> On 02/27/2013 07:24 PM, Frans de Boer wrote:
>> Dear all,
>>
>> The book allows creation if 32-bit systems as well as 64-bit. However,
>> on 64-bit systems the library directory is still called /usr/lib pointed
>> to fro
On 02/28/2013 07:51 AM, Simon Geard wrote:
> On Wed, 2013-02-27 at 22:45 +0100, Frans de Boer wrote:
>> By the way, I looked at the CLFS site and see that things are not that
>> different only that they are a couple of versions behind. That said, I
>> think I will try som
On 03/06/2013 12:38 AM, Nicholas McCurdy-Luksch wrote:
> I had the same problem with 7.2... I never found a satisfactory cause, but
> my solution was to re-run the script (after a few minutes of looking around
> for the source of the problem and doing nothing in the process)... it
> completed
...of changed/new files on http only sites like sourceforge.net?
Keeping track of changed and new files on FTP sites is relative easy.
However, HTTP sites is differently and made complicated because no page
is the same and directory listings are not easy. In fact, I do not
remember anymore how
On 10/20/2013 04:43 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> ...of changed/new files on http only sites like sourceforge.net?
>>
>> Keeping track of changed and new files on FTP sites is relative easy.
>> However, HTTP sites is differently and made complicate
I noticed that the debian site can't be reached anymore and therefore
the newest shadow tar can't be reached - if any.
Does anybody knows where the latest shadow tar's can be found - beside
the LFS site.
Regards, Frans.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://ww
On 12/06/2013 08:43 PM, Bruce Dubbs wrote:
> frozen tuesday wrote:
>>> root:/sources/glibc-build# grep Error glibc-check-log
>>> make[2]: *** [/sources/glibc-build/math/
>> test-float.out] Error 1
>>> make[2]: *** [/sources/glibc-build/math/test-ldouble.out] Error 1
>>> make[2]: *** [/sources/glibc
On 12/07/2013 10:57 PM, William Harrington wrote:
>
> On Dec 5, 2013, at 2:43 PM, frozen tuesday wrote:
>
>> make[2]: *** [/sources/glibc-build/math/test-float.out] Error 1
>> make[2]: *** [/sources/glibc-build/math/test-ldouble.out] Error 1
>> make[2]: *** [/sources/glibc-build/math/test-ifloat.ou
On 12/08/2013 01:08 AM, Frans de Boer wrote:
> On 12/07/2013 10:57 PM, William Harrington wrote:
>>
>> On Dec 5, 2013, at 2:43 PM, frozen tuesday wrote:
>>
>>> make[2]: *** [/sources/glibc-build/math/test-float.out] Error 1
>>> make[2]: *** [/sources/gli
Dear all,
There was another thread in this form which did not yield the desired
result. So, maybe I can revive it.
Below is the output listing from the test in 6.9.1:
make[1]: Target 'check' not remade because of errors.
make[1]: Leaving directory '/sources/glibc-2.18'
Makefile:9: recipe for ta
On 12/17/2013 05:55 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Dear all,
>>
>> There was another thread in this form which did not yield the desired
>> result. So, maybe I can revive it.
>>
>> Below is the output listing from the test in 6.9.1:
&
On 12/18/2013 02:50 AM, William Harrington wrote:
>
> On Dec 17, 2013, at 10:55 AM, Bruce Dubbs wrote:
>
>>> make[2]: *** [/sources/glibc-2.18/build/nptl/tst-pthread-getattr.out]
>
> FOr this one and some others, you may want to look at the values of
> the command:
>
> ulimit -a
>
> If the .out fil
On 12/18/2013 05:06 PM, William Harrington wrote:
>
> On Dec 18, 2013, at 4:07 AM, Frans de Boer wrote:
>
>> The output of ulimit -a is:
>> root:/sources/glibc-2.18# ulimit -a
>> core file size (blocks, -c) 0
>> data seg size (kbytes, -d)
On 12/19/2013 09:32 AM, Frans de Boer wrote:
> On 12/18/2013 05:06 PM, William Harrington wrote:
>>
>> On Dec 18, 2013, at 4:07 AM, Frans de Boer wrote:
>>
>>> The output of ulimit -a is:
>>> root:/sources/glibc-2.18# ulimit -a
>>> core fil
Dear reader,
While building things again, I now start to wonder why LFS let almost
every package installs a static library? Where are the static libraries
used?
After all, the down side of static libraries is that once linked into a
module/program, any upgrade is not incorporated. Potentially
On 12/31/2013 12:37 AM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>> Dear reader,
>>
>> While building things again, I now start to wonder why LFS let almost
>> every package installs a static library? Where are the static libraries
>> used?
>>
>> Af
Dear reader,
I am having problems lately making the tool chain on my x86_64 machine.
I finally traced it back to chapter 5.7, where glibc aborts with the
next messages:
...
echo soversions.mk-done = t;) <
/mnt/lfs/sources/glibc-2.17/build/soversions.i >
/mnt/lfs/sources/glibc-2.17/build/sov
On 01/11/2014 08:41 PM, Chris Staub wrote:
> On 01/11/14 14:38, Frans de Boer wrote:
>> Dear reader,
>>
>> I am having problems lately making the tool chain on my x86_64 machine.
>> I finally traced it back to chapter 5.7, where glibc aborts with the
>> n
Hm, I decided to restart all over - had to change scripts to follow the
book more strictly - but building binutils now ends with Error 2.
...
mv -f elf32-target.new elf32-target.h
rm -f elf64-target.h
sed -e s/NN/64/g < ../../binutils-2.24/bfd/elfxx-target.h > elf64-target.new
mv -f elf64-target.
On 01/11/2014 11:43 PM, Frans de Boer wrote:
> Hm, I decided to restart all over - had to change scripts to follow the
> book more strictly - but building binutils now ends with Error 2.
>
> ...
> mv -f elf32-target.new elf32-target.h
> rm -f elf64-target.h
> sed -e s/NN/64/g
Dear reader,
I do not know where else to post the next:
One of my (server)systems is an i686 with 640MB. During checking I
always get "FAIL: gas/i386/rept". I noticed that when running without
any services, this error did not appear. So after some searching I found
a file which cause this erro
On 01/19/2014 11:11 PM, Frans de Boer wrote:
> Dear reader,
>
> I do not know where else to post the next:
>
> One of my (server)systems is an i686 with 640MB. During checking I
> always get "FAIL: gas/i386/rept". I noticed that when running without
> any services
The next messages are produced every single time I encounter this chapter:
Running /sources/binutils-2.24/ld/testsuite/ld-elf/binutils.exp ...
Running /sources/binutils-2.24/ld/testsuite/ld-elf/comm-data.exp ...
Running /sources/binutils-2.24/ld/testsuite/ld-elf/compress.exp ...
Running /sources/b
On 01/28/2014 08:37 PM, Ken Moffat wrote:
> On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote:
>> Frans de Boer wrote:
>>> FAIL: static preinit array
>>> FAIL: static init array
>>> FAIL: static fini array
>>> FAIL: static init array mixed
On 01/28/2014 09:09 PM, Frans de Boer wrote:
> On 01/28/2014 08:37 PM, Ken Moffat wrote:
>> On Tue, Jan 28, 2014 at 07:27:58PM +0200, Markku Pesonen wrote:
>>> Frans de Boer wrote:
>>>> FAIL: static preinit array
>>>> FAIL: static init array
>>&
Great, glibc 2.19 is working fine.
Also, the first two 'sed' lines - static and make - can be removed
because those issues are resolved in the new version. I did not created
any other change. Maybe have a look at the locales for the bss chain.
ef2progs - due to the introduction of using a build
During testing I get "col: Invalid or incomplete multibyte or wide
character" as output for the man-6 test. I found references which date
back to 2009 with the same errors, but no solution is found.
So, I doubt I'll be the first to notice this.
Any suggestions?
Regards, Frans.
--
http://linuxf
On 02/13/2014 05:29 PM, Armin K. wrote:
> On 02/13/2014 04:42 PM, Frans de Boer wrote:
>> During testing I get "col: Invalid or incomplete multibyte or wide
>> character" as output for the man-6 test. I found references which date
>> back to 2009 with the same e
During a BSS rebuild I found that automake generates two errors which
stop the auto build.
It is introduced by flex-2.5.38, I tried the same with flex-2.5.37 with
no errors.
I added the next line to the build script for automake because I can't
find the cause. All errors complain about a missi
On 02/15/2014 01:38 AM, Armin K. wrote:
> On 02/15/2014 01:29 AM, Frans de Boer wrote:
>> During a BSS rebuild I found that automake generates two errors which
>> stop the auto build.
>>
>> It is introduced by flex-2.5.38, I tried the same with flex-2.5.37 with
>>
On 02/15/2014 10:48 AM, Frans de Boer wrote:
> On 02/15/2014 01:38 AM, Armin K. wrote:
>> On 02/15/2014 01:29 AM, Frans de Boer wrote:
>>> During a BSS rebuild I found that automake generates two errors which
>>> stop the auto build.
>>>
>>> It is int
On 02/13/2014 09:40 PM, Ken Moffat wrote:
> On Thu, Feb 13, 2014 at 06:08:46PM +0100, Frans de Boer wrote:
>> On 02/13/2014 05:29 PM, Armin K. wrote:
>>> On 02/13/2014 04:42 PM, Frans de Boer wrote:
>>>> During testing I get "col: Invalid or incomplete multibyt
Dear All,
It looks like most Linux distributions are switching to systemd from
sysvinit. As Bruce is even one of the (co-?)authors of systemd, the
knowledge is already in the house. Why would (x)LFS stick to sysvinit
while the rest of the world is moving to systemd?
Of course, simplicity might
On 02/16/2014 01:52 PM, Armin K. wrote:
> On 16.2.2014 12:59, Frans de Boer wrote:
>> Dear All,
>>
>> It looks like most Linux distributions are switching to systemd from
>> sysvinit. As Bruce is even one of the (co-?)authors of systemd, the
>> knowledge is alrea
On 02/16/2014 02:55 PM, akhiezer wrote:
>> Date: Sun, 16 Feb 2014 12:59:19 +0100
>> From: Frans de Boer
>> To: lfs-support@linuxfromscratch.org
>> Subject: [lfs-support] systemd versus sysvinit
>>
>> Dear All,
>>
>> It looks like most Linux distrib
On 02/16/2014 12:59 PM, Frans de Boer wrote:
> Dear All,
>
> It looks like most Linux distributions are switching to systemd from
> sysvinit. As Bruce is even one of the (co-?)authors of systemd, the
> knowledge is already in the house. Why would (x)LFS stick to sysvinit
> whi
From last week until yesterday - Wednesday - there where several
updates like linux-3.13.5, grep-2.17 and 18, psmisc-22.21, bash-4.3 and
readline-6.3 and of course systemd-209.
In todays online documentation update, all mentioned packages are not
included. It tried to compile all (except the n
On 02/27/2014 04:49 PM, Bruce Dubbs wrote:
> Frans de Boer wrote:
>>From last week until yesterday - Wednesday - there where several
>> updates like linux-3.13.5, grep-2.17 and 18, psmisc-22.21, bash-4.3 and
>> readline-6.3 and of course systemd-209.
>>
>> In t
I could not compile 4.9.0 since it always fails when staring to
configure for 'libvtv' as showed next:
...
make[3]: Leaving directory
`/mnt/lfs/sources-tc/gcc-build/x86_64-bld-linux-gnu/libgcc'
make[2]: Leaving directory
`/mnt/lfs/sources-tc/gcc-build/x86_64-bld-linux-gnu/libgcc'
Checking multi
On 04/24/2014 02:51 AM, Ken Moffat wrote:
> On Thu, Apr 24, 2014 at 12:23:28AM +0200, Frans de Boer wrote:
>> I could not compile 4.9.0 since it always fails when staring to
>> configure for 'libvtv' as showed next:
>>
> [snip]
>>
&g
Ok, followed the advises from ticket #3552, now binutils chapter 6
reports failures:
Running /sources-bss/binutils-2.24/ld/testsuite/ld-plugin/lto.exp ...
FAIL: PR ld/12758
FAIL: PR ld/12760
FAIL: LTO 3 symbol
FAIL: PR ld/13183
FAIL: LTO 3a
FAIL: LTO 11
Running /sources-bss/binutils-2.24/ld/tests
On 04/24/2014 09:38 PM, Bruce Dubbs wrote:
> Pierre Labastie wrote:
>> Le 24/04/2014 17:28, Frans de Boer a écrit :
>>> Ok, followed the advises from ticket #3552, now binutils chapter 6
>>> reports failures:
>>>
>>> Running /sources-bss/binutils-2.2
54 matches
Mail list logo
