Hello,
I have subscribed this list recently, so let me introduce myself:
My name is Pierre Labastie. I have been practicing linux system building
as a hobby for quite a while: I think my first attempts (with Linux From
Scratch) were undertaken in 2003. Time passing, I switched to DIY linux
Le 28/12/2011 13:27, Matt Burgess a écrit :
On Wed, 2011-12-28 at 13:09 +0100, Pierre Labastie wrote:
So, `version-check.sh' outputs (among other things...):
version-check.sh: line 22: /lib/libc.so.6: No such file or directory
Actually, current jhalfs does not find it either.
Current jhalfs
Le 29/12/2011 22:53, Matt Burgess a écrit :
On Thu, 2011-12-29 at 13:39 -0800, Bryan Kadzban wrote:
ldd /bin/ls | awk '/libc\.so/ {print $3;}'
That's really neat. Works on a Fedora 64-bit host and an up to date
lfs-trunk build as well. I'll add it to the book in a few days in case
someone
, 2011-12-28 at 15:01 +0100, Pierre Labastie wrote:
I meant `current trunk' too. The change in version 3537 is not enough.
Here is what I have done (not checked on any other system than Debian,
but I do not see a reason why it would not work):
# if [ -f /lib/libc.so.6 ]; then
#libcLoc
Le 30/12/2011 08:46, Alex a écrit :
I tried using it myself and saw odd behavior when using sysroot with a
native gcc. The library search path ended up being /SYSROOT/ABSOLUTE/lib/
instead of /SYSROOT/lib when the 'lib' directory was located at
/ABSOLUTE/lib. I added a 'hack' symlink
Le 06/01/2012 04:49, Jeremy Huntwork wrote:
I'm sure whatever you choose to do is perfectly fine for your needs, but
objecting to parameter substitution as being more complicated than piping to
head and then cut is silly. It's simple pattern substitution like you do with
sed in the rest of
Hi,
In the book sources retrieved from the subversion repository,
there is a Makefile, which has non POSIX constructs, e.g.:
$(Q)rm -f $(RENDERTMP)/lfs-{full,html,pdf}.xml # no {} in POSIX
or
$(Q)if [ x$(MAKETAR) == x ]; then # no == in POSIX. use
simple '='
Le 07/01/2012 18:47, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Would it be possible to add SHELL = /bin/bash in the
header of the Makefile ? (same in BLFS and HLFS). the git
CLFS Makefile has the line SHELL=/bin/bash
I did that for LFS/BLFS. I don't make changes to HLFS.
-- Bruce
Le 15/01/2012 13:48, Matt Burgess a écrit :
The rules to create persistent network interface and cdrom link
rules automatically in /etc/udev/rules.d/ have been disabled by
default. Explicit configuration will be required for these use
cases, udev will no longer try to write any persistent
Hi,
Regarding the posix/bug-regex32error in glibc tests, I found
http://sourceware.org/bugzilla/show_bug.cgi?id=13118
Maintainer says he has applied the patch, but I checked that Glibc-2.14.1
tarball still lacks the correction.
Not sure it is worth considering including the patch (or adding a
Hi,
As the subject heading says, it looks like kmod.xml is missing in rev 9712,
while chapter06/chapter06.xml has been modified to xinclude it.
Regards,
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
Hi,
In packages.ent, the line:
!ENTITY udev-url kernel;linux/utils/kernel/udev-udev-version;.tar.xz
should be:
!ENTITY udev-url
kernel;linux/utils/kernel/hotplug/udev-udev-version;.tar.xz
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Hi,
I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
lately.
ICA is broken because of the part in glibc's instructions, which
instructs 'test-installation.pl' to look for /usr/lib rather than
/tools/lib. On the second (and following) pass, the line 'DL=...' sets
DL to empty
Hi,
I think I spotted something by doing ICA (not all investigated yet).
ld.so.cache differs at the end of pass 1 and at the end of pass 2.
It can be printed with ldconfig -p, and then diffed, which gives:
--- ld.so.cache-1 2012-01-27 19:19:13.0 +0100
+++ ld.so.cache-2
Le 27/01/2012 19:46, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Hi,
I think I spotted something by doing ICA (not all investigated yet).
ld.so.cache differs at the end of pass 1 and at the end of pass 2.
It can be printed with ldconfig -p, and then diffed, which gives:
Now, one
Le 28/01/2012 00:01, Matt Burgess a écrit :
OK, so running ldconfig just after pass2 should fix things up then, do
you think?
Oh, I should not have used pass 1, 2: I meant the ICA passes.
Let us call them 'build'.
Running ldconfig at the end of build 1 (Section 6.64 - Cleaning Up,
for
Hi,
Maybe another thing to worry about:
--
--- iteration-1/usr/lib/libgmpxx.la
+++ iteration-2/usr/lib/libgmpxx.la
@@ -17,7 +17,7 @@
inherited_linker_flags=''
# Libraries that this one depends upon.
-dependency_libs=' /usr/lib/libgmp.la'
Le 28/01/2012 00:30, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Well, the reason why grub does not find liblzma is much simpler
anyway: grub is built before xz!
It should find xz from Chapter 5. The liblzma.so.5.0.3 is in /tools and
it does have the lzma_code reference.
There are a few
Le 28/01/2012 12:34, Matt Burgess a écrit :
On Thu, 2012-01-26 at 19:15 -0500, Thomas Pegg wrote:
I noticed the patch too but haven't had time to thoroughly review it
yet. But I would say before it does get applied a new stable release of
jhalfs as there have been a few fixes since the last
Le 03/02/2012 06:04, Bryan Kadzban a écrit :
But this is it:
# ignore KVM virtual interfaces
ENV{MATCHADDR}==52:54:00:*, GOTO=persistent_net_generator_end
(From /lib/udev/rules.d/75-persistent-net-generator.rules.)
It might not work on real hardware machines under Fedora 16:
Because they
Hi,
I already reported that ICA iteration 1 and 2 did not
have the same libgmpxx.so.4.2.3. I have investigated
a little more.
Maybe I should recall what ICA is:
-First build as per chapter 6 instructions.
-Remove /tools, copy the / hierarchy into some directory, say iteration1
-then start again
Le 04/02/2012 21:30, Pierre Labastie a écrit :
maybe link libstdc++ to this directory, something like:
ln -s /tools/lib/libstdc++.a `dirname $(gcc
--print-libgcc-file-name)`/libstdc++.a
could be added to the readjusting instructions. After doing that,
gmp's configure finds that 'g++ -static
Le 04/02/2012 22:33, Bryan Kadzban a écrit :
Bah, right. Well, there's a C++ compiler *somewhere*, that the pass2
gcc is using to compile libstdc++ when it runs into this error. :-)
Maybe it'd be a better idea to do it that way: Run a build until it
breaks, then repeat the command that
Le 05/02/2012 12:36, Pierre Labastie a écrit :
Le 04/02/2012 22:33, Bryan Kadzban a écrit :
Bah, right. Well, there's a C++ compiler *somewhere*, that the pass2
gcc is using to compile libstdc++ when it runs into this error. :-)
Maybe it'd be a better idea to do it that way: Run a build
Le 05/02/2012 16:44, Andrew Benton a écrit :
On Sun, 05 Feb 2012 12:46:24 +0100
Pierre Labastiepierre.labas...@neuf.fr wrote:
Maybe try (supposing the build tree has not been removed):
echo '#includecstdio' |/mnt/lfs/sources/gcc-build/gcc/xgcc -shared-libgcc
\
Le 05/02/2012 18:02, Andrew Benton a écrit :
On Sat, 04 Feb 2012 23:00:37 +0100
Pierre Labastiepierre.labas...@neuf.fr wrote:
Looks like the libstdc++.a built during chapter 5 cannot be used...
Some missing -fPIC during build of libstdc++?
(-fPIC is indeed used for C++ bindings during the
Le 06/02/2012 00:32, Andrew Benton a écrit :
On Sun, 05 Feb 2012 23:01:30 +0100
Pierre Labastiepierre.labas...@neuf.fr wrote:
If I understand the xxx.la files, they are used by libtool to find
libraries. I am certainly missing something, but I do not understand
why changing tools to usr in
Le 05/02/2012 20:16, Bruce Dubbs a écrit :
We are starting to plan for LFS-7.1. We are anticipating an -rc1
release in about two weeks and lfs-7.1 around the first of March.
Right now there are only two relatively routine package updates in the
ticket queue: the kernel and automake.
Le 05/02/2012 20:16, Bruce Dubbs a écrit :
We are starting to plan for LFS-7.1. We are anticipating an -rc1
release in about two weeks and lfs-7.1 around the first of March.
Right now there are only two relatively routine package updates in the
ticket queue: the kernel and automake.
Le 05/02/2012 20:16, Bruce Dubbs a écrit :
We are starting to plan for LFS-7.1. We are anticipating an -rc1
release in about two weeks and lfs-7.1 around the first of March.
Right now there are only two relatively routine package updates in the
ticket queue: the kernel and automake.
Le 17/02/2012 23:08, Thomas Pegg a écrit :
After looking at this all that is needed is to add the following line
to common/libs/func_book_parser right after we check out the sources.
cd ${PROGNAME}-$LFSVRS; bash process-scripts.sh $LOGDIR/$LOG 21 ; cd ..
This quells all those messages.
Le 17/02/2012 23:19, Bruce Dubbs a écrit :
Pierre Labastie wrote:
jhalfs needs an xml file to process for extracting commands scripts.
'index.xml' in book sources is the most obvious choice. But using this file
leads necessary to try to find the '.script' entities, which have been
deleted
Le 18/02/2012 00:49, Matt Burgess a écrit :
I'm not sure your fix is right though. Being a pedant, the last 2
commands in the validxml target have nothing to do with validating the
XML; that is obviously achieved by the call to xmllint. Then again,
those last 2 commands are required in order
Le 20/02/2012 04:45, Bruce Dubbs a écrit :
The Linux From Scratch community is pleased to announce the release of
LFS Version 7.1-rc1. This is the first release candidate on the road to
LFS-7.1. This It is an incremental release with updates from LFS-7.0 to
20 packages as well as fixes to
Le 20/02/2012 11:27, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Le 20/02/2012 04:45, Bruce Dubbs a écrit :
The Linux From Scratch community is pleased to announce the release of
LFS Version 7.1-rc1. [...]
Hi,
Looks like since 7.0, the svn tags/${version} dir contains directly the
sources
Hi,
I have done a test of LFS-7.1-rc1. ICA went OK, except the
already reported problem with ld.so.cache (ldconfig still missing
somewhere), which is not a big issue. In case somebody else
does ICA, there is this difference in etip.h between ICA
iterations 1 and 2:
Le 21/02/2012 21:51, Andrew Benton a écrit :
On Tue, 21 Feb 2012 09:47:00 +0100
Pierre Labastiepierre.labas...@neuf.fr wrote:
Hi,
I have done a test of LFS-7.1-rc1. ICA went OK, except the
already reported problem with ld.so.cache (ldconfig still missing
somewhere), which is not a big
Hi,
I have read several times that some of you were using DESTDIR
and recording the installed files for being able to uninstall
packages. I recently realized that what I have called `package
management' in jhalfs could be used for that purpose:
basically it automates the generation of scriptlets
Le 23/02/2012 16:29, Thomas Pegg a écrit :
On Feb 23, 2012, at 8:30 AM, Pierre Labastie wrote:
I think this function could be used for recording the
installed files.
There is actually already functionality in jhalfs to do that already, Cant
remember which menu it's under but we can create
Hi,
I have seen several discussions about the new build method
proposed by Jeremy.;-)
For myself, I have no idea, although I like this method because
I tried to implement it myself (and not succeeded because I
took a wrong path).
One crucial point always with a novelty is does it work?
Of course
Le 03/03/2012 08:22, Qrux a écrit :
I spent a little time with jhalfs in 6.8. I had some trouble with the build
(I'm sure it was me, or an outdated host). It's very pretty, and I might try
a similar menuconfig-style-interface in my own stuff. Right now I just use
'read VAR' for my
Le 06/03/2012 20:03, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Actually the instructions in the book for wget have a
configure switch '--with-ssl=openssl', while openssl
is optional. Furthermore, the command explanations
say that this switch may be omitted if https is not
needed, which
Le 09/03/2012 14:53, Qrux a écrit :
Howdy.
In trying to build LFS-7.0 with LFS-7.0, I'm getting this error:
FAIL: test-readlink (exit: 134)
===
[...]
OOH, it doesn't appear to be a huge issue, so the sed is nice...OTOH, it's
still a red flag
Le 09/03/2012 14:53, Qrux a écrit :
1) Does anyone else see this in either 7.0 or 7.1 when building LFS from
their host platform?
no
2) Does anyone see this when building 7.0 (or 7.1) from 7.0?
not tried
3) Does anyone see this when building 7.1 from 7.1?
no. I just tried buiding m4 from 7.1
Le 10/03/2012 02:32, Qrux a écrit :
Thanks for all the responses (I'm still looking through some info Pierre sent
me).
@Pierre: I'm talking about *testing* m4 (in Chap 6). If you're using
openSUSE-12.1, you should see this error if you run the tests for m4--I did.
Sorry, I really meant
Le 10/03/2012 09:57, Pierre Labastie a écrit :
Sorry, I really meant the tests pass. I didn't send the
not-so-informative result of the test:
PASS: test-readlink.
Whatever I do, I never see an error. Even with the 3.2.6 kernel built
with LFS. I used 7.1, but without the patch, of course
Hi,
In chapter06/gcc.xml, there is an extraspace at the
end of the line --enable-threads=posix \ . This makes
configure start right after that line when copying and pasting,
without reading the other options.
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Le 12/03/2012 10:18, Andrew Benton a écrit :
On Mon, 12 Mar 2012 00:31:41 +
Jeremy Huntworkjhuntw...@lightcubesolutions.com wrote:
On Fri, 2012-03-02 at 00:39 +, Andrew Benton wrote:
I'm still no nearer to figuring out why I get this error. Trying to
follow Jeremy's new newlib build
Le 12/03/2012 15:07, Andrew Benton a écrit :
The --disable-target-zlib and --disable-target-libiberty patch is what
we're discussing here. Jeremy says he can compile without it.
Andy
I can compile without it too. But I do not have the logs anymore.
I looked at logs obtained with the patch.
Le 12/03/2012 15:07, Andrew Benton a écrit :
The --disable-target-zlib and --disable-target-libiberty patch is what
we're discussing here. Jeremy says he can compile without it.
Andy
I've run binutils/gcc-pass1 following Jeremy's patch, with gcc-4.6.3,
so without --disable-target-*.
It
Le 13/03/2012 03:44, Jeremy Huntwork a écrit :
I'm not sure what you're doing differently, but I can't replicate.
JH
Maybe, what you could do is exchange your logs and diff them?
Or send it both to me, and I'll try to diff them sometime today.
This is useful only if you have not used make -j,
Le 13/03/2012 16:18, Andrew Benton a écrit :
I was unwilling to use jhalfs as I dislike sudo. However, needs must,
and the result?
[...]
This was using Jeremy's sysroot.diff on top of the LFS xml files. I
think vanilla LFS will work for me as it has the patch and
--disable-target-zlib
So
Le 13/03/2012 20:14, Bruce Dubbs a ecrit:
- if [ $2 == lib ]; then
-file=$(PATH=/lib:/usr/lib type -p $1)
+ if [ $2 = lib ]; then
+file=$(find /lib /usr/lib -maxdepth 1 -name $1 | head -n 1)
else
-file=$(type -p $1)
+file=$(find /bin /usr/bin /sbin /usr/sbin -maxdepth
Le 14/03/2012 03:02, Andrew Benton a écrit :
On Tue, 13 Mar 2012 22:37:30 +
Gilles Espinasseg@free.fr wrote:
- Original Message -
From: Andrew Bentona...@benton.eu.com
To:lfs-dev@linuxfromscratch.org
Sent: Tuesday, March 13, 2012 11:00 PM
Subject: Re: [lfs-dev] gcc cross
Le 15/03/2012 04:32, Bryan Kadzban a écrit :
Jeremy Huntwork wrote:
On 3/8/12 4:24 PM, Bruce Dubbs wrote:
Jeremy Huntwork wrote:
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
Yes, I saw that. Reviewing.
How is that coming along?
Not well, sorry. I've got some personal things going on right now
Le 16/03/2012 07:45, Bryan Kadzban a écrit :
Pierre Labastie wrote:
Le 15/03/2012 04:32, Bryan Kadzban a écrit :
This may have been covered in this thread already, but I don't
recall anymore -- did you do an ICA run with this change?
I have not taken the time to directly compare the results
Le 18/03/2012 23:56, Bryan Kadzban a écrit :
I am not sure I fully understand this story of relocation data...
I'd have to guess different flags sent to the linker. As for *why*
those flags are being sent differently... no idea yet. :-) I should
get some hardware and start rebuilding to
Le 20/03/2012 05:24, Bryan Kadzban a écrit :
That's weird. There are no differences in the strip binaries (when you
do strip the libraries), right? Or in libbfd.so.whatever-it-is?
Actually, in the book, the binaries in {,/usr}{/bin,/sbin} are stripped,
and the
libraries in {,/usr}lib from
Le 20/03/2012 22:53, g@free.fr a écrit :
Would not using something like
export GZIP='-n'
solve the include timestamp issue?
Gilles
Well, anyway, unzipping files allows to compare them more easily.
And I think it would not be safe to change book instructions just for the
purpose of doing
Le 22/03/2012 22:43, Thierry Nuttens a écrit :
Hello,
I'm facing some trouble which I could partially solved but pass1 glibc 2.15
is not compiling successfully. Any idea
GNU C (GCC) version 4.7.0 (x86_64-lfs-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version
Le 23/03/2012 12:09, Thierry Nuttens a écrit :
Anyway install_root=/tools should have been install_root=$LFS in fact.
Actually, this is the correct way to cross-compile a package:
Use a cross-compiler (binutils-pass1+gcc-pass1) and install the package
to a place
where it can be transferred
Hi,
I've tried the last svn version on my old pentium-m
laptop.
1- The error:
/mnt/lfs/sources/libc-build/math/s_frexp.os.dt -MT
/mnt/lfs/sources/libc-build/math/s_frexp.os
./sysdeps/i386/fpu/s_frexp.S: Assembler messages:
./sysdeps/i386/fpu/s_frexp.S:66: Error: invalid identifier for .ifdef
Le 27/03/2012 15:12, Matthew Burgess a écrit :
2- When building without optimization (noOpt in jhalfs), there is an error
glibc cannot be built without optimization
Is this a regression from Glibc-2.14.1? It certainly sounds like an explicit
decision from upstream.
Well, I have to test again
Le 27/03/2012 22:23, Matt Burgess a écrit :
On Tue, 2012-03-27 at 18:47 +0200, Pierre Labastie wrote:
Well, I have to test again and my 32 bit computer is slow (I never built
glibc
with noOpt before). Will tell tomorrow...
A quick grep of the sources suggests you'll hit the same issue
Matt,
Thanks for the quick fixes.
Looks like you have included instructions for downloading the glibc
patch, but it seems that it is not included in the instructions of glibc
(chapter 5 at least, not looked at chapter 6).
Regards,
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
Hi,
The binutils patch in chapter05/binutils-pass{1,2} should be applied
before changing directory
to binutils-build:-) . Chapter06/binutils is OK.
Regards,
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above
Le 28/03/2012 10:32, Matthew Burgess a écrit :
On Wed, 28 Mar 2012 10:23:57 +0200, Pierre Labastiepierre.labas...@neuf.fr
wrote:
Hi,
The binutils patch in chapter05/binutils-pass{1,2} should be applied
before changing directory to binutils-build:-) . Chapter06/binutils is OK.
BTW, the
Le 27/03/2012 18:47, Pierre Labastie a écrit :
Le 27/03/2012 15:12, Matthew Burgess a écrit :
2- When building without optimization (noOpt in jhalfs), there is an error
glibc cannot be built without optimization
Is this a regression from Glibc-2.14.1? It certainly sounds like an explicit
Le 29/03/2012 08:47, Matt Burgess a écrit :
On Wed, 2012-03-28 at 22:39 -0400, Ivan Wagner wrote:
Matt,
Whoops, yes, it was in chapter 6, but not in chapter 5. Fixed in r9792.
The fix got put in the middle of something else so that the line now reads:
The Glibc documentation recommends
Le 29/03/2012 19:13, Pierre Labastie a écrit :
Hi,
#include ... search starts here:
#include... search starts here:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
/tools/include
Le 29/03/2012 22:59, Jeremy Huntwork a écrit :
Le 29/03/2012 19:13, Pierre Labastie a écrit :
Hi,
#include ... search starts here:
#include...search starts here:
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown
Le 22/04/2012 22:09, Jeremy Huntwork a écrit :
On 4/22/12 3:48 PM, Pierre Labastie wrote:
I think the sysroot method can be simplified if using the switch above:
you do not even need the part:
cp gcc/Makefile.in{,.orig}
sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
gcc
Le 22/04/2012 23:07, Jeremy Huntwork a écrit :
Looks good, committing the change to the jh branch. Thanks Pierre.
You're welcome.
I take the opportunity to thank you, all the editors of those
wonderfull books (lfs and blfs). I really enjoy interacting with
you. You're reactive, knowlegeable and
Le 23/04/2012 18:45, Jeremy Huntwork a écrit :
This changelog entry on 2012-04-05 isn't quite correct. It reads:
[matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
instead of the one from chapter 5. Install su as su rather than su-tools
in chapter 5. Fixes #3057.
Le 23/04/2012 23:01, Bruce Dubbs a écrit :
Matt Burgess wrote:
'../gcc-4.7.0/contrib/test_summary $TEST_LOG 21', hence giving the
appearance that the tests were run twice. I wonder whether that 2nd
command should just have 'role=nodump' in it to prevent jhalfs from
running it?
I think I'd
Le 23/04/2012 22:38, Jeremy Huntwork a écrit :
On 4/23/12 4:33 PM, Matt Burgess wrote:
The fix for this is to add
--with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
builds so that it doesn't look at /usr/include at all.
For the current build method, I think it's only
Le 23/04/2012 22:34, Bruce Dubbs a écrit :
Bruce Dubbs wrote:
It appears there are multiple ways to isolate the programs we need in
Chapter 6 to /tools. For us, the simpler the better. I think we ought
to do a little more testing, but it's looking good.
I'm still in the initial build, but
Le 24/04/2012 11:00, Matthew Burgess a écrit :
1) sudo chmod a=rx,u+s /tools/bin/su in chapter 5 coreutils
2) Dropped the getlogin.c sed from chapter 6 coreutils
The test still fails. It appears to be because of the way that jhalfs is
setting things
up. The test assumes you will have a
Le 25/04/2012 03:35, Ken Moffat a écrit :
On Wed, Apr 25, 2012 at 02:18:40AM +0100, Ken Moffat wrote:
On Tue, Apr 24, 2012 at 08:43:43PM +0100, Ken Moffat wrote:
Still doing this after chapter 6 is complete, but at a differnet
line in the same file. Oddly, if I try 'make' *after* the error
Le 24/04/2012 02:38, Andrew Benton a écrit :
If you only add --with-native-system-header-dir=/tools/include to the
second pass of gcc then you will still need --without-ppl and
--without-cloog for the second pass of gcc.
I get a build failure if I try to build without
Le 07/05/2012 14:46, Andrew Benton a écrit :
Including cairo/cairo.h in every header seems like quite a large
sledgehammer to crack a nut. Perhaps a more delicate solution would be
(for librsvg-2.36.1):
sed -i '/_gir_CFLAGS/s#$# -I/usr/include/cairo#' Makefile.in
Andy
Thanks,
I like that
Le 07/05/2012 18:00, Ken Moffat a écrit :
In my case I build dbus, cairo, gtk-doc, dbus-glib, ...,
gobject-introspection in that order, followed by pango, atk,
shared-mime-info, cups, gdk-pixbuf, gtk2, gtk3. I don't imagine that
variations in the build order are causing this, but librsvg is
Le 08/05/2012 22:22, Pierre Labastie a écrit :
The Firefox and Seamonkey pages have a paragraph that mentions how you
can install all the development libs. If they need changing to
accommodate icedtea please let me know.
Andy
Thanks for pointing me to that. I'll test tomorrow.
Pierre
I am
about
overwritten files, and you can uninstall with just one command.
Sample of the description file for gcc in chapter 6 of LFS:
-
cd $DESTDIR
mkdir -v DEBIAN
cat DEBIAN/control EOF
Package: gcc-lfs
Version: 4.4.3
Architecture: i386
Maintainer: Pierre Labastie
Le 02/06/2012 18:00, Jeremy Huntwork a écrit :
I'm going to start by jumping on the parser, since it will be necessary
right away for any of this to work. My initial thoughts are to build one
parser that can accept different output filters, for example, outputting
to PKGBUILD files, or rpm
Le 03/06/2012 06:22, Bruce Dubbs a écrit :
This is mostly for Matt, but others may take note.
I was adding new pages to LFS and had a hard time getting pkg-config to
be recognized by jhalfs. What I found out was that the xml code:
?dbhtml filename=pkg-config.html?
and the file name
Le 03/06/2012 06:22, Bruce Dubbs a écrit :
I originally had filename=pkgconfig.html and jhalfs couldn't file the
package and didn't give a warning or error. It just failed when the
build got to that point. In this case, after several hours. :(
-- Bruce
BTW,
Once the correction is
Le 02/06/2012 18:00, Jeremy Huntwork a écrit :
I'm going to start by jumping on the parser, since it will be
necessary right away for any of this to work. My initial thoughts are
to build one parser that can accept different output filters, for
example, outputting to PKGBUILD files, or rpm
Le 12/07/2012 05:18, Bryan Kadzban a écrit :
Matt Burgess wrote:
On Sun, 2012-07-01 at 18:20 +0100, Andrew Benton wrote:
Fixed by this sed in the gcc source before the first pass of gcc:
sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure
I don't mind displaying my lack of autofoo
Hello,
I know it has been reported by Tobias on lfs-support, but it seems to me
it is an issue with the current version of check, and it should be
addressed in the book:
- the error occurs during make:
/bin/bash ../libtool --tag=CC --mode=compile gcc
Le 25/11/2012 19:06, Matt Burgess a écrit :
Hmm, on a Fedora 17 host, I get:
checking for pipe... yes
checking for putenv... yes
checking for setenv... yes
checking for sleep... yes
checking for strdup... yes
checking for strsignal... yes
checking for unsetenv... yes
Looks like
Le 26/11/2012 09:06, Pierre Labastie a écrit :
First, I confirm that without any flag, everything went well.
Actually not: I had forgotten to remove LDFLAGS=-lpthread from the
configure command, which I had added for testing.
So the error is still there. I think I have found the reason.
After
Le 02/12/2012 11:31, Pierre Labastie a écrit :
[...]
After gcc-pass2, using the dummy.c as in the book, try:
gcc -v -Wl,--verbose dummy.c -lrt 21 | grep '\( \|usr\)/lib'
I get:
found libpthread.so.0 at /lib/x86_64-linux-gnu/libpthread.so.0
(see 'at /lib/...' instead of 'at /tools/lib
It seems that the VERSION=196 instruction should be changed
to VERSION=196-2 in udev-lfs-196-2/Makefile.lfs.
Otherwise the 'include' instructions fails when running
make -f udev-lfs-196-2/Makefile.lfs
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Le 02/12/2012 23:35, Bruce Dubbs a écrit :
Pierre Labastie wrote:
It seems that the VERSION=196 instruction should be changed
to VERSION=196-2 in udev-lfs-196-2/Makefile.lfs.
Otherwise the 'include' instructions fails when running
make -f udev-lfs-196-2/Makefile.lfs
Humm, thanks Pierre
Le 03/12/2012 18:29, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Well, only changing the 'VERSION' line was enough to achieve the build
and to boot a virtual machine. So I thought there was no other issue.
That makes things like 'udevadmm --version' give the wrong results. The
lfs part
Hi,
Not long ago, I had some problems with the building of check, which
I traced back to some problem with binutils pass2 (see
http://linuxfromscratch.org/pipermail/lfs-dev/2012-December/067444.html).
But it seemed that nobody had the same issue.
I think I have found the way to trigger the bug:
Le 17/12/2012 17:13, Bruce Dubbs a écrit :
[...]
By far, the biggest problem is having the wrong symlink for /bin/sh. I
recently highlighted the symlink issue in Section 5.3 of SVN. [...]
I have made a great number of builds with /bin/sh being a link to dash
without any flaw. The two others
Le 18/12/2012 22:12, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Le 17/12/2012 17:13, Bruce Dubbs a écrit :
[...]
By far, the biggest problem is having the wrong symlink for /bin/sh. I
recently highlighted the symlink issue in Section 5.3 of SVN. [...]
I have made a great number of builds
Le 20/12/2012 19:10, John Joganic a écrit :
In the stable LFS book, the host /dev directory is mounted into the chroot
environment using a bind mount.
mount -v --bind /dev $LFS/dev
Next, the following command removed a symbol link and mounted tmpfs for the
chroot environment, but there's
1 - 100 of 196 matches
Mail list logo
