On Mon, Jun 30, 2014 at 04:45:16PM -0700, logical american wrote:
> Some comments while creating the LFS 7.5 system on an openSuse v13.1
> platform, I hope
> they might be usable to others.
>
> 1 In the section Host System Requirements -
>
> The openSuse v13.1 zypper command enables program versions to be found:
>
> Example:
>
> %zypper info bash | grep Version
> Version: 4.2-68.1.5
>
> but the version-check.sh script in LFS 7.5 book is already available.
>
> 2. However the version-check.sh script had to be changed slightly to
> find the libgmp, libmpfr and libmpc libraries, as they
> were under /usr/local/lib* not /usr/lib in openSuse v13.1.
>
If that is true (and I have no reason to doubt you, but it seems
very unlikely - /usr/local is traditionally where the system owner
put things which are not part of the distribution), then it sounds
as if it is broken - recent versions of gcc need them, and things in
/usr should never require things in /usr/local.
> -------------- CHANGED TO ----------------
> for lib in lib{gmp,mpfr,mpc}.la; do
> echo $lib: $(if find /usr/local/lib* -name $lib|
> grep -q $lib;then :;else echo not;fi) found
> done
> unset lib
> -------------------
>
> 3. gmp-6.0.0.tra.lz had to have the lzip package installed on openSuse v13.1
> in order to unzip this type of archive. (to me a recent change)
>
We do not care what hoops you have to jump through to get the host
distro to a suitable state where it can build LFS! The details will
differ for each host distro.
> I choose to try to install gmp-6.0.0 since I use this library very much
> and it installed successfully.
>
I do not have the 7.5 book in front of me at the moment, but that
sounds as if you think it is OK to randomly try newer versions of
packages. Sometimes it is ...
> 4. SPECIAL NOTE: gcc-4.9.0 will NOT install, evidently enough changes have
> occurred between it and gcc-4.8.2 to prevent
> LFS v7.5 from being able to compile this newer package.
>
and at other times it is not. If you are building your _first_ LFS
system (but, reading the end of your mail, I think you are not even
building LFS), it is best to follow the most recent release. Once
you understand how to configure it for your own hardware, and have
decided that you like it, then it is fine to follow the development
book (LFS-svn). Of course now that we have many packages in BLFS,
the preferred route is probably to build enough of BLFS to make the
system useful (either as a desktop or a server, according to
whatever interests you).
The recent versions of LFS-svn are probably reasonably OK in 64-bit
(there are some questions about 32-bit with gcc-4.9.0 : some people
think it is now OK, but very few people seem to have tried it).
> 5. Gawk "make check" failed unexpectedly (to me) with a message seemingly
> indicating that mpfr was not supported by the system, which is not true,
> since it was previously just built.
>
> make[2]: Leaving directory `/lfs/gawk-4.1.0/test'
> ======== Done with shared library tests ========
> ======== Starting MPFR tests ========
> MPFR tests not supported on this system
> ======== Done with MPFR tests ========
> make[2]: Entering directory `/lfs/gawk-4.1.0/test'
> 2 TESTS FAILED
> make[2]: Leaving directory `/lfs/gawk-4.1.0/test'
> make[1]: Leaving directory `/lfs/gawk-4.1.0/test'
>
From what you say later, you seem to still be in chapter 5. At
that point, running the tests is a fool's game : there are many
things on the host system which can cause failure. Even in chroot
when you are only reliant on the new system, there are sometimes
oddities which cause failures only for a few people.
> 6. Texinfo ./configure --prefix=/tools came up with a warning (unexpected to
> me, since ncurses was built)
>
> configure: WARNING: Could not find a terminal library among tinfo ncurses
> curses termlib termcap terminfo
> configure: WARNING: The programs from `info' directory will not be built.
>
No idea if that is normal, and I have no interest : chapter 5 is a
temporary system, the only thing which matters is that it should be
"good enough" to build chapter 6.
> -- End of comments to the LFS v7.5 install.
>
> As to some other comments made upon my previous postings:
>
> I appreciate the comments by both Bruce Dubbs and Christ Staub. Thanks for
> being pointed back to checking the Host System Requirements, which I did
> skip by glancing over the pages, instead of carefully reading them (which I
> did today)
>
> Someone laughed about the mail disclaimer, that actually was from my Windows
> XP laptop which I was using as as Q&D mailout.
That was me - I have no idea what Q&D means (I dare say I could
probably google it), my point was that if you send something like
that to _any_ public mailing list, you lack credibility.
>
> One final question now that I have completed Chapter 5, except for stripping
> off the debug symbols and making the ownership change to root:
>
> Can I use the gcc compiler in the /lfs partition as is? do I simply make a
> user/group change to the folders and construct alias
> to the /tools/bin files?
>
> My original goal was to have a native C and C++ compiler for the corei7
> hardware.
>
If you only wanted to build a different version of gcc (and,
ideally, a suitable version of binutils) then /usr/local would have
been a better place to put them.
The LFS book is about building a completely new system, which you
then boot. For many people (me included!), what is in LFS is
insufficient for a usable system, but that depends on what you want
to do with it.
The mention of "a native compiler for the core i7" does not mean
much to me - i7 processors can run both 32-bit (i686, but also code
only optimised for much older processors) and 64-bit (x86_64).
Also, I think that intel have "re-used" the iN names - I have a
Sandy Bridge i3 (I think, but maybe it is an i5), but the current
model seems to be Haswell. Whatever, the one place where
optimisations for a processor family are important is probably the
linux kernel - and for that you do not need a specific compiler.
The things which make a compiled program specific to a particular
processor (or, likely to run slower on other processors) are the
options you pass, such as -mtune or -mcpu. In the past, I used an
AMD K6-2 and would have given the proverbial for a way of getting it
to run things faster. But with modern high-end processors there is
often little to gain. Back in the day, gentoo users used to have
all manner of weird and wonderful gcc optimisations. The Americans
tended to refer to them as "ricers" - for those of us in GB I guess
that sort of translates as "boy racers". I have nothing against
using specific optimisations, but as they say - "when it breaks, you
get to keep both pieces". But, it is your system, and your time, so
"your rules" and "do what thou wilt".
ĸen
--
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
