Configure: error: cannot compute sizeof (long double)
baho-utot at columbus.rr.com
Sun Jul 15 13:30:34 PDT 2007
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 :)
More information about the lfs-support