* __setfpucw in glibc 2.0.7
@ 1999-07-22 14:03 H.J. Lu
1999-07-24 11:03 ` Ulrich Drepper
0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 1999-07-22 14:03 UTC (permalink / raw)
To: GNU C Library
Hi,
__setfpucw is the only function available in glibc 2.0.7
to control the FPU at the run-time. There is <fenv.h> in
glibc 2.1. But it is not available in glibc 2.0. I believe
we should export it in glibc 2.1.2.
--
H.J. Lu (hjl@gnu.org)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: __setfpucw in glibc 2.0.7
1999-07-22 14:03 __setfpucw in glibc 2.0.7 H.J. Lu
@ 1999-07-24 11:03 ` Ulrich Drepper
1999-07-24 11:09 ` H.J. Lu
0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 1999-07-24 11:03 UTC (permalink / raw)
To: H.J. Lu; +Cc: GNU C Library
hjl@lucon.org (H.J. Lu) writes:
> __setfpucw is the only function available in glibc 2.0.7
> to control the FPU at the run-time. There is <fenv.h> in
> glibc 2.1. But it is not available in glibc 2.0. I believe
> we should export it in glibc 2.1.2.
No. Nobody outside the libc should have used it. This function is
not portable. Therefore people should have used asms which at least
is portable on machines of the same architecure.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: __setfpucw in glibc 2.0.7
1999-07-24 11:03 ` Ulrich Drepper
@ 1999-07-24 11:09 ` H.J. Lu
1999-07-24 11:25 ` Ulrich Drepper
1999-07-24 12:06 ` Thorsten Kukuk
0 siblings, 2 replies; 6+ messages in thread
From: H.J. Lu @ 1999-07-24 11:09 UTC (permalink / raw)
To: drepper; +Cc: libc-hacker
>
> hjl@lucon.org (H.J. Lu) writes:
>
> > __setfpucw is the only function available in glibc 2.0.7
> > to control the FPU at the run-time. There is <fenv.h> in
> > glibc 2.1. But it is not available in glibc 2.0. I believe
> > we should export it in glibc 2.1.2.
>
> No. Nobody outside the libc should have used it. This function is
> not portable. Therefore people should have used asms which at least
> is portable on machines of the same architecure.
>
It is in glibc 2.0 and it is used by some programs. It
doesn't make any senses to break existing binaries. At
least, it should be global as the glibc 2.0 symbol
and local as the glibc 2.1 symbol so that ld won't use
it. People have been complaining about the Linux library
upgrade. Why don't we try to avoid the binary incompatibility
as much as we can?
--
H.J. Lu (hjl@gnu.org)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: __setfpucw in glibc 2.0.7
1999-07-24 11:09 ` H.J. Lu
@ 1999-07-24 11:25 ` Ulrich Drepper
1999-07-24 12:06 ` Thorsten Kukuk
1 sibling, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 1999-07-24 11:25 UTC (permalink / raw)
To: H.J. Lu; +Cc: libc-hacker
hjl@lucon.org (H.J. Lu) writes:
> It is in glibc 2.0 and it is used by some programs.
And it never must have been used.
> Why don't we try to avoid the binary incompatibility as much as we
> can?
People must use the functions which are designed for it.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: __setfpucw in glibc 2.0.7
1999-07-24 11:09 ` H.J. Lu
1999-07-24 11:25 ` Ulrich Drepper
@ 1999-07-24 12:06 ` Thorsten Kukuk
1999-07-24 12:58 ` H.J. Lu
1 sibling, 1 reply; 6+ messages in thread
From: Thorsten Kukuk @ 1999-07-24 12:06 UTC (permalink / raw)
To: H.J. Lu; +Cc: libc-hacker
On Sat, Jul 24, H.J. Lu wrote:
> >
> > hjl@lucon.org (H.J. Lu) writes:
> >
> > > __setfpucw is the only function available in glibc 2.0.7
> > > to control the FPU at the run-time. There is <fenv.h> in
> > > glibc 2.1. But it is not available in glibc 2.0. I believe
> > > we should export it in glibc 2.1.2.
> >
> > No. Nobody outside the libc should have used it. This function is
> > not portable. Therefore people should have used asms which at least
> > is portable on machines of the same architecure.
> >
>
> It is in glibc 2.0 and it is used by some programs. It
> doesn't make any senses to break existing binaries. At
> least, it should be global as the glibc 2.0 symbol
> and local as the glibc 2.1 symbol so that ld won't use
> it. People have been complaining about the Linux library
> upgrade. Why don't we try to avoid the binary incompatibility
> as much as we can?
As far as I know, on our 6 SuSE Linux 6.2 CDs is only one program
which uses __setfpucw. And for this I use the same workaround as
for the applixware binaries.
It would be really interesting to know how many programs are
affected. It looks for me we waste more time in discussing this
than we would need to fix this few programs.
Thorsten
--
Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de
SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: __setfpucw in glibc 2.0.7
1999-07-24 12:06 ` Thorsten Kukuk
@ 1999-07-24 12:58 ` H.J. Lu
0 siblings, 0 replies; 6+ messages in thread
From: H.J. Lu @ 1999-07-24 12:58 UTC (permalink / raw)
To: Thorsten Kukuk; +Cc: libc-hacker
>
> As far as I know, on our 6 SuSE Linux 6.2 CDs is only one program
> which uses __setfpucw. And for this I use the same workaround as
> for the applixware binaries.
>
I was told quake used it.
--
H.J. Lu (hjl@gnu.org)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-07-24 12:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-22 14:03 __setfpucw in glibc 2.0.7 H.J. Lu
1999-07-24 11:03 ` Ulrich Drepper
1999-07-24 11:09 ` H.J. Lu
1999-07-24 11:25 ` Ulrich Drepper
1999-07-24 12:06 ` Thorsten Kukuk
1999-07-24 12:58 ` H.J. Lu
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 read-only IMAP folder(s) and NNTP newsgroup(s).