[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -xc99=all and libraries on Solaris 10

From: Ralf Wildenhues
Subject: Re: -xc99=all and libraries on Solaris 10
Date: Wed, 10 Feb 2010 21:56:44 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hi Peter,

* Peter O'Gorman wrote on Wed, Feb 10, 2010 at 06:20:42PM CET:
> Libc, when deciding what its behavior should be looks at the values of
> two global integers __xpg4 and __xpg6.
> __xpg4=1; __xpg6=0x0000FFFF; is c99 behavior
> __xpg4=0; __xpg6=0xFFFF0000; is c89 behavior.
> 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).
> What this means is, if a library is linked with c99 on solaris 10, any
> clients of that library will get c99 behavior from libc (the lookup for
> __xpg4 and __xpg6 will find the definitions in the library before
> finding the ones in libc itself). It is, of course, possible to override
> this by putting definitions for __xpg4 and __xpg6 into the application
> itself (but then the library that was built with c99 will get c89
> behavior from libc).

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?

Hmm, this seems to even be the case for shared libraries.  So I guess it
will be a problem for dlopened modules as well.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]