Configure: error: cannot compute sizeof (long double)

Baho Utot 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 mailing list