Re: Recent toolchain breakage
Matthew Burgess wrote: /tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../../i686-pc-linux-gnu/bin/ld: Sorry for the noise if this is my own doing, but the above line caught my eye. I just finished building the latest svn and noticed much the same after installing GCC in ch6. Running the sanity tests up to that point worked as expected, so I figured everything was ok, but the sanity check in 6.13 (re-adjusting the toolchain) failed-ish. I get the 'Requesting program interpreter: /lib/ld-linux.so.2,' 'attempt to open /lib/libc.so.6 succeeded,' and 'found ld-linux.so.2 at /lib/ld-linux.so.2' lines but not the 'attempt to open /usr/lib/crt?.o succeeded' lines. If I change the grep to '/crt*.o' it shows something like this IIRC: /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../crt1.o succeeded I also ended up with multiple copies of the compilers (not symlinked) as in: g++ i686-pc-linux-gnu-g++ (IIRC, there were 3 variants for g++ all the same size, a couple gcc, ..) I assume neither the presence of /../../../ nor the additional compilers is really a problem, I've just never noticed them before. The /../../../ certainly isn't necessary and I wouldn't think the multiple copies are either. When I stumbled upon this in the final ch6 sanity check, I figured I made a typeo and started over, but I got the same result again. All the other toolchain package tests pass as expected. Any idea what I might have done wrong to get this? Thanks, Jeremy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Recent toolchain breakage
Dan Nicholson wrote:
On 2/18/06, Jeremy Byron <[EMAIL PROTECTED]> wrote:
I get the 'Requesting program interpreter: /lib/ld-linux.so.2,' 'attempt
to open /lib/libc.so.6 succeeded,' and 'found ld-linux.so.2 at
/lib/ld-linux.so.2' lines but not the 'attempt to open /usr/lib/crt?.o
succeeded' lines.
If I change the grep to '/crt*.o' it shows something like this IIRC:
/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../crt1.o succeeded
This is after you install the final gcc or before? Because it will
only say /usr/lib/crt1.o between the time you add /usr/lib/ to
*startfile_prefix_spec till you build the final gcc. This is the
normal path for the final gcc to find the glibc startfiles.
After. If this is normal then no worries. Might want to fix the sanity
check in the book to account for this though.
I also ended up with multiple copies of the compilers (not symlinked) as in:
g++
i686-pc-linux-gnu-g++
(IIRC, there were 3 variants for g++ all the same size, a couple gcc, ..)
That seems normal to me. On my current system I have
$ ls -l /usr/bin/*{c,g}++
-rwxr-xr-x 4 root root 81144 2005-11-04 10:54 /usr/bin/c++
-rwxr-xr-x 4 root root 81144 2005-11-04 10:54 /usr/bin/g++
-rwxr-xr-x 4 root root 81144 2005-11-04 10:54 /usr/bin/i686-pc-linux-gnu-c++
-rwxr-xr-x 4 root root 81144 2005-11-04 10:54 /usr/bin/i686-pc-linux-gnu-g++
Nice to know; must have just never taken notice of them.
Thanks,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Glibc-2.3.6 sys/kd.h patch
DJ Lucas wrote:
> The glibc version in current LFS causes a build failure when compiling
> xorg-6.9 and xorg-server-1.0.{1,2}. linux/types.h cannot be included
> after sys/kd.h. The glibc-2.3.6-linux_types-1.patch just committed to
>
> http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.3.6-linux_types-1.patch
Works for me with xorg-6.9 on an SVN-20060210 build.
Regards,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: User lfs is more than optional.
William Zhou wrote:
One of my friend started LFS several days ago and got an error when
adjusting the toolchain( 5.7 ). The problem was that the gcc specs path
was pointed to the host's one. It took me me a while to figure out that
he ignored the creation of user lfs and thus the ~/.bashrc is not created.
The PATH enviourment does not even includes /tools/bin.
The creation of ~/.bashrc is independend of whether or not you create
the lfs user. It's even on a different page. What you're saying is
that your friend simply disregarded a section of the book.
Most of us follows the book's recommendation and never had this problem.
But I believe the creation of LFS should be stated to be mandatory, or at
least make this clear.
It is stated as recommended, which essentially translates to 'follow
this recommendation or any problems are your own.' This just adds
support to FBBG.
2. set +h search for commands every time
Wait, so instead of setting it once, I can set it dozens of times? I
think not, though you're welcome to deviate as you wish. ('Your distro
your rules' and all..)
3. Get rid of useless environment variables using the method in
~/.bash_profile.
( exec env -i HOME=$HOME TERM=$TERM PS1='...' /bin/bash )
These are useless? Huh. Strange how the LFS devs would add useless book
content. They should be ashamed of themselves. ;)
4. LFS environment variable. (Not so important).
Sure it is; it lets you set the location once and not have to type it in
again and again. More importantly, it allows the book to be written
with generic instructions that can be used regardless of where you
choose to build your shiny new lfs. Not everybody (myself included)
builds it in /mnt/lfs. (I build the new lfs in the home partition so I
can test it first, then overwrite my old lfs with it when it's useable.
I really must get another hard drive.. sigh.) As soon as somebody
deviates from /mnt/lfs (if that's what the book used instead of $LFS),
(s)he could no longer just cut and paste all of the instructions.
Regards,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: User lfs is more than optional.
Emu wrote: I think that you have mis-understood William's email. From his email, I gather that he means that the commands set in 1 through 3 should be stated as 'Compulsory', ie if not used then you have a good chance of > I think as Linux becomes more mainstream, more people are going to try > LFS for the first time and some people don't know (or understand or even > don't realise) that a recommendation in the LFS book is something that > you should do to prevent troubles occurring down the line. Not at all.. as I said, 'recommended' essentially means 'compulsory' or at least 'deal with your own problems if something goes wrong by not following the recommendations.' That's implied in the definition of recommended as far as I'm concerned. This is true for anything where there is a recommended action. If I were to recommend you not jumping out of an airplane from 30,000 feet without a parachute, I'm pretty sure you'll accept that as a compulsory action. If you choose not listen, the fact that you become flying goo when you hit the ground is your own damn fault. But hey, if you can learn to fly on your way down, that's great; write a hint for the rest of us. ;) The point is, the *LFS maintainers cannot be held accountable for people who cannot follow instructions. The instructions are there and, for those who read them, they work. Jeremy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: module-init-tools-3.2.1
Matthew Burgess wrote: Hi folks, There's a minor issue with the Makefile in this version. Essentially, if one uses the current '--prefix=""' then the following ends up in the logs: /bin/sh: line 0: [: =: unary operator expected That's caused by: Makefile:71: if [ $(prefix) = / ] In this case, $(prefix) will obviously = "", hence the test doesn't get a condition on the left-hand side. Additionally, that test failing results in the manpages being installed to /share/man instead of /usr/share/man. Now, we can fix this in a couple of ways: 3) Change the Makefile to do the following test instead: if [ "$(prefix)" = / -o "$(prefix)" = "" ]; > This should still give the 'unary operator expected' message, I would think. In order to protect against '"$(prefix)" = /' failing, don't you need to test the null case first? if [ "$(prefix)" = "" -o "$(prefix)" = / ]; This way, assuming sh skips further OR cases when the first succeeds (as it should), you won't get the above error because '"$(prefix)" = /' is never reached. I've never really looked into sh scripting, so I'm not certain this applies, but it's something for you to consider. In any case, I think going directly to option 3 is the best route. Regards, Jeremy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
OOo2 Build Instructions Gimped
I tried building OOo2 again using the instructions in the book seeing as people are saying they have successful builds, but I don't see how they could without a lot of monkeying on their own. The bsh download is "..b4-src.tar.bz2" but the copy and decompression command references "..b4.tar.bz2" and the build system requires "..b4-src.tar.gz". And why do you decompress it? I thought the build scripts did that in the appropriate locations; I never decompressed it when I was building OOo2 before. I submitted a patch a while back (most of which looks like it has been cleaned out) that removed erroneous optimizations in the code but you still have the sed in the book for unxlngi6.mk. There are a few files that have this problem and unxlngi6.mk is no longer one of them so the sed doesn't do anything. You'll have to run a "grep -lr 'mtune'" and "grep -lr 'mcpu'" to find them, I didn't make a patch. There is no mention in the dependencies about Gnome-vfs but the build requires it unless --disable-gnome-vfs is added to the configure. Under the latest SVNs, tcsh is gimped such that the bootstrap command fails unless you 'unset LS_COLORS'. Using the instructions to swap in --with-system-mozilla (with an added --with-firefox) to use the firefox ldap, the build fails as before. Why isn't David's libsec patch in the book? It seems retarded to build a full mozilla suite just to have an office suite, especially when a browser is already on the system. Regards, Jeremy. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OOo2 Build Instructions Gimped
Jeremy Byron wrote:
still have the sed in the book for unxlngi6.mk. There are a few files
that have this problem and unxlngi6.mk is no longer one of them so the
Sorry, my bad.. unxlngi6.mk still has the problem but so does a few
other files. No point fixing one and not the others and, unless you can
do a crazy sed one-liner it'd be easier to just drop another patch into
the loop.
Affected files:
solenv/inc/unxlngi{4,5,6}.mk
solenv/inc/unxfbsdi.mk
Regards,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
