On 4/22/12 11:33 AM, LFS Trac wrote:
> #3066: Chapter 5 ncurses fails with (old?) gpm on host
> -+--
> Reporter: dj@… | Owner: lfs-book@…
> Type: task | Status: new
On 04/22/2012 06:11 PM, a...@linuxfromscratch.org wrote:
> Author: andy
> Date: 2012-04-22 10:11:50 -0600 (Sun, 22 Apr 2012)
> New Revision: 9975
>
> Modified:
> trunk/BOOK/x/lib/cairo.xml
> Log:
> patch cairo to expose some private functions that Firefox needs
>
This patch breaks the testsuit
Jeremy Huntwork wrote:
> On 4/22/12 11:33 AM, LFS Trac wrote:
>> #3066: Chapter 5 ncurses fails with (old?) gpm on host
>> -+--
>> Reporter: dj@… | Owner: lfs-book@…
>> Type: task
On 04/22/2012 12:19 PM, Jeremy Huntwork wrote:
> On 4/22/12 11:33 AM, LFS Trac wrote:
>> #3066: Chapter 5 ncurses fails with (old?) gpm on host
>> -+--
>>Reporter: dj@… | Owner: lfs-book@…
>>
On 4/22/12 2:23 PM, DJ Lucas wrote:
> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
> not a symlink, but rather a linker script that points to another linker
> script that points to an invalid destination (ie: no 64bit libgpm). I
> was going to close as invalid, but then
On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:23 PM, DJ Lucas wrote:
>> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
>> not a symlink, but rather a linker script that points to another linker
>> script that points to an invalid destination (ie: no 64bit libgp
DJ Lucas wrote:
> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
> not a symlink, but rather a linker script that points to another linker
> script that points to an invalid destination (ie: no 64bit libgpm).
Now, isn't that special.
> I was going to close as invalid
On 4/22/12 2:35 PM, Bruce Dubbs wrote:
> It only makes a difference if we are going to actually use ncurses
> functionality
> between the time we bould it in Chapter 5 and Chapter 6. Otherwise we are
> just
> linking to the libraries.
>
> However, I don't have a problem with adding --without-gpm
On 4/22/12 2:35 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
>> On 4/22/12 2:23 PM, DJ Lucas wrote:
>>> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
>>> not a symlink, but rather a linker script that points to another linker
>>> script that poi
Le 22/04/2012 20:23, DJ Lucas wrote:
> On 04/22/2012 12:19 PM, Jeremy Huntwork wrote:
>> On 4/22/12 11:33 AM, LFS Trac wrote:
>>> #3066: Chapter 5 ncurses fails with (old?) gpm on host
>>> -+--
>>> Reporter: dj@…
On 4/22/12 2:49 PM, Pierre Labastie wrote:
> Solution:
> add the switch --with-native-system-header-dir=/tools/include to
> gcc-pass2 configure command.
> I've been building ten times on various (virtual) hosts with this switch
> without a problem.
I believe the proposed sysroot method also fixes
Jeremy Huntwork wrote:
> On 4/22/12 2:49 PM, Pierre Labastie wrote:
>> Solution:
>> add the switch --with-native-system-header-dir=/tools/include to
>> gcc-pass2 configure command.
>> I've been building ten times on various (virtual) hosts with this switch
>> without a problem.
>
> I believe the p
On 4/22/12 2:52 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:49 PM, Pierre Labastie wrote:
>> Solution:
>> add the switch --with-native-system-header-dir=/tools/include to
>> gcc-pass2 configure command.
>> I've been building ten times on various (virtual) hosts with this switch
>> without a problem.
Le 22/04/2012 21:10, Bruce Dubbs a écrit :
> Jeremy Huntwork wrote:
>> On 4/22/12 2:49 PM, Pierre Labastie wrote:
>>> Solution:
>>> add the switch --with-native-system-header-dir=/tools/include to
>>> gcc-pass2 configure command.
>>> I've been building ten times on various (virtual) hosts with this
On 4/22/12 3:48 PM, Pierre Labastie wrote:
> cp gcc/Makefile.in{,.orig}
> sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
> gcc/Makefile.in.orig> gcc/Makefile.in
> cp gcc/cppdefault.c{,.orig}
> sed '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0@g' \
> gcc/cppdefault.c.or
Jeremy Huntwork wrote:
> So to be clear, Pierre is correct in that there is a serious flaw in the
> current LFS SVN. In fact, until this gets resolved LFS SVN should be
> considered completely broken. Having a chapter 5 toolchain that searches
> /usr/include kills the purpose of building a sepa
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/Makefile.in.orig> gcc/Makefile.in
> cp gcc/
On 04/22/2012 03:06 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> So to be clear, Pierre is correct in that there is a serious flaw in the
>> current LFS SVN. In fact, until this gets resolved LFS SVN should be
>> considered completely broken. Having a chapter 5 toolchain that searches
>> /u
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@' \
>>
On 4/22/12 4:09 PM, Jeremy Huntwork wrote:
> So CROSS_SYSTEM_HEADER_DIR should get set correctly if we've already
> specified NATIVE_SYSTEM_HEADER_DIR, which is what gets set via your switch.
>
> I'll just fix up the jh branch source and give another run and compare
> results.
Looks good, committi
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 an
So, I'm seeing that you have the aforementioned switches in both pass 1
and pass 2 gcc and I'm trying to understand exactly why.
Here's the changeset that introduced them:
http://wiki.linuxfromscratch.org/lfs/changeset/9349
And here's the ticket that started that ball rolling:
http://wiki.linuxf
On 04/22/2012 04:35 PM, Jeremy Huntwork wrote:
> So, I'm seeing that you have the aforementioned switches in both pass 1
> and pass 2 gcc and I'm trying to understand exactly why.
In pass1 it simply speeds up the build, the explanation is incorrect.
They shouldn't be needed by pass2.
-- DJ Lucas
On Sun, 2012-04-22 at 17:35 -0400, Jeremy Huntwork wrote:
> So given that... I don't see a need to have those switches for either
> pass 1 or pass 2.
Given your reasoning, I don't see why they're needed either, but #2723
explicitly mentioned link errors (although conveniently failed to copy
and
On 4/22/12 5:59 PM, DJ Lucas wrote:
> On 04/22/2012 04:35 PM, Jeremy Huntwork wrote:
>> So, I'm seeing that you have the aforementioned switches in both pass 1
>> and pass 2 gcc and I'm trying to understand exactly why.
>
> In pass1 it simply speeds up the build
How does it speed up the build?
JH
On 4/22/12 6:00 PM, Matt Burgess wrote:
> Given your reasoning, I don't see why they're needed either, but #2723
> explicitly mentioned link errors (although conveniently failed to copy
> and paste them). Now, admittedly, I never saw those errors myself, but
> then I only test on one arch on one h
On 04/22/2012 03:25 PM, DJ Lucas wrote:
>
> Should be able to give a thumbs up
> in about 45 minutes or so.
Yeah, good.
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxf
Jeremy Huntwork wrote:
> On 4/22/12 6:00 PM, Matt Burgess wrote:
>> Given your reasoning, I don't see why they're needed either, but #2723
>> explicitly mentioned link errors (although conveniently failed to copy
>> and paste them). Now, admittedly, I never saw those errors myself, but
>> then I o
On 04/22/2012 05:05 PM, Jeremy Huntwork wrote:
> On 4/22/12 5:59 PM, DJ Lucas wrote:
>> On 04/22/2012 04:35 PM, Jeremy Huntwork wrote:
>>> So, I'm seeing that you have the aforementioned switches in both pass 1
>>> and pass 2 gcc and I'm trying to understand exactly why.
>> In pass1 it simply speed
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:41 PM, Jeremy Huntwork wrote:
woops, that wasn't supposed to send. Turned out to be a very minor
thread after all. :)
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:44 PM, DJ Lucas wrote:
> I'm not entirely positive, it's been a few years, but there was no need
> to compile unnecessary additions that eat up time. Granted, it is a very
> small savings in the grand scheme. That was the goal of those switches
> and several others at the time that GCC
I've been studying Jeremy's changes and want to summarize them here.
Chapter 5
Binutil pass 1
Add two configure options:
--with-sysroot=$LFS
--with-lib-path=/tools/lib
These are not in the main binutils configure command, but are in the
configure for ld
gcc-pa
On 04/22/2012 10:36 PM, Bruce Dubbs wrote:
> I've been studying Jeremy's changes and want to summarize them here.
>
>
Asking for a technical review? :-) Both methods achieve the goal!
Now for a quick, non-technical overview of the effect on the book. You
have reduced the amount of lines in comm
34 matches
Mail list logo
