* vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' @ 2013-04-08 19:39 meres5 2013-04-08 20:05 ` Szabolcs Nagy 2013-04-08 20:09 ` Rich Felker 0 siblings, 2 replies; 17+ messages in thread From: meres5 @ 2013-04-08 19:39 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 19:39 vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' meres5 @ 2013-04-08 20:05 ` Szabolcs Nagy 2013-04-08 20:41 ` meres5 2013-04-08 20:09 ` Rich Felker 1 sibling, 1 reply; 17+ messages in thread From: Szabolcs Nagy @ 2013-04-08 20:05 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 20:05 ` Szabolcs Nagy @ 2013-04-08 20:41 ` meres5 2013-04-08 21:26 ` Szabolcs Nagy 2013-04-10 5:14 ` Rob Landley 0 siblings, 2 replies; 17+ messages in thread From: meres5 @ 2013-04-08 20:41 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 20:41 ` meres5 @ 2013-04-08 21:26 ` Szabolcs Nagy 2013-04-09 20:15 ` meres5 2013-04-10 5:14 ` Rob Landley 1 sibling, 1 reply; 17+ messages in thread From: Szabolcs Nagy @ 2013-04-08 21:26 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 21:26 ` Szabolcs Nagy @ 2013-04-09 20:15 ` meres5 2013-04-09 22:38 ` Szabolcs Nagy ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: meres5 @ 2013-04-09 20:15 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-09 20:15 ` meres5 @ 2013-04-09 22:38 ` Szabolcs Nagy 2013-04-10 1:18 ` Rich Felker 2013-04-10 8:24 ` John Spencer 2 siblings, 0 replies; 17+ messages in thread From: Szabolcs Nagy @ 2013-04-09 22:38 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-09 20:15 ` meres5 2013-04-09 22:38 ` Szabolcs Nagy @ 2013-04-10 1:18 ` Rich Felker 2013-04-10 10:55 ` meres5 2013-04-10 8:24 ` John Spencer 2 siblings, 1 reply; 17+ messages in thread From: Rich Felker @ 2013-04-10 1:18 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 1:18 ` Rich Felker @ 2013-04-10 10:55 ` meres5 0 siblings, 0 replies; 17+ messages in thread From: meres5 @ 2013-04-10 10:55 UTC (permalink / raw) To: musl 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-09 20:15 ` meres5 2013-04-09 22:38 ` Szabolcs Nagy 2013-04-10 1:18 ` Rich Felker @ 2013-04-10 8:24 ` John Spencer 2013-04-10 9:47 ` Szabolcs Nagy 2 siblings, 1 reply; 17+ messages in thread From: John Spencer @ 2013-04-10 8:24 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 8:24 ` John Spencer @ 2013-04-10 9:47 ` Szabolcs Nagy 2013-04-10 14:14 ` Isaac Dunham 0 siblings, 1 reply; 17+ messages in thread From: Szabolcs Nagy @ 2013-04-10 9:47 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 9:47 ` Szabolcs Nagy @ 2013-04-10 14:14 ` Isaac Dunham 2013-04-10 14:31 ` Rich Felker 0 siblings, 1 reply; 17+ messages in thread From: Isaac Dunham @ 2013-04-10 14:14 UTC (permalink / raw) To: musl 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 14:14 ` Isaac Dunham @ 2013-04-10 14:31 ` Rich Felker 2013-08-11 21:30 ` Justin Cormack 0 siblings, 1 reply; 17+ messages in thread From: Rich Felker @ 2013-04-10 14:31 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 14:31 ` Rich Felker @ 2013-08-11 21:30 ` Justin Cormack 0 siblings, 0 replies; 17+ messages in thread From: Justin Cormack @ 2013-08-11 21:30 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 20:41 ` meres5 2013-04-08 21:26 ` Szabolcs Nagy @ 2013-04-10 5:14 ` Rob Landley 2013-04-10 6:21 ` Rich Felker 1 sibling, 1 reply; 17+ messages in thread From: Rob Landley @ 2013-04-10 5:14 UTC (permalink / raw) To: musl; +Cc: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-10 5:14 ` Rob Landley @ 2013-04-10 6:21 ` Rich Felker 0 siblings, 0 replies; 17+ messages in thread From: Rich Felker @ 2013-04-10 6:21 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 19:39 vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' meres5 2013-04-08 20:05 ` Szabolcs Nagy @ 2013-04-08 20:09 ` Rich Felker 2013-04-08 20:47 ` meres5 1 sibling, 1 reply; 17+ messages in thread From: Rich Felker @ 2013-04-08 20:09 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' 2013-04-08 20:09 ` Rich Felker @ 2013-04-08 20:47 ` meres5 0 siblings, 0 replies; 17+ messages in thread From: meres5 @ 2013-04-08 20:47 UTC (permalink / raw) To: musl 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-08-11 21:30 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-08 19:39 vfprintf.c:(.text+0xc6c): undefined reference to `__signbitl' meres5 2013-04-08 20:05 ` Szabolcs Nagy 2013-04-08 20:41 ` meres5 2013-04-08 21:26 ` Szabolcs Nagy 2013-04-09 20:15 ` meres5 2013-04-09 22:38 ` Szabolcs Nagy 2013-04-10 1:18 ` Rich Felker 2013-04-10 10:55 ` meres5 2013-04-10 8:24 ` John Spencer 2013-04-10 9:47 ` Szabolcs Nagy 2013-04-10 14:14 ` Isaac Dunham 2013-04-10 14:31 ` Rich Felker 2013-08-11 21:30 ` Justin Cormack 2013-04-10 5:14 ` Rob Landley 2013-04-10 6:21 ` Rich Felker 2013-04-08 20:09 ` Rich Felker 2013-04-08 20:47 ` meres5
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).