Re: -xc99=all and libraries on Solaris 10

[Bruno Haible]

Hi,

Reviving an old thread from February 2010.
In <http://lists.gnu.org/archive/html/autoconf/2010-02/msg00013.html>
Peter O'Gorman wrote:

> When creating a library or application with c99 or cc -xc99=all
> /usr/lib/values-xpg6.o is included in the output, this object file
> contains the c99 definitions for __xpg4 and __xpg6. When creating output
> without c99/-xc99=all this extra object is not put into the output and
> the values of __xpg4 and __xpg6 in libc (c89 behavior) are used (because
> they are the only definitions available).

I confirm with a test program.
========================== foo.c =======================
#include <stdio.h>
int main ()
{
  printf ("%f\n", 1.0 / 0.0);
  return 0;
}
========================================================

POSIX:2008 says that the output should be "inf".

$ /opt/solstudio12.2/bin/cc foo.c && ./a.out
Inf
$ nm a.out | grep values
[34]    |         0|       0|FILE |LOCL |0    |ABS    |values-Xa.c

$ /opt/solstudio12.2/bin/cc -xc99=all foo.c && ./a.out
inf
$ nm a.out | grep values
[34]    |         0|       0|FILE |LOCL |0    |ABS    |values-Xa.c
[36]    |         0|       0|FILE |LOCL |0    |ABS    |values-xpg6.c

$ gcc foo.c && ./a.out 
Inf
$ gcc foo.c /usr/lib/values-xpg4.o && ./a.out 
Inf
$ gcc foo.c /usr/lib/values-xpg6.o && ./a.out 
inf
$ gcc -std=gnu99 foo.c && ./a.out 
Inf
$ gcc -std=gnu99 foo.c /usr/lib/values-xpg6.o && ./a.out
inf

So, it's clear that
  - the presence of values-xpg6.c in the executable causes printf()
    to behave differently,
  - values-xpg6.c is implicit in the link command line of
    "cc -xc99=all", but not of "cc", "gcc", "gcc -std=gnu99".

> Also, does anyone happen to know what exactly libc does differently
> with __xpg4=1 (the __xpg6 settings are documented in
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/inc/xpg6.h

Grepping through the OpenSolaris source code, I find references to
__xpg4 in

  libc/port/sys/libc_open.c
  libc/port/sys/libc_link.c
  libc/port/gen/execvp.c
  libc/port/gen/sysconf.c
  libc/port/stdio/system.c
  libc/port/stdio/_filbuf.c
  libc/port/stdio/popen.c
  libc/port/print/doprnt.c
  libc/port/threads/spawn.c
  libc/port/threads/thr.c
  libc/port/regex/wordexp.c
  libc/inc/libc.h

and to __xpg6 in

  libc/port/gen/strtod.c
  libc/port/gen/sysconf.c
  libc/port/gen/confstr.c
  libc/port/stdio/fopen.c
  libc/port/stdio/doscan.c
  libc/port/print/doprnt.c
  libc/port/threads/thr.c
  libc/port/i18n/wstod.c
  libc/inc/xpg6.h

Ralf Wildenhues asked in
<http://lists.gnu.org/archive/html/autoconf/2010-02/msg00014.html>
> Do I understand correctly that effectively, that makes all code relying
> on one behavior silently link-incompatible with all code relying on the
> other behavior, but either of them still compatible with code that
> doesn't care?

Yes. And the "xpg6" flag can sit in the program and have an effect on the
libraries, just as it can sit in a library and have an effect on the rest
of the code in the program.

Test case:
$ cat libinf.c
#include <stdio.h>
void libinf (void)
{
  printf ("%f\n", 1.0 / 0.0);
}
$ cat foo.c
#include <stdio.h>
extern void libinf (void);
int main ()
{
  printf ("In lib:  "); libinf ();
  printf ("In main: %f\n", 1.0 / 0.0);
  return 0;
}

$ gcc -shared -fPIC libinf.c -o libinf.so
$ gcc foo.c libinf.so -R `pwd`
$ ./a.out 
In lib:  Inf
In main: Inf

$ gcc -shared -fPIC libinf.c -o libinf.so
$ gcc foo.c /usr/lib/values-xpg6.o libinf.so -R `pwd`
$ ./a.out 
In lib:  inf
In main: inf

$ gcc -shared -fPIC libinf.c /usr/lib/values-xpg6.o -o libinf.so
$ gcc foo.c libinf.so -R `pwd`
$ ./a.out 
In lib:  inf
In main: inf

$ gcc -shared -fPIC libinf.c /usr/lib/values-xpg6.o -o libinf.so
$ gcc foo.c /usr/lib/values-xpg6.o libinf.so -R `pwd`
$ ./a.out 
In lib:  inf
In main: inf

Bob Friesenhahn asked in
<http://lists.gnu.org/archive/html/autoconf/2010-02/msg00015.html>:
> if GCC and GNU ld participate in this scheme under Solaris.

As far as GCC 4.5.2, the answer from grepping the source code is no.

There is a bug open about this, though:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411>

I hope this flag won't be used by GCC, because it's a bad idea, just
like the _fmode variable on Windows.

The right way to distinguish desired standards conformance, in a way
that works fine with libraries, is through preprocessor defines
(such as __EXTENSIONS__, _FILE_OFFSET_BITS, etc.). This technique is
used in Solaris in some places (ttyname_r, getlogin_r, sysconf, putmsg
etc.); no idea why the implementors went the wrong way for printf and
other functions.

Bruno