On Sunday 15 July 2007 4:06 pm, Ken Moffat wrote: > On Sun, Jul 15, 2007 at 02:09:51PM -0400, Baho Utot wrote: > > It is hard to parse the config.log in glibc-build directory. > > Yes, but it is essential. The last part of it is a dump of all the > variables, which you can probably ignore. Before that, each test in > the configure script typically generates something to say what is > running, some code which you will see, and then command(s) to check > the result, plus the output including errors, and the one-liner that > appears on the screen. > > > It is the only > > file there, there are no others. I would like to know how the test for > > long double works.:u > > Mostly, configure generates some code (you can see it in config.log) > - it will be near the error message. In this case the code is > probably just a call to sizeof(long double). Configure then ompiles > the code and tries to run it. Sizeof uses glibc, and compiling > uses gcc. If it works, you would get a result of something like 12 > or 16 (the number of bytes meeded to hold a long double - it varies > across different architectures). > > > The only thing I see missing is configure looking for crt1.so and > > Scrt1.so. Those are in /tools/lib. > > When a test works as expected, it often fails because something is > not present on a particular platform. In your case, there is a real > problem. You are getting some sort of error message (crt1.so ? is > that a typo for crt1.o ?) - please tell the list what it says.
Yes it was a typo it was crt1.o and Scrt1.o What is it for? I did some C programming many years ago on the doze platform and have some code in Bob Stouts "snippets" I just need to figure out how gcc and company works on Linux :) > > It looks as if glibc is broken, so from here, I _guess_ that > either you went wrong when adjusting the toolchain, or you missed > one of the symlinks, or perhaps you built in stages and something > is linked agaisnt the host's libraries. Ok, I am going to remake the "tools" using "cut, paste and run" from the book. Then I will try again. > > Start by checking each of the symlinks (does the link exists, is it > the right name, does it point to the right destination (beware of > typos), and does the file it points to exist). After that, run > 'readelf -l' against example programs to make sure they are linked > against /tools. > I did check the symlinks and they were right as far as I could tell :) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
