Building SVN-20081028 on a Playstation 3
Hi, My apologies if this is the wrong list for this post.. Due to the fact that lfs SVN-20081028 uses gcc-4.3 and a 2.6.27 kernel, which both contain various ps3 specific optimisation possibilities, I'm very interested by the idea of building an lfs system on a Playstation 3 using ydl-6 as a host. I've found almost nothing ps3 specific on the lfs site - other than some sbu information proving that somebody must have been successful - are there any lfs/ps3 guidelines/tips/howtos around that might avoid some blundering around in the dark? Note I'll almost certainly go ahead anyway... John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Building SVN-20081028 on a Playstation 3
At 13:28 29-10-08, you wrote: >Selon John Frankish <[EMAIL PROTECTED]>: > > > Hi, > > > > My apologies if this is the wrong list for this post.. > > > > Due to the fact that lfs SVN-20081028 uses gcc-4.3 and a 2.6.27 > > kernel, which both contain various ps3 specific optimisation > > possibilities, I'm very interested by the idea of building an lfs > > system on a Playstation 3 using ydl-6 as a host. > > > > I've found almost nothing ps3 specific on the lfs site - other than > > some sbu information proving that somebody must have been successful > > - are there any lfs/ps3 guidelines/tips/howtos around that might > > avoid some blundering around in the dark? > > > > Note I'll almost certainly go ahead anyway... > > > > John > > >On ipcop svn, we are able to build for ppc-32 mostly following lfs >instructions. >http://ipcop.svn.sourceforge.net/viewvc/ipcop/ipcop/trunk/ > >I should say I don't know if ps3 is a 32 or a 64b system. > >Our instructions are in overall not far from lfs instructions from a few weeks >ago (but the form sligthly differ related to lfsmake-like files usage). >We actually stay on gcc-4.2 and the move from 2.6.25 to 2.6.27 >kernel is not yet >made. > >The only big problem we have is that our initramfs is bigger than 6MB and even >with most recent yaboot git version, this does not boot (tested on a G3 350). >For a build on a dedicated machine, that should be easy to reduce >drivers number >and so initramfs size, so it simply work again. > > >Gilles >-- Thanks for the link Gilles The ps3 cell processor is 64bit, but ydl-6 is compiled 32bit. Due to the ps3 memory limitation - 256MB - I'm not sure building a 64bit lfs system would be a good idea... John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gcc-4.3.2 build fails
Hi, I'm trying to build on a playstation 3 with yellow dog linux v6 Although binutils-2.18 builds OK, gcc-4.3.2 fails after the first bootstrap pass succeeds and then gcc tries to compile a second version of itself. The failure is "gcc compiler cannot build executables" - config.log does not give too many clues... Note that I'm obliged to build using LDFLAGS=$CXXFLAGS=$CFLAGS='-m32' otherwise gcc-4.2.2 tries to build a 64-bit version of itself and fails looking for gnu/stubs-64.h - glibc and the rest of the ydl system is 32-bit. The host gcc is gcc-4.1.1 (I think). Any suggestions where I might be going wrong? John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.3.2 build fails
At 21:22 01-11-08, you wrote: >John Frankish wrote: > > Hi, > > > > I'm trying to build on a playstation 3 with yellow dog linux v6 > > > > Although binutils-2.18 builds OK, gcc-4.3.2 fails after the first > > bootstrap pass succeeds and then gcc tries to compile a second > > version of itself. The failure is "gcc compiler cannot build > > executables" - config.log does not give too many clues... > > > > Note that I'm obliged to build using > > LDFLAGS=$CXXFLAGS=$CFLAGS='-m32' otherwise gcc-4.2.2 tries to build > > a 64-bit version of itself and fails looking for gnu/stubs-64.h - > > glibc and the rest of the ydl system is 32-bit. The host gcc is > > gcc-4.1.1 (I think). > >-m32 only specifies what types of _binaries_ to produce. This means that > when you build gcc with -m32, it will produce a 32-bit binary gcc >(provided you have 32-bit libs, which you do), but the gcc you build >will still be configured for a 64-bit machine and when you run it, it >will attempt to build for that architecture. Because you don't have >64-bit libs, it will fail. > >You can't build 64-bit without first building a 64-bit libc, and you >can't build 32-bit unless you modify your host settings. > >If you want to build LFS as 32-bit, you _might_ get away with hacking >the output of uname to trick the build system into thinking you're >running on a 32-bit host, but a saner approach would be to build a >32-bit only kernel. > >If you want to build LFS as 64-bit, there is an approach that currently >works pioneered by DIY-Linux which involves cross-compiling your first >glibc and then building natively after that. I have some notes on that >method and have started adapting it to LFS, but I haven't published >anything yet. > >Otherwise, as was already mentioned, CLFS should be able to help you in >the right direction, too. > >-- >JH Thanks for the feedback I'd be interested in the notes to build a 64-bit LFS to play around with if you'd like somebody to act as a guinea pig for them John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.3.2 build fails
At 11:00 01-11-08, you wrote: >On Saturday 01 November 2008 02:49:24 John Frankish wrote: > > Any suggestions where I might be going wrong? > >Hi, > > >Have you had a chance to look at the clfs project yet? The build method >and support structure looks to be in place to guide you through the >type of build you have in mind. > >http://trac.cross-lfs.org/wiki/read >http://trac.cross-lfs.org/wiki/lists > > >Good luck, >Trent. >-- Thanks for the pointers. If I understand correctly, due to the fact that the ps3 has a 64-bit cpu/kernel and 32-bit os, I would need to cross-compile to get either a 64-bit os or a 32-bit os? Which would be better to use on the host system - the ydl-6 gcc-4.1.1. or IMB cell SDK-3 ppu-gcc? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.3.2 build fails
At 22:55 05-11-08, you wrote:
>On Sun, Nov 02, 2008 at 01:55:25AM -0800, Trent
>Shea wrote: > On Saturday 01 November 2008
>23:59:36 John Frankish wrote: > > If I
>understand correctly, due to the fact that the
>ps3 has a 64-bit > > cpu/kernel and 32-bit os, I
>would need to cross-compile to get either > > a
>64-bit os or a 32-bit os? Which would be better
>to use on the host > > system - the ydl-6
>gcc-4.1.1. or IMB cell SDK-3 ppu-gcc? > > I
>don't have any experience with this; I have not
>looked at the cell > processor in any great
>detail, but if it is anything like the amd64, >
>which allows you to run 32bit kernel/os, you
>should be able to boot a > 32bit distro and
>build away following the LFS instructions. > Or,
>if it's anything like the various versions of
>the 970 ('G5' in apple speak) the kernel will
>refuse to build unless you set it for 64-bits
>(and have a 64-bit (cross-) gcc (C only) and
>binutils. I've done that in the past for ppc
>(32) userspace on ppc64. Some packages in the
>base system may produce obscure issues doing
>that, so not all of my builds succeeded. >
>Whichever you choose it will have to be based on
>a little bit of > research, and usage
>analysis. > Dunno about the usage analysis (a
>lot of us build our own systems "because we can"
>or "because it's there"), but research is
>definitely needed. 'linux32' can be helpful if
>configure thinks it's on a 64-bit machine. As
>was said earlier, clfs might be (a little) more
>useful - I'm not willing to talk about the
>detail here, it's definitely O/T (we haven't
>even got x86_64 into LFS yet). For a machine
>with only limited memory, I guess building a
>32-bit userspace is probably a lot more
>practical than 64-bit (e.g. the toolchain
>packages build much bigger files on 64-bit
>powerpc than on x86). ĸen -- das eine Mal als
>Tragödie, das andere Mal als Farce --
>http://linuxfromscratch.org/mailman/listinfo/lfs-dev
>FAQ: http://www.linuxfromscratch.org/faq/
>Unsubscribe: See the above information page
--
I've just started the clfs
Version SVN-20081102-PowerPC64-Multilib build
alongside ydl-6 on the ps3 - lets see how it goes...
John
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: libusb and usbutils
At 12:14 29-12-08, you wrote: >We have a problem with libusb and usbutils. > >libusb has released 1.0.0 on 2008-12-13. >usbutils is at version 0.73 released on 2007-10-24. > >usbutils configure wants a function, usb_get_string_simple(), that is not in >libusb-1.0.0. There are functions libusb_get_string_descriptor() and >libusb_get_string_descriptor_ascii() vi in the new libusb. The >second seems to >use the same parameters as usb_get_string_simple(). > >As I see it, there are a few things that we can do. > >1. Just leave out usbutils for now. >2. Revert to the earlier version of libusb. >3. Try to hack usbutils to use the new libusb. Looking at the code, this is >non-trivial and I don't have the time or inclination to do it. >4. Try to install both the old and new versions simultaneously. >5. There is a libusb-compat-0.1 compatibility layer. It aims to >look, feel and >behave exactly like libusb-0.1. As it is a replacement, you cannot install it >alongside libusb-0.1 on the same system. > >There have only been about 4 messages since January in the usbutils >mailing list >(none since September) so it is not very active. Waiting for a new >release may >take a long time. > >The following packages use libusb: > >usbutils >pilot-link >gnome/add/gok >kdeedu >kdebase >gnupg >gnupg2 >sane > >It's unlikely that any use the new libusb. > >Opinions on what to do? I'm leaning toward #5. > >-- Bruce I could be wrong, but I think I took libusb from svn/git/cvs and things compiled OK. John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
"mount --bind" with rootfs
As per Chapter 6.2.2 of SVN-20090401 where the host (tinycorelinux) runs entirely in ram I get this: # mount --bind /dev /mnt/sdc1/dev mount: wrong fs type, bad option, bad superblock on /dev, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so I understand this is something to do with rootfs (the ,dev option is set for sdc1), but cannot find how to get around it - I'd be grateful for any suggestions Thanks, John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: "mount --bind" with rootfs
-Original Message- From: lfs-dev-boun...@linuxfromscratch.org [mailto:lfs-dev-boun...@linuxfromscratch.org] On Behalf Of Ken Moffat Sent: 14 April, 2009 17:30 To: LFS Developers Mailinglist Subject: Re: "mount --bind" with rootfs On Tue, Apr 14, 2009 at 06:52:53AM +0200, John Frankish wrote: > As per Chapter 6.2.2 of SVN-20090401 where the host (tinycorelinux) runs > entirely in ram I get this: > > # mount --bind /dev /mnt/sdc1/dev > mount: wrong fs type, bad option, bad superblock on /dev, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > I understand this is something to do with rootfs (the ,dev option is set for > sdc1), but cannot find how to get around it - I'd be grateful for any > suggestions > > Thanks, John > -- This probably belongs on lfs-support. The only time I saw anything like this (trying to mount ext4, in that case I had to rebuild some things) the explanation was indeed in syslog, so please check what that says. The problem is probably your host system - tinycorelinux is based on busybox. I guess any error message in the syslog will show that the configuration of busybox in tinycorelinux doesn't support the --bind option for mount. ĸen -- Thanks for the feedback In fact I'd replaced busybox mount with the full gnu version so it's not that (but since /tools/bin is already at the front of the path by this stage it would use the version there?). Since posting, I experimented with installing the host (tinycorelinux) as per a "traditional" linux installation, rather than un-packing it to ram on boot and "mount --bind" works in this mode. John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: kernel compression with lzma
-Original Message- From: lfs-dev-boun...@linuxfromscratch.org [mailto:lfs-dev-boun...@linuxfromscratch.org] On Behalf Of Tobias Gasser Sent: 20 June, 2009 04:10 To: LFS Developers Mailinglist Subject: Re: kernel compression with lzma Bruce Dubbs schrieb: > Tobias Gasser wrote: >> kernel 2.26.30 allows compression with gz, bz2 and lzma > >> my current kernel-sizes: >> gzip 1913696 >> bzip21820944 >> lzma 1605712 > > When the smallest disk dive you can get right now is about 160G, does 215K > really make a difference? good argument. (btw: i still can order new 80gb 3.5" or 30gb 2.5", but your argument keeps valid even with a 4gb ssd) but as the kernel maintainers decided to make this option available, i think we should offer the tools to use it. >> i propose to include the xz and not lzma in >> the book to be able to compress the kernel with any method the user >> wishes. > > I would think a more logical place would be BLFS. i don't mind. as the kernel compile does not check wether lzma is possible but just starts compiling resulting in a failure at the very end, i propose at least a hint in the kernel section about not to use lzma unless the corresponding chapter from blfs is done. within the next days i'll rebuild my usb-rescue-stick with a compressed kernel. maybe it will boot a little faster... tobias -- Try tinycorelinux as a usb rescue stick - I have to insert "waitusb" to slow the boot down (and the kernel is gz compressed)... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gcc and "-fomit-frame-pointer"
Ref http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html Just an observation, but compiling gcc-4.6.1 like this, i.e. with "-fomit-frame-pointer" results in a gcc which produces compiled output +/-15% larger (after stripping) than using gcc compiled without "-fomit-frame-pointer" when compiling with CFLAGS="-march=i486 -mtune=i686 -Os -pipe" Note that (per gcc docs) as from gcc-4.6.x, using the optimization -Ox (i.e. -Os, -O2, etc) automatically causes "-fomit-frame-pointer" to be used and the ./configure switch "--enable-frame-pointer" is required to reverse this. I don't know if "-fomit-frame-pointer" produces compiled output that is more efficient (i.e. runs more quickly), but a +/-15% size increase is significant - even the gcc compiled by a gcc without "-fomit-frame-pointer" will be significantly smaller... Regards John -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Latest svn fails to compile gcc pass 1
Using lfs svn-20130320 I get the error below at chapter 5.5. gcc-4.7.2 - pass 1. If I omit "--with-native-system-header-dir=/tools/include", then things fail looking for $LFS/usr/include and if I create $LFS/tools/include, then things fail looking for headers which have not yet been installed to $LFS/tools/include. I would have thought "--without-headers" would have prevented this behavior, but apparently not. Any suggestions would be gratefully received John -- ../gcc-4.7.2/configure --target=$LFS_TGT --prefix=/tools --with-sysroot=$LFS --with-newlibc --without-headers --with-local-prefix=/tools --with-native-system-header-dir=/tools/include --disable-nls --disable-shared --disable-multilib --disable-decimal-float --disable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath --enable-languages=c --with-mpfr-include=$(pwd)/../gcc-4.7.2/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs make ... The directory that should contain system headers does not exist: /mnt/lfs/tools/include make[2]: *** [stmp-fixinc] Error 1 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' make: *** [all] Error 2 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Latest svn fails to compile gcc pass 1
> -Original Message- > From: lfs-dev-boun...@linuxfromscratch.org [mailto:lfs-dev- > boun...@linuxfromscratch.org] On Behalf Of Pierre Labastie > Sent: Monday, 25 March, 2013 17:16 > To: John Frankish; LFS Developers Mailinglist > Subject: Re: [lfs-dev] Latest svn fails to compile gcc pass 1 > > Le 25/03/2013 11:47, John Frankish a écrit : > > -- > > > > ../gcc-4.7.2/configure --target=$LFS_TGT --prefix=/tools --with- > sysroot=$LFS --with-newlibc ... > > > > > The switch is --with-newlib, not newlibc. That is the switch which prevents > the build system to look for the headers dir... > > Regards > Pierre Aaaargh Thanks -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
