FWIW, the rest of my 6.6 build was uneventful, and it booted last
night. That's not yet much of a test, none at all of nscd.
--
Paul Rogers
paulgrog...@fastmail.fm
http://www.xprt.net/~pgrogers/
Rogers' Second Law: Everything you do communicates.
(I do not personally endorse any additions after
On 07/06/10 16:35, linux fan wrote:
# Hack to solve glibc __stack_chk_guard cross compile ( 2.4 :)
# this schpeel in LFS-6.6 ch5 gcc-pass1 and ch5 gcc-pass2 after unpack:
glibc=$(ls /lib/libc-*.so)
read j1 v[0] v[1] v[2] j2 ${glibc//[-.]/ }
if (( v[0] 2 )) || (( v[1] 4 )) [ -f
On 6/8/10, Andrew Benton b3n...@gmail.com wrote:
shouldn't that be
if (( ${v[0]} 2 )) (( ${v[1]} 4 ))
or maybe (( v[0] == 2 )) (( v[1] 4 ))
... bash (( allowed me to omit $ and {} around variables/arrays ))
But in the target lfs-6.6, glibc 2.4 is true, so the test isn't even needed.
On 6/8/10, Andrew Benton b3n...@gmail.com wrote:
so the whole thing can be reduced to:
v=($(ls /lib/libc-*.so | sed 's/[.-]/ /g'))
[ (( ${v[1]} 2 )) (( ${v[2]} 4 )) ]
sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' ../gcc-4.5.0/gcc/configure
[ $(ls /lib/libc-*.so \
| sed 's/[.-]/
# Hack to solve glibc __stack_chk_guard cross compile ( 2.4 :)
# this schpeel in LFS-6.6 ch5 gcc-pass1 and ch5 gcc-pass2 after unpack:
glibc=$(ls /lib/libc-*.so)
read j1 v[0] v[1] v[2] j2 ${glibc//[-.]/ }
if (( v[0] 2 )) || (( v[1] 4 )) [ -f gcc/configure ]; then
# kick it
sed -i -e '/#
linux fan wrote:
# Hack to solve glibc __stack_chk_guard cross compile ( 2.4 :)
# this schpeel in LFS-6.6 ch5 gcc-pass1 and ch5 gcc-pass2 after unpack:
glibc=$(ls /lib/libc-*.so)
read j1 v[0] v[1] v[2] j2 ${glibc//[-.]/ }
if (( v[0] 2 )) || (( v[1] 4 )) [ -f gcc/configure ]; then
#
Bruce Dubbs wrote:
[...]
After configure:
#ifdef TARGET_LIBC_PROVIDES_SSP
#undef TARGET_LIBC_PROVIDES_SSP
#endif
#define TARGET_LIBC_PROVIDES_SSP 1
Modern C compilers do not require that little idiom to prevent
a warning. #undefine-ing something which is not defined is not
supposed to
I imagine this will be ok.
Fun!
No, not ok.
/sources/glibc-build/nscd/connections.o: In function `main_loop_epoll':
/sources/glibc-2.11.1/nscd/connections.c:2005: undefined reference to
`__stack_chk_guard'
So it IS reproducible! You just have to start with a gcc-3.x.
Is there
Then this evening I made a copy of the script without that line and
recompiled glibc with the Stage2 compiler as the next step. No
problem this time. So I think I have a fairly straightforward
workaround. I don't imagine there was any need for the nscd code to
get through the gcc
On 6/4/10, Paul Rogers paulgrog...@fastmail.fm wrote:
So the problem was the Chapter 5 gcc?
I'm not sure that follows.
Seems to.
Intending to attempt to duplicate __stack_chk_guard error in chapter 6
while building lfs-6.6 from lfs-6.1.1 ...
The theory being that the host gcc/glibc ideal
On 6/4/10, linux fan linuxscra...@gmail.com wrote:
So the problem was the Chapter 5 gcc?
I'm not sure that follows.
Seems to.
... I decide to break out of it, and try something
... This diff in commands
=
---
Paul Rogers wrote:
Then this evening I made a copy of the script without that line and
recompiled glibc with the Stage2 compiler as the next step. No
problem this time. So I think I have a fairly straightforward
workaround. I don't imagine there was any need for the nscd code to
get through
On Wed, 2010-06-02 at 17:05 -0700, Paul Rogers wrote:
And if that leads some of us to scoff at the idea of dragons, it has, in
fact, done the job.
Oh, I don't scoff at the idea of dragons - I just don't recommend
stopping and asking them for directions. :)
Simon.
signature.asc
Description:
On 03/06/10 05:22, Mike McCarty wrote:
Andrew Benton wrote:
If I'm reading those correctly the problem happens when newer versions
of gcc are compiled against an older version of glibc, which begs the
question, why was Paul Rogers getting the undefined reference to
__stack_chk_guard error in
I wouldn't really say they are a triviality (given that I am one of
those who did much of the initial testing/research for the HSR's in
the first place) but they *are* just one of many parts of the book
that would need to be checked, though I would argue that they are
slightly less important
I've just done some googling on the subject today and it seems that when
gcc is compiled as a cross compiler it can cause the undefined
reference to `__stack_chk_guard' error. Of course, the version of gcc
being used in chroot, the second version of gcc compiled in chapter 5,
shouldn't be
shouldn't be a cross compiler. IE, it shouldn't have been configured
with --target=$LFS_TGT. I wonder if the people reporting these errors
mistakenly used the option --target=$LFS_TGT when they compiled gcc the
second time in chapter 5?
Yes, I can definitely confirm it was NOT in my Stage2
Paul Rogers wrote:
shouldn't be a cross compiler. IE, it shouldn't have been configured
with --target=$LFS_TGT. I wonder if the people reporting these errors
mistakenly used the option --target=$LFS_TGT when they compiled gcc the
second time in chapter 5?
Yes, I can definitely confirm it
On Sunday 30 May 2010 12:45:54 Paul Rogers wrote:
...
Yesterday I left my first few steps of Stage2 in place--their results
are in the FHS, which Stage1 will ignore. I CAREFULLY backed my way to
the Stage1 environment, then back through the Stage1 steps removing the
packages through the
On Tuesday 01 June 2010 04:46:36 Simon Geard wrote:
On Mon, 2010-05-31 at 09:35 -0700, Paul Rogers wrote:
On Mon, 2010-05-31 at 00:36 +0100, Ken Moffat wrote:
What you are overlooking is that doing it my way comes with when
it breaks, I get to keep all the pieces.
What a curious
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in
fact install flawlessly with those prerequisites.
Volunteers welcomed.
I reported it doesn't work with 6.1, that's as close as I had. And the
response I
On 6/2/10, Mike McCarty mike.mcca...@sbcglobal.net wrote:
Paul Rogers wrote:
I reported it doesn't work with 6.1, that's as close as I had. And the
response I got was, paraphrasing, use 6.3, it's known to work. There
seemed to be a complete lack of recognition of it being a problem with
the
On Wednesday 02 June 2010 21:22:07 Mike McCarty wrote:
Paul Rogers wrote:
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in
fact install flawlessly with those prerequisites.
Volunteers welcomed.
Danny Engelbarts wrote:
On Wednesday 02 June 2010 21:22:07 Mike McCarty wrote:
Paul Rogers wrote:
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in
fact install flawlessly with those prerequisites.
On 6/2/10, Danny Engelbarts d.engelba...@gmail.com wrote:
... a 6.3 system is required than the book should state 6.3 until proven
otherwise.
That is just exactly what the DEV book now requires.
Unfortunately, now we don't get to find out exactly why the original problem
undefined reference
On 26/05/10 03:04, Paul Rogers wrote:
/usr/local/src/glibc-build/libc_nonshared.a -lgcc -Wl,--as-needed
-lgcc_s -Wl,--no-as-needed `gcc --print-file-name=crtendS.o`
/usr/local/src/glibc-build/csu/crtn.o
/usr/local/src/glibc-build/nscd/nscd.o: In function `nscd_open_socket':
linux fan wrote:
On 6/2/10, Danny Engelbarts d.engelba...@gmail.com wrote:
... a 6.3 system is required than the book should state 6.3 until proven
otherwise.
That is just exactly what the DEV book now requires.
Unfortunately, now we don't get to find out exactly why the original
linux fan wrote:
On 6/2/10, Danny Engelbarts d.engelba...@gmail.com wrote:
... a 6.3 system is required than the book should state 6.3 until proven
otherwise.
That is just exactly what the DEV book now requires.
Unfortunately, now we don't get to find out exactly why the original
On 02/06/10 22:24, Mike McCarty wrote:
linux fan wrote:
Unfortunately, now we don't get to find out exactly why the original problem
undefined reference to __stack_chk_guard
surfaces from time to time.
I don't see why. It simply has to do with whether gcc provides the
stack clobber check.
Mike McCarty wrote:
linux fan wrote:
On 6/2/10, Danny Engelbarts d.engelba...@gmail.com wrote:
... a 6.3 system is required than the book should state 6.3 until proven
otherwise.
That is just exactly what the DEV book now requires.
Unfortunately, now we don't get to find out exactly why
Only one comment: are you *certain* you have removed all related
things before (or after) restoring a prior-built tarball? Just *one*
stupid file in the wrong place can bollux the works.
Yes, and yes. If I had been hand building and retreating by hand, I
agree, I certainly would have been
On 06/02/2010 08:05 PM, Paul Rogers wrote:
I don't see that the necessity of using a relatively recent version of
the kernel in the host environment to be, in spirit, any different
from requiring a relatively recent version of a C compiler. If all you
have is a KR C compiler, then the
On 6/2/10, Bruce Dubbs bruce.du...@gmail.com wrote:
The version of glibc within chroot certainly should support ssp but the
two reports we have didn't seem to find it automatically. Others cannot
duplicate the problem. If we had consistent errors on most builds, we
could fix it.
Could
My understanding is that Paul came upon an error while building 6.6
from 6.1. When he reported this error here the overall reply was that
he should try a more recent build to start with. Paul objects because
the 6.6 book stated 6.1 would suffice.
Actually, 6.1 mostly exceeds the 6.6 HSR's.
linux fan wrote:
On 6/2/10, Bruce Dubbs bruce.du...@gmail.com wrote:
The version of glibc within chroot certainly should support ssp but the
two reports we have didn't seem to find it automatically. Others cannot
duplicate the problem. If we had consistent errors on most builds, we
could
On Wednesday 02 June 2010 20:05:36 Paul Rogers wrote:
But one *can* bellow, Where am I? And of course, one should then
expect the obligatory, Yer in a boat in the midst of the sea, ya
dang fool!
But let's not AT ALL slight the purpose of LFS, to teach us how to build
a functional
Andrew Benton wrote:
On 02/06/10 22:24, Mike McCarty wrote:
linux fan wrote:
Unfortunately, now we don't get to find out exactly why the original problem
undefined reference to __stack_chk_guard
surfaces from time to time.
I don't see why. It simply has to do with whether gcc provides the
Paul Rogers wrote:
I agree that the problem you have uncovered is worth pursuing
down to root cause. Until we understand the root cause, we
can't be sure it won't come up again in the future. When it
is understood, then either a prevention in the sense of what
a minimal HSR is can be done, or a
On Mon, 2010-05-31 at 09:35 -0700, Paul Rogers wrote:
On Mon, 2010-05-31 at 00:36 +0100, Ken Moffat wrote:
What you are overlooking is that doing it my way comes with when
it breaks, I get to keep all the pieces.
What a curious thing to write in a SUPPORT forum of a LINUX distribution
On Mon, 2010-05-31 at 19:11 -0400, x2...@lycos.com wrote:
So Paul, what i really need to say is that if it breaks, you get to
keep the pieces but maybe, more important, if it doesn't break,
you still get to keep the pieces.
Well yes, that's true. But then, LFS is a natural path for those
On 01/06/10 01:54, Bruce Dubbs wrote:
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
Many Bothans died to bring us this information.
LOL
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above
Others have said it: unless we can duplicate the problem somebody
faces doing things slightly different, support can be hard to provide.
As Ken wrote and I believe, most of your development team can be
expected to stay pretty close to front-line developments. As seems
indicated by the current
Your distro, your rules - but going along with that, there's the
unstated your rules, your problems. There's nothing wrong with
exploring uncharted waters, but if you sail into the middle of here be
dragons, you can't expect to stop and ask for directions...
There was a guy chained to the
Paul Rogers wrote:
As seems
indicated by the current situation, someone should adopt a QC role, and
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in fact
install flawlessly with those prerequisites.
The Host System requirements may indeed be too low for LFS 6.6
Updated to the packages in LFS-6.3, known to work for LFS-6.6 Added
erratum to website.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See
On 1 June 2010 19:40, Paul Rogers paulgrog...@fastmail.fm wrote:
As Ken wrote and I believe, most of your development team can be
expected to stay pretty close to front-line developments. As seems
indicated by the current situation, someone should adopt a QC role, and
have one system that
On 06/01/10 15:19, Bruce Dubbs wrote:
Paul Rogers wrote:
As seems
indicated by the current situation, someone should adopt a QC role, and
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in fact
install
Baho Utot wrote:
On 06/01/10 15:19, Bruce Dubbs wrote:
Paul Rogers wrote:
As seems
indicated by the current situation, someone should adopt a QC role, and
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and verifies that each version of LFS does in
On 06/01/10 18:24, Bruce Dubbs wrote:
Baho Utot wrote:
On 06/01/10 15:19, Bruce Dubbs wrote:
Paul Rogers wrote:
As seems
indicated by the current situation, someone should adopt a QC role, and
have one system that trails, i.e. has exactly the package versions
specified in the HSR, and
Baho Utot wrote:
The system I am using to compile this stuff is an AMD Phenom(tm) II X4
810 Processor that has 8G DDR3 memory. I use that system so I can make
mistakes really fast ;) ie things can go sour quickly and at a high rate
of speed. You usually don't get a chance to see them let
On 06/01/10 19:05, Bruce Dubbs wrote:
Baho Utot wrote:
The system I am using to compile this stuff is an AMD Phenom(tm) II X4
810 Processor that has 8G DDR3 memory. I use that system so I can make
mistakes really fast ;) ie things can go sour quickly and at a high rate
of speed. You usually
On 6/1/10, Baho Utot baho-u...@columbus.rr.com wrote:
Volunteers welcomed.
I'll volunteer...I can mess up anything :)
I am going to try it again as I am a gluten for punishment.
From one punishment lubber 't another:
Consider using the HSR that are now in LFS-DEV for your testing.
The
Possibly. The problem may be not using gcc-4.x.
So it seems, though grepping the kernel sources for 2.6.18 didn't
turn up any usage of PROTECTOR which would be in .config, hence
a matching string in it's configure/makefiles. So I expect.
My advice would be to use jhalfs for some arbitrary
Paul Rogers wrote:
My advice would be to use jhalfs for some arbitrary version of the
book that you choose and just let it run. We know that LFS-6.3 works
because it has been used a lot from the last LiveCD. That would be a
good candidate for an intermediate release.
No, if I decide to
On 5/31/10, Bruce Dubbs bruce.du...@gmail.com wrote:
You don't have any standing to 'expect' anything from us. You can
suggest, but with your attitude, my reaction is to push back and say no,
even if that's wrong.
-- Bruce
I support and congratulate Paul Roger's package management
On 31 May 2010 17:35, Paul Rogers paulgrog...@fastmail.fm wrote:
What you are overlooking is that doing it my way comes with when
it breaks, I get to keep all the pieces.
What a curious thing to write in a SUPPORT forum of a LINUX distribution
with the motto, YOUR DISTRO, YOUR RULES. I
On 1 June 2010 00:11, x2...@lycos.com wrote:
In my arrogance i drank of the ALFS.
Like a siren's song the jhalfs scripts drew me in. Only teasing me
with a few trials to test my love before providing, with barely a
touch of the keyboard, a new bootable LFS system with a
blfs_root
x2...@lycos.com wrote:
That was a very entertaining post. Thanks.
On a more serious note, we do try to address problems that come up. The
issue is that we have seen lots of posts where the final resolution is
oops, it was my error, not the book's. (Which you humorously noted.)
The
On 5/31/10, x2...@lycos.com x2...@lycos.com wrote:
Most of the posters with problems do seem to have,
for whatever reason, strayed from the path of righteousness
and not followed the book closely enough.
Quoth the creator:
Gerard: Read the book we wrote for our users. But, don’t be
Quoth the creator:
Gerard: Read the book we wrote for our users. But, don’t be afraid to
deviate from it. After all, that’s the whole point of the project: to
make a system for yourself, not according to somebody else’s
specifications.
Well, that was fun!
But first, I want to thank you all for your help while I persue this.
Since it does happen from time to time, and nobody knows exactly why or
how to fix it, we probably should find out what's happening.
Yesterday I left my first few steps of Stage2 in place--their results
are
On 30 May 2010 17:45, Paul Rogers paulgrog...@fastmail.fm wrote:
Yes, it does, and I could go from my current 6.1 to 6.3 by installing
the LiveCD. Except that also brings along X xfce, et al. The way I
go, cloning with the setup, restore, finish steps, I get a system that's
the equivalent
Since I cut and paste the book instructions into my build script
template, albeit with ample instruction and organization for use in
cloning the system too, I can provide them for the Stage 1 2 builds of
gcc and glibc, if it would help to see EXACTLY what I have done. I have
read all of a
On 5/29/10, Paul Rogers paulgrog...@fastmail.fm wrote:
Since I cut and paste the book instructions into my build script
template, albeit with ample instruction and organization for use in
cloning the system too, I can provide them for the Stage 1 2 builds of
gcc and glibc, if it would help to
I closely examined you script and my eyes could not detect anything
about the ch6-glibc that would cause any difference from pure cut and
There shouldn't be. I just separate the book instructions into setup,
e.g. useradd, build binaries, and finish, e.g. diddle /etc/fstab,
because it makes
Paul Rogers wrote:
The __stack_chk_guard which is only seen by grep in gcc, must have
gotten built in at some earlier step or possibly bled in from the
How far back do you suppose? Stage 2 pass 1 or Stage 1 pass 2? I can
quite confidently rip either out and replace it with my scripts.
On 5/29/10, Paul Rogers paulgrog...@fastmail.fm wrote:
No fun. 1.4GHz P-3, 512MB. Besides, as I wrote, I really want to have
a clean migration path. Maybe 6.1 to 6.6 is too far a jump, but it
matched the HSR with the exception of kernel version.
Besides I rather think the LiveCD starts
I tried restarting the make, but it just failed with the next routine
in the list, connect.c. I expected that, it's using the same
parameter list. I did grep for -fstack-protector, and found it only
in the login nscd directories. Then it occurred to me to check the
gcc package for that
On 5/28/10, Paul Rogers paulgrog...@fastmail.fm wrote:
gcc package for that __stack_chk_guard variable, assuming it was
defined there. It's not. Could someone please grep their include
directory and let me know where it is defined? I haven't found it on
my system.
grep -r -c
On 28 May 2010 05:21, linux fan linuxscra...@gmail.com wrote:
I maintain some pure IDE drives as hdXn by using the config parameters:
CONFIG_HAVE_IDE=y
CONFIG_IDE=y
in addition to:
CONFIG_ATA=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_PROMISE=y
for the SATAS as sdXn, providing the peaceful
On 5/28/10, Ken Moffat zarniwhoo...@googlemail.com wrote:
Good advice. I'd actually recommend 'make oldconfig' and then make
notes on *everything* that might be questionable, research, then set or
not in menuconfig, but that's just a variation - the important thing is not
to try to jump
I spent more time poking around. I don't find anything obvious grepping
in the kernel source code, neither 2.6.18 nor the 2.6.32.7. All I can
find is in the gcc-4.4.3. There are pointers, all of which I've looked
at, but I lack the skills, other than having to function in more than a
dozen
make[2]: Entering directory `/usr/local/src/glibc-2.11.1/nscd'
make[2]: Leaving directory `/usr/local/src/glibc-2.11.1/nscd'
make[2]: Entering directory `/usr/local/src/glibc-2.11.1/nscd'
gcc nscd.c -c -std=gnu99 -fgnu89-inline -O2 -O3 -Wall -Winline -Wwrite-
strings
Have built LFS-4.1 -6.1, trying to build -6.6 on -6.1. Stage 1
seemed to go well. Building glibc early in Stage2 failed. I did a
search, saw others had a similar problem, but didn't see a relevant
solution. The /scripts in my $PATH is where I put my cutpasted
build scripts.
After you get to this stoppage, try doing a paste of just these
instructions back with modifications. To do that, you need to paste
into vim and add backslashes to each line, change what you want (delete
-fstack-protector) and see if you can get that one file
(build/nscd/nscd.o) to
Paul Rogers wrote:
OK, I did that. It paused about one
second, then returned a command prompt. No console messages at all.
Ummm, waita minute! (I don't compile anything unless I'm installing
a package--I finished being a programmer over 25 years ago.) I guess
that means it worked, eh?
Paul Rogers wrote:
[...]
Yes, I've seen that in some of the other distros I've gotten from LXF.
Using SCSI emulation for IDE drives just seems WRONG somehow. I'm a
Wrong headed I'd say. However, if you think you do anything but
use Linux, then you're wrong. Influencing the course of it is
On 5/27/10, Paul Rogers paulgrog...@fastmail.fm wrote:
[Ken Moffat]
getting from a .config that worked in 2.6.18 to one that works in
2.6.32. Particularly, libata [ most ide drives now use libata and
therefore /dev/sdXn instead of hdXn ].
[Paul Rogers]
Yes, I've seen that in some of the
On 26/05/10 03:04, Paul Rogers wrote:
Have built LFS-4.1 -6.1, trying to build -6.6 on -6.1. Stage 1 seemed
to go well. Building glibc early in Stage2 failed. I did a search, saw
others had a similar problem, but didn't see a relevant solution. The
/scripts in my $PATH is where I put my
We've seen this before and there was really no good answer.
I did some googling and I think this may be a kernel issue. In the
kernel .config I am using, there is
# CONFIG_CC_STACKPROTECTOR is not set
I'm using an X86_64 and not a i686, so that may make a difference.
If your kernel was
Paul Rogers wrote:
We've seen this before and there was really no good answer.
I did some googling and I think this may be a kernel issue. In the
kernel .config I am using, there is
# CONFIG_CC_STACKPROTECTOR is not set
I'm using an X86_64 and not a i686, so that may make a difference.
On Wed, May 26, 2010 at 11:05:10AM -0700, Paul Rogers wrote:
When I installed LFS-6.1, it was patched up to 2.6.17, one short. ;-(
To
do this 6.6 install I patched to .18.
Hmm, I can see you don't like updating kernels ;) Assuming you can
get past the current problem [ for that, my only
Paul Rogers wrote:
Have built LFS-4.1 -6.1, trying to build -6.6 on -6.1. Stage 1 seemed
to go well. Building glibc early in Stage2 failed. I did a search, saw
others had a similar problem, but didn't see a relevant solution. The
/scripts in my $PATH is where I put my cutpasted build
83 matches
Mail list logo
