headers
Jonathan Davis | 1 Jan 2007 22:06
Picon

Re: python installation troubles

> So, if anyone here has a clue as to how to get python's make test and
> make install to work properly in 32-bit land, I'd definitely
> appreciate it.  I DID try USE_ARCH=32 in case that did something, but
> nothing changes.  While CBLFS sets up tcl to use the multiarch
> wrapper, it does NOT set up tk to use it.  Perhaps tk should be as
> well and that's the problem, but I doubt it.  If anyone knows, or has
> a suggestion, please send it my way.  Thanks.
>
> - Jonathan M Davis

In a bout of weirdness, the last time that I tried the 32-bit
installation again (with the -fwrapv flag), it worked.  Before it
didn't and now it does.  As far as I know, I didn't change anything
whatsoever, so I have no clue why it worked this time, but it did.

I have updated the python instructions in CBLFS to use the -fwrapv
flag so that this problem will hopefully not plague anyone else.

- Jonathan M Davis
Permalink | Reply | 0 comments |
headers
Vladimir A. Pavlov | 3 Jan 2007 23:03
Picon

Re: X86/X86-CLFS-1.0.0: init dos not start - boot stops at "Freeing unused kernel memory..."

On Saturday 30 December 2006 14:38, Marc Michalewicz wrote:
> But during booting the target, right after the message "Freeing
> unused kernel memory [..]" nothing happens anymore, system hangs.
> In the internet I read, the configured CPU in the kernel may not
> the correct one - but I tried some (386, 486) without any success.
> The same for the whole build-process, I tried as well i486 as target,
> with no success either, so I am quite clueless now, and I would
> greatly appreciate any hint or help. 

1. What're your CLFS_HOST and CLFS_TARGET variables?

2. Did you see this thread:
   http://lists.linux-phreak.biz/pipermail/clfs-support/2006-October/000366.html ?

3. You wrote to lfs-support that you had found out that the
   init-process did not start. Can you say why it didn't?

4. Try to modify /etc/inittab so that /bin/bash is started instead of
   /sbin/init and look what happens. In particular, are you sure the
   problem is in the /sbin/init?

--

-- 
Nothing but perfection
pv
Permalink | Reply | 2 comments |
headers
Joe Ciccone | 3 Jan 2007 22:47
Picon

Re: X86/X86-CLFS-1.0.0: init dos not start - boot stops at "Freeing unused kernel memory..."

Vladimir A. Pavlov wrote:
> On Saturday 30 December 2006 14:38, Marc Michalewicz wrote:
>   
>> But during booting the target, right after the message "Freeing
>> unused kernel memory [..]" nothing happens anymore, system hangs.
>> In the internet I read, the configured CPU in the kernel may not
>> the correct one - but I tried some (386, 486) without any success.
>> The same for the whole build-process, I tried as well i486 as target,
>> with no success either, so I am quite clueless now, and I would
>> greatly appreciate any hint or help. 
>
>
> 2. Did you see this thread:
>    http://lists.linux-phreak.biz/pipermail/clfs-support/2006-October/000366.html ?
>   
That thread is relevant to building a x86 final system to a triplet
other then $(uname -m)-pc-linux-gnu. This message has a workaround.
http://lists.linux-phreak.biz/pipermail/clfs-support/2006-October/000369.html

> 3. You wrote to lfs-support that you had found out that the
>    init-process did not start. Can you say why it didn't?
>   
Are there any messages indicating that it couldn't mount the root
filesystem or that the kernel couldn't execute init?
> 4. Try to modify /etc/inittab so that /bin/bash is started instead of
>    /sbin/init and look what happens. In particular, are you sure the
>    problem is in the /sbin/init?
>   
Well, modifying inittab wont stop init from loading because init is the
one that parses that file not the kernel. If you want to boot straight
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir A. Pavlov | 4 Jan 2007 01:14
Picon

Re: X86/X86-CLFS-1.0.0: init dos not start - boot stops at "Freeing unused kernel memory..."

On Thursday 04 January 2007 00:47, Joe Ciccone wrote:
> > 4. Try to modify /etc/inittab so that /bin/bash is started instead of
> >    /sbin/init and look what happens. In particular, are you sure the
> >    problem is in the /sbin/init?
> >   
> Well, modifying inittab wont stop init from loading because init is the
> one that parses that file not the kernel. If you want to boot straight
> to bash put init=/bin/bash on the kernel's command line through your
> bootloader.

Oops... I'm sorry, I was wrong.

Thanks for the correction.

--

-- 
Nothing but perfection
pv
Permalink | Reply | 0 comments |
headers
Eshi | 7 Jan 2007 13:25
Picon

what's tthe problem is?

after we construct the temporary system there is a choice to boot up or to chroot, i have problems with this choice - i really can choose booting, but i don't understand what to do? We use su - clfs when constructing the temporary, but here what we must to do - use root to complete and after boot this system to build the final one, or what?? Chroot choice doesn't work at my system, however i want to do it, because of very simple instructions, help me pls to choose! thx
_______________________________________________
Clfs-support mailing list
Clfs-support <at> lists.cross-lfs.org
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Permalink | Reply | 1 comment |
headers
Dennis J Perkins | 7 Jan 2007 17:46
Favicon

Re: what's tthe problem is?

On Sun, 2007-01-07 at 15:25 +0300, Eshi wrote:
> after we construct the temporary system there is a choice to boot up
> or to chroot, i have problems with this choice - i really can choose
> booting, but i don't understand what to do? We use su - clfs when
> constructing the temporary, but here what we must to do - use root to
> complete and after boot this system to build the final one, or what??
> Chroot choice doesn't work at my system, however i want to do it,
> because of very simple instructions, help me pls to choose! thx
> _______________________________________________

The answer depends on the host OS and the target OS.  If the host can
run the programs that you are building for the target, you can use
choot.  Otherwise, you must boot into the target and continue building
from there.

So, if the host is a 32-bit Linux and you are building a 64-bit CLFS,
you must boot because the host cannot run 64-bit code.  If the host is
biarch (32-bit and 64-bit) or if it is 64-bit, you can chroot.
Permalink | Reply | 0 comments |
headers
amdsux | 7 Jan 2007 19:07

Xorg 6.9 multilib instructions missing in the CBLFS wiki.

 Because I am getting segfaults when installing parts of Xork 7.0, I am going to
go with 6.9 untill I can get time to mess around with 7.0  I am not sure how to
change the make worls command so that I can build 32 and 64 bit builds.

I can make the page on the wiki if somone can give me the changes to the BLFS
instructions.

Thanks for your time

DAve B
Permalink | Reply | 2 comments |
headers
Ken Moffat | 8 Jan 2007 00:17

Re: Xorg 6.9 multilib instructions missing in the CBLFS wiki.

On Sun, Jan 07, 2007 at 11:07:20AM -0700, amdsux <at> telus.net wrote:
>  Because I am getting segfaults when installing parts of Xork 7.0, I am going to
> go with 6.9 untill I can get time to mess around with 7.0  I am not sure how to
> change the make worls command so that I can build 32 and 64 bit builds.
> 
 I don't see any problems with 7.1 (didn't try 7.0, and it's a bit
old to try now), but then I'm happy with my AMD processors.

> I can make the page on the wiki if somone can give me the changes to the BLFS
> instructions.

 I'll ignore any possible copyright issues with the blfs
instructions, and tell you that the changes I needed for x86_64
multilib with 6.9 seem to be

for 32:
 in host.def add
#define LibDirName lib
#define HaveLib64 NO

 then
make CC="gcc -m32" WORLDOPTS="" World # use $BUILD32
and similarly for make install

for 64:
 in host.def add
#define LibDirName lib64
#define LibDir /usr/X11R6/lib64/X11
#define HaveLib64 YES

 and build as normal (because -m64 is the x86_64 default)

 in my case, I then removed the 32-bit fonts:
rm -rf /usr/X11R6/lib/X11/fonts
ln -sf /usr/X11R6/lib64/X11/fonts /usr/X11R6/lib/X11/fonts

- my script is about a year old, possibly things like where the
fonts should be have changed since then in current blfs.  Also, I
never bothered with the symlinks part of the build, which seemed
unnecessary overhead to me.  YMMV.

 Whether it is a good idea to point clfs builders to an old
unmaintained X implementation is a different matter entirely.  Your
time might be better spent asking for help on the problems you are
seeing :-)

ĸen
--

-- 
das eine Mal als Tragödie, das andere Mal als Farce
Permalink | Reply | 1 comment |
headers
Joe Ciccone | 8 Jan 2007 00:11
Picon

Re: Xorg 6.9 multilib instructions missing in the CBLFS wiki.

Ken Moffat wrote:
> On Sun, Jan 07, 2007 at 11:07:20AM -0700, amdsux <at> telus.net wrote:
>   
>>  Because I am getting segfaults when installing parts of Xork 7.0, I am going to
>> go with 6.9 untill I can get time to mess around with 7.0  I am not sure how to
>> change the make worls command so that I can build 32 and 64 bit builds.
>>
>>     
>  I don't see any problems with 7.1 (didn't try 7.0, and it's a bit
> old to try now), but then I'm happy with my AMD processors.
>
>   
>> I can make the page on the wiki if somone can give me the changes to the BLFS
>> instructions.
>>     
>
>  I'll ignore any possible copyright issues with the blfs
> instructions, and tell you that the changes I needed for x86_64
> multilib with 6.9 seem to be
>
> for 32:
>  in host.def add
> #define LibDirName lib
> #define HaveLib64 NO
>
>  then
> make CC="gcc -m32" WORLDOPTS="" World # use $BUILD32
> and similarly for make install
>
> for 64:
>  in host.def add
> #define LibDirName lib64
> #define LibDir /usr/X11R6/lib64/X11
> #define HaveLib64 YES
>
>  and build as normal (because -m64 is the x86_64 default)
>
>   
>From what I've learned. You can use the same host.def for the 32bit
build and the 64bit build.

You only need to add #define HaveLib64 NO on a pure64 system.
>  in my case, I then removed the 32-bit fonts:
> rm -rf /usr/X11R6/lib/X11/fonts
> ln -sf /usr/X11R6/lib64/X11/fonts /usr/X11R6/lib/X11/fonts
I've always left them, although i don't see what good they would do.

I added a page in cblfs, feel free to cut/hack/stab at it in any way
possible.
Permalink | Reply | 0 comments |
headers
Jaqui Greenlees | 8 Jan 2007 10:20
Picon
Favicon

sane build environmnt...

I'm planning on building lfs on my new system, which
is an AMD AM2 3800+ based system.

using the linux64 option on the lfs livecd is a sane
environment for building onto this dual core system?

I did install a mainstream distro to test hardware
compatibility, and Mandriva2007 was able to drive
everything with default configuration of the hardware.
but Mandriva is most definitely not a sane build
environment, they have far to many customizations.

Jaqui

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
Permalink | Reply | 0 comments |

Gmane