vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[meres5]

Hi out there,

I build the latest musl under

meres5@alpha:~/tmp$ uname -a
Linux alpha 2.6.32-5-powerpc64 #1 SMP Mon Oct 3 07:59:38 UTC 2011 ppc64
GNU/Linux

and got

meres5@alpha:~/tmp$ ld -o stdhello.static lib/crt1.o lib/crti.o stdhello.o
lib/libc.a lib/libgcc.a lib/crtn.o
lib/libc.a(vfprintf.o): In function `printf_core':
vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'
vfprintf.c:(.text+0xccc): undefined reference to `__fpclassifyl'

by linking static against musl a Hello sample.
I think this is not good. . .

I push on gcc with theese:

int __signbitl( long double x ) { return 0;}
int __fpclassifyl( long double x ) { return 0;}

then it worked fine - for this simple Hello :-)

Someone might have a look at math.h, and implement these
for this arch. . .

Regards
M5

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Szabolcs Nagy]

* meres5@alpha.tmit.bme.hu <meres5@alpha.tmit.bme.hu> [2013-04-08 21:39:19 +0200]:
> 
> meres5@alpha:~/tmp$ uname -a
> Linux alpha 2.6.32-5-powerpc64 #1 SMP Mon Oct 3 07:59:38 UTC 2011 ppc64
> GNU/Linux

what is the long double on your platform? i assume it's 128bit

gcc -dM -E - </dev/null |grep LDBL_

> meres5@alpha:~/tmp$ ld -o stdhello.static lib/crt1.o lib/crti.o stdhello.o
> lib/libc.a lib/libgcc.a lib/crtn.o
> lib/libc.a(vfprintf.o): In function `printf_core':
> vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'
> vfprintf.c:(.text+0xccc): undefined reference to `__fpclassifyl'
> 
> by linking static against musl a Hello sample.
> I think this is not good. . .

the problem is that various functions use the signbit macro
from math.h

it gets the sign bit with bithacks for float and double and
calls __signbitl for long double

but the __signbitl call should only be generated by the compiler
if sizeof(long double) != sizeof(double)

in that case we only support the 80bit long double of x86

(powerpc long double can be 64bit, 128bit ieee or 128bit ibm
and we only support 64bit at this point, the others are
soft-float emulations anyway so not very useful, but that's
the standard abi so many toolchains use that..)

> I push on gcc with theese:
> 
> int __signbitl( long double x ) { return 0;}
> int __fpclassifyl( long double x ) { return 0;}
> 
> then it worked fine - for this simple Hello :-)

it might make sense to add these so code will
"happen to work" if it does not use long double

(note that printf uses long double internally
to print floats but it may even work with
float and doubles but it will definitly fail to
print long doubles)

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Rich Felker]

On Mon, Apr 08, 2013 at 09:39:19PM +0200, meres5@alpha.tmit.bme.hu wrote:
> Hi out there,
> 
> I build the latest musl under
> 
> meres5@alpha:~/tmp$ uname -a
> Linux alpha 2.6.32-5-powerpc64 #1 SMP Mon Oct 3 07:59:38 UTC 2011 ppc64
> GNU/Linux

On powerpc, musl uses the old long-double ABI where long double is the
same as double. It sounds like your gcc was built for 128-bit long
double, which is completely soft-float. For some reason the GCC and
glibc folks decided this would be a smart thing to do, despite the
fact that it's very slow and forces you to link a lot of soft-float
bloat into every single program (I guess they don't care because they
only do dynamic linking...?).

Anyway, there may be a way to override this on the gcc command line,
but the best solution would be to rebuild your gcc toolchain to use
64-bit long-double (same as double).

Rich

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[meres5]

Well,

> what is the long double on your platform? i assume it's 128bit
>
> gcc -dM -E - </dev/null |grep LDBL_

meres5@alpha:~/src/eglibc/ports$ gcc -dM -E - </dev/null |grep LDBL_
#define __LDBL_MAX__ 1.79769313486231580793728971405301e+308L
#define __LDBL_MAX_EXP__ 1024
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_MIN__ 2.00416836000897277799610805135016e-292L
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L
#define __LDBL_MANT_DIG__ 106
#define __LDBL_MIN_EXP__ (-968)
#define __LDBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.94065645841246544176568792868221e-324L
#define __LDBL_MIN_10_EXP__ (-291)
#define __LDBL_DIG__ 31

seems . . .

>> lib/libc.a(vfprintf.o): In function `printf_core':
>> vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'
>> vfprintf.c:(.text+0xccc): undefined reference to `__fpclassifyl'
>>
>> by linking static against musl a Hello sample.
>> I think this is not good. . .
>
> the problem is that various functions use the signbit macro
> from math.h

Yep.

> it gets the sign bit with bithacks for float and double and
> calls __signbitl for long double
>
> but the __signbitl call should only be generated by the compiler
> if sizeof(long double) != sizeof(double)
>
> in that case we only support the 80bit long double of x86
>
> (powerpc long double can be 64bit, 128bit ieee or 128bit ibm
> and we only support 64bit at this point, the others are
> soft-float emulations anyway so not very useful, but that's
> the standard abi so many toolchains use that..)

I won't like to descend so deep.
I've just like to demo the difference between static and
dynamic linking to our students, and came up here - LOL!

Anyway, it's been 19 years passed, so my guide seemed not so
durable.
Also Linux dropped the concept of static linking in practivce.
Goodby kiss to

$ ld -o stdhello /lib/crt0.o stdhello.o -lc

> it might make sense to add these so code will
> "happen to work" if it does not use long double
>
> (note that printf uses long double internally
> to print floats but it may even work with
> float and doubles but it will definitly fail to
> print long doubles)

Thanks. . . I check out some more static libs for gcc.
I have just tried to build eglibc:

cc1: error: unrecognized command line option "-mno-vsx"
make[2]: *** [/home/meres5/src/eglibc/ports/gmon/mcount.o] Error 1

:-)
All about
./configure --prefix=. . . . .
make
make install

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[meres5]

That's a string to pull.
I've stucked with EGLIBC too, but

make ARCH=ppc64 "CC=gcc -m64"

tossed forward until got

cc1: error: unrecognized command line option "-mno-vsx"
make[2]: *** [/home/meres5/src/eglibc/ports/gmon/mcount.o] Error 1

Why is so painful to say no to a nonexistent thing?
LOL again.
Facing interesting hours though...

> On Mon, Apr 08, 2013 at 09:39:19PM +0200, meres5@alpha.tmit.bme.hu wrote:
>> Hi out there,
>>
>> I build the latest musl under
>>
>> meres5@alpha:~/tmp$ uname -a
>> Linux alpha 2.6.32-5-powerpc64 #1 SMP Mon Oct 3 07:59:38 UTC 2011 ppc64
>> GNU/Linux
>
> On powerpc, musl uses the old long-double ABI where long double is the
> same as double. It sounds like your gcc was built for 128-bit long
> double, which is completely soft-float. For some reason the GCC and
> glibc folks decided this would be a smart thing to do, despite the
> fact that it's very slow and forces you to link a lot of soft-float
> bloat into every single program (I guess they don't care because they
> only do dynamic linking...?).
>
> Anyway, there may be a way to override this on the gcc command line,
> but the best solution would be to rebuild your gcc toolchain to use
> 64-bit long-double (same as double).
>
> Rich
>

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Szabolcs Nagy]

* meres5@alpha.tmit.bme.hu <meres5@alpha.tmit.bme.hu> [2013-04-08 22:41:28 +0200]:
> >
> > gcc -dM -E - </dev/null |grep LDBL_
> 
> meres5@alpha:~/src/eglibc/ports$ gcc -dM -E - </dev/null |grep LDBL_
> #define __LDBL_MAX__ 1.79769313486231580793728971405301e+308L
> #define __LDBL_MAX_EXP__ 1024
> #define __LDBL_HAS_INFINITY__ 1
> #define __LDBL_MIN__ 2.00416836000897277799610805135016e-292L
> #define __LDBL_HAS_QUIET_NAN__ 1
> #define __LDBL_HAS_DENORM__ 1
> #define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L
> #define __LDBL_MANT_DIG__ 106

this is bad, it is 'double-double' long double format
which means broken long double arithmetics

> #define __LDBL_MIN_EXP__ (-968)
> #define __LDBL_MAX_10_EXP__ 308
> #define __LDBL_DENORM_MIN__ 4.94065645841246544176568792868221e-324L
> #define __LDBL_MIN_10_EXP__ (-291)
> #define __LDBL_DIG__ 31
> 

> I won't like to descend so deep.
> I've just like to demo the difference between static and
> dynamic linking to our students, and came up here - LOL!

if you want to play with static linking then it's better
not to use soft-float long double, that ruins it a lot

(every trivial program will get an entire floating point
emulation library linked in from libgcc pulled in by printf
so the students will get the impression that static linking
always gives bloated binaries..)

the correct thing to do is to build a toolchain with 64bit
long double

> Anyway, it's been 19 years passed, so my guide seemed not so
> durable.
> Also Linux dropped the concept of static linking in practivce.
> Goodby kiss to

linux did not drop it, but for some reason the glibc and
binutils maintainers thought that dynamic linking is always
better so it's enough to support that

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[meres5]

Hi!

I have good, and bad news concerning this issue!

>
> this is bad, it is 'double-double' long double format
> which means broken long double arithmetics
>

Its the out of the box debian, installed on our
old IBM eServer pSeries 615 (7029 6C3).
Surprisingly a native PPC host/target/and everything. . .

> if you want to play with static linking then it's better
> not to use soft-float long double, that ruins it a lot

Well, we won't made any REAL (floating point) thing on this
old machine. Performance is not an issue here.

> (every trivial program will get an entire floating point
> emulation library linked in from libgcc pulled in by printf
> so the students will get the impression that static linking
> always gives bloated binaries..)

The picture is not that bad.
Finally I managed to unleash the two functions in question
in ~/src/musl-0.9.9/src/math: __signbitl and __fpclassifyl with some
#if bombing and voilla!

root@alpha:/home/meres5/tmp# ld crt1.o stdhello.o -L. -lc -lgcc -o stdhello
root@alpha:/home/meres5/tmp# chroot . ./stdhello
Hello

worked and its 'only' 25k.

> the correct thing to do is to build a toolchain with 64bit
> long double

I won't touch the Debian tool chain. . .
We are on PPC and not cross compiling for PSP3 :-)

>> Anyway, it's been 19 years passed, so my guide seemed not so
>> durable.
>> Also Linux dropped the concept of static linking in practivce.
>> Goodby kiss to
>
> linux did not drop it, but for some reason the glibc and
> binutils maintainers thought that dynamic linking is always
> better so it's enough to support that
Yep.
Finally I got it - thanks for the MUSL team!

And the good news:
 - worked
 - I have checked several other libc for embedded, supporting static ld
   and only musl prevails with some really little hack in source.
   Others claimed broken tool-chain (by being surprised not in a
   cross compling toolchain)

Bad news:
 - Someone had better to have a look at those conditionals in
   __signbitl.c and __fpclassifyl.c

Regards
m5

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Szabolcs Nagy]

* meres5@alpha.tmit.bme.hu <meres5@alpha.tmit.bme.hu> [2013-04-09 22:15:40 +0200]:
> > this is bad, it is 'double-double' long double format
> > which means broken long double arithmetics
> >
> 
> Its the out of the box debian, installed on our
> old IBM eServer pSeries 615 (7029 6C3).
> Surprisingly a native PPC host/target/and everything. . .

yes, double-double is also called the 128bit ibm format
and it used to be defined this way in the powerpc abi
(recently gcc changed to the 128bit ieee format if i
understood the libgcc code correctly)

> > (every trivial program will get an entire floating point
> > emulation library linked in from libgcc pulled in by printf
> > so the students will get the impression that static linking
> > always gives bloated binaries..)
> 
> The picture is not that bad.
> Finally I managed to unleash the two functions in question
> in ~/src/musl-0.9.9/src/math: __signbitl and __fpclassifyl with some
> #if bombing and voilla!
> 
> root@alpha:/home/meres5/tmp# ld crt1.o stdhello.o -L. -lc -lgcc -o stdhello
> root@alpha:/home/meres5/tmp# chroot . ./stdhello
> Hello
> 
> worked and its 'only' 25k.

nice

> > linux did not drop it, but for some reason the glibc and
> > binutils maintainers thought that dynamic linking is always
> > better so it's enough to support that
> Yep.
> Finally I got it - thanks for the MUSL team!
> 
> And the good news:
>  - worked
>  - I have checked several other libc for embedded, supporting static ld
>    and only musl prevails with some really little hack in source.
>    Others claimed broken tool-chain (by being surprised not in a
>    cross compling toolchain)

i'm glad it worked

> Bad news:
>  - Someone had better to have a look at those conditionals in
>    __signbitl.c and __fpclassifyl.c

adding support for a new long double representation
is non-trivial

but you are right that code without floating-point
should work even on systems with weird long double

i will look into that later

meanwhile on powerpc gcc has -mlong-double-64 option
to compile with 64bit long doubles, maybe the musl
config script should check for that and add it when
the long double format is unsupported

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Rich Felker]

On Tue, Apr 09, 2013 at 10:15:40PM +0200, meres5@alpha.tmit.bme.hu wrote:
> Hi!
> 
> I have good, and bad news concerning this issue!
> 
> >
> > this is bad, it is 'double-double' long double format
> > which means broken long double arithmetics
> >
> 
> Its the out of the box debian, installed on our
> old IBM eServer pSeries 615 (7029 6C3).
> Surprisingly a native PPC host/target/and everything. . .
> 
> > if you want to play with static linking then it's better
> > not to use soft-float long double, that ruins it a lot
> 
> Well, we won't made any REAL (floating point) thing on this
> old machine. Performance is not an issue here.
> 
> > (every trivial program will get an entire floating point
> > emulation library linked in from libgcc pulled in by printf
> > so the students will get the impression that static linking
> > always gives bloated binaries..)
> 
> The picture is not that bad.
> Finally I managed to unleash the two functions in question
> in ~/src/musl-0.9.9/src/math: __signbitl and __fpclassifyl with some
> #if bombing and voilla!

Just providing those functions does not mean "it worked". Important
floating point code in musl, including printf, scanf, and strtod,
assumes that long double arithmetic conforms to IEEE requirements. IBM
double-double format does not, and it will result in seriously broken
behavior, at least incorrect processing of floating point values, but
possibly even including infinite loops or crashing. You should not try
to hack in support for double-double unless you really know what
you're doing, and even then it's a bad idea.

If on the other hand your toolchain is using IEEE quad precision
128-bit long-double, then these functions should work fine, and your
only problem will be insufficient precision in the long-double math
library and a few other broken functions.

Rich

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Rob Landley]

On 04/08/2013 03:41:28 PM, meres5@alpha.tmit.bme.hu wrote:
> Also Linux dropped the concept of static linking in practivce.
> Goodby kiss to

No it didn't. Ulrich Drepper, the ex-glibc maintainer, had a personal  
grudge against static linking. But the community did one of this  
gcc->egcs things and abandoned glibc in droves for eglibc until Ulrich  
bogged off to The Bank of Evil (Goldman Sachs), and now less crazy  
people are in charge of glibc.

It's going to take a while for the damage to work its way through, and  
in the meantime smartphones are replacing the PC and kicking it up into  
the server space like minicomputers and mainframes before it. (This  
time the marketing people are calling this process "the cloud" and  
trying to make "big iron is still lucrative" sound exciting.)

So far the smartphone has no use for glibc (android forbids GPL code in  
userspace, and since the GPLv2/GPLv3 split means there's no "the GPL"  
anymore to the point Linux and Samba can't share code desite  
implementing two ends of the same protocol, nobody's fighting very hard  
on behalf of the fragmented rubble of copyleft).

Some of us are trying to position musl as an upgrade/replacement to  
bionic. That targets a niche with a billion deployed seats and 4x  
growth potential, as opposed to a niche with 300 million deployed seats  
(most of which are windows) that's already peaked.

So don't write of static linking just yet. :)

Rob

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Rich Felker]

On Wed, Apr 10, 2013 at 12:14:13AM -0500, Rob Landley wrote:
> On 04/08/2013 03:41:28 PM, meres5@alpha.tmit.bme.hu wrote:
> >Also Linux dropped the concept of static linking in practivce.
> >Goodby kiss to
> 
> No it didn't. Ulrich Drepper, the ex-glibc maintainer, had a
> personal grudge against static linking. But the community did one of
> this gcc->egcs things and abandoned glibc in droves for eglibc until
> Ulrich bogged off to The Bank of Evil (Goldman Sachs), and now less
> crazy people are in charge of glibc.

To set the record straight, the current glibc maintainership considers
static linking supported. I don't have the citations right off, but
there have been several threads in which issues of current breakage
with static linking, or avoiding future breakage, came up, and each
time the position seems to have been that static linking is supported.
I could probably dig them up if anybody's interested.

Rich

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[John Spencer]

On 04/09/2013 10:15 PM, meres5@alpha.tmit.bme.hu wrote:
>
>> the correct thing to do is to build a toolchain with 64bit
>> long double
> I won't touch the Debian tool chain. . .
> We are on PPC and not cross compiling for PSP3 :-)

nobody says that you should mess with your debian toolchain.

but you should build a properly configured, musl-agnostic toolchain so 
that the binaries you produce don't work by luck only.
(using a different prefix so everything is safely kept away from your 
debian TC)

as a reference you can either look at the musl-cross project (you can 
probably even compile that straight on ppc without changes)
or use the sabotage build scripts. see the musl wiki for links to these 
projects.

even better, you could just get the sabotage powerpc rootfs, extract it 
into a temporary directory and use the included native gcc 4.5.4 (it's 
in /opt/gcc4 inside the rootfs).
http://mirror.wzff.de/sabotage/sabotage-0.9.8-powerpc-rootfs.tar.xz -> 
150 MB
be sure to unpack inside a newly created temp dir.


>
> Bad news:
>   - Someone had better to have a look at those conditionals in
>     __signbitl.c and __fpclassifyl.c

no, we do not intend to support broken configurations that produce 
broken code.

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Szabolcs Nagy]

* John Spencer <maillist-musl@barfooze.de> [2013-04-10 10:24:10 +0200]:
> On 04/09/2013 10:15 PM, meres5@alpha.tmit.bme.hu wrote:
> >
> >>the correct thing to do is to build a toolchain with 64bit
> >>long double
> >I won't touch the Debian tool chain. . .
> >We are on PPC and not cross compiling for PSP3 :-)
> 
> nobody says that you should mess with your debian toolchain.
> 
> but you should build a properly configured, musl-agnostic toolchain
> so that the binaries you produce don't work by luck only.
> (using a different prefix so everything is safely kept away from
> your debian TC)
> 

for serious usage that's the right thing to do

but it may be overkill to require a complete toolchain
when someone just wants to try out musl

> >Bad news:
> >  - Someone had better to have a look at those conditionals in
> >    __signbitl.c and __fpclassifyl.c
> 
> no, we do not intend to support broken configurations that produce
> broken code.

i was thinking that it should be possible to support the
case when the powerpc toolchain is double-double but the
user guarantees that no long double arithmetics is used

(ie we only need to fix the internal long double usage so
double inputs are handled correctly)

although it's probably easier to just add -mlong-double=64
during the musl build

the unsupported format can be detected in the configure
script (the user will have to use -mlong-double=64
consistently then though, but we can add it to the musl-gcc
wrapper as well)

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[meres5]

Hi All!

Thanks for reflections, and the story!
Yep, the rabbit holes used to be way deeeep.

I do not meant to "use" broken code, just show it,
and I did not posted my hack for good reason.

My goal is run a set of tools to produce an executable and
objdump it to show what is what here and there, static/dynamic.
It's just a fun that it can say "Hello" when we run it,
and not segfault - that will be enforced later...  :-)

Sorry to act as a noob, but I slept through the last
decades doing hardware, IP cores, and some firmware.
Back to work -

Regards
M5

p.s.
Still...

./configure . . .
make
make install

should work fine on a popular distro.
Shouldn't?

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Isaac Dunham]

On Wed, 10 Apr 2013 11:47:54 +0200
Szabolcs Nagy <nsz@port70.net> wrote:

> although it's probably easier to just add -mlong-double=64
> during the musl build
> 
> the unsupported format can be detected in the configure
> script (the user will have to use -mlong-double=64
> consistently then though, but we can add it to the musl-gcc
> wrapper as well)

Are the gcc startup files sensitive to this?
If not, this seems desireable (I would put it in the specs file, but that's a pretty trivial difference).

-- 
Isaac Dunham <idunham@lavabit.com>

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Rich Felker]

On Wed, Apr 10, 2013 at 07:14:44AM -0700, Isaac Dunham wrote:
> On Wed, 10 Apr 2013 11:47:54 +0200
> Szabolcs Nagy <nsz@port70.net> wrote:
> 
> > although it's probably easier to just add -mlong-double=64
> > during the musl build
> > 
> > the unsupported format can be detected in the configure
> > script (the user will have to use -mlong-double=64
> > consistently then though, but we can add it to the musl-gcc
> > wrapper as well)
> 
> Are the gcc startup files sensitive to this?
> If not, this seems desireable (I would put it in the specs file, but that's a pretty trivial difference).

It should not affect them. We'd just need to add code to configure and
the Makefile to generate extra arch-specific stuff for addition into
the specfile..

Rich

Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl'

[Justin Cormack]

On Wed, Apr 10, 2013 at 3:31 PM, Rich Felker <dalias@aerifal.cx> wrote:
> It should not affect them. We'd just need to add code to configure and
> the Makefile to generate extra arch-specific stuff for addition into
> the specfile..
>
> Rich

I just ran into this again (lack of -mlong-double-64 on ppc)...

Justin