Re: [osol-discuss] Identification macro for Open Solaris
Your remarks seem to suggest that the test for OS/compiler/library should be
pushed up to the Makefile (or similar script) level, so that the application
developer does not need to worry about testing for OS/compiler/library. But
isn't the Makefile author usually also the program author? Is it a big
difference between testing OS/compiler/library in a Makefile and testing it in
a source program ? Yes, testing it at the Makefile level does not require a
macro defining the OS. In your script, you test against the output of uname,
not a macro such as __sun or __SunOS_5_9; but before you write the script, you
need to know the output of uname for a particular OS. That seems to suggest
that the OS vendor needs to publicize that output (Hey everyone, the output of
uname-s is SunOS on the Solaris OS.). And is it so different from my
suggestion that the OS vendor suggest a standardized preprocessor macro, such
as __sun, for everybody's use?
Another point is that whereas you define _XOPEN_SOURCE using the compiler -D
option, it is considered better to #define _XOPEN_SOURCE in the source program.
The GNU libc Manual
(http://www.gnu.org/software/libtool/manual/libc/Feature-Test-Macros.html)
suggests: You should define these macros by using '#define' preprocessor
directives at the top of your source code files. ... You could also use the
-D option to GCC, but it's better if you make the source files indicate their
own meaning in a self-contained way.
If one defines _XOPEN_SOURCE in the source program, then one needs to test the
OS identification macro in the source program, as my examples show. What if
one gets rid of the '#if defined __sun', for instance, in my bind_thread()
example? Compiling it on Linux would generate errors complaining that
{sys/pset.h} cannot be found.
SunOS-5.1[01] BEST_STD_FLAG=
Is there SunOS-5.11? I am serious.
And what's the output of 'uname -s' and 'uname -r' on Open Solaris?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
On Sat, Sep 27, 2008 at 9:23 AM, Ming Kin Lai [EMAIL PROTECTED] wrote:
Your remarks seem to suggest that the test for OS/compiler/library should be
pushed up to the Makefile (or similar script) level, so that the application
developer does not need to worry about testing for OS/compiler/library. But
isn't the Makefile author usually also the program author? Is it a big
difference between testing OS/compiler/library in a Makefile and testing it
in a source program ? Yes, testing it at the Makefile level does not require
a macro defining the OS. In your script, you test against the output of
uname, not a macro such as __sun or __SunOS_5_9; but before you write the
script, you need to know the output of uname for a particular OS. That seems
to suggest that the OS vendor needs to publicize that output (Hey everyone,
the output of uname-s is SunOS on the Solaris OS.). And is it so different
from my suggestion that the OS vendor suggest a standardized preprocessor
macro, such as __sun, for everybody's use?
Another point is that whereas you define _XOPEN_SOURCE using the compiler -D
option, it is considered better to #define _XOPEN_SOURCE in the source
program. The GNU libc Manual
(http://www.gnu.org/software/libtool/manual/libc/Feature-Test-Macros.html)
suggests: You should define these macros by using '#define' preprocessor
directives at the top of your source code files. ... You could also use the
-D option to GCC, but it's better if you make the source files indicate their
own meaning in a self-contained way.
If one defines _XOPEN_SOURCE in the source program, then one needs to test
the OS identification macro in the source program, as my examples show. What
if one gets rid of the '#if defined __sun', for instance, in my bind_thread()
example? Compiling it on Linux would generate errors complaining that
{sys/pset.h} cannot be found.
If you are going to support more than 3-4 variations of OSs I'd
suggest that you make use of autoconf. Manually playing with defines
not based on functionality quickly becomes a maintenance nightmare.
There is no need to use anything else from the GNU autobuild toolset.
automake just lays another indirection between you and the Makefile
that is mostly frustrating if you already know how to make Makefiles.
libtool is harmful to portability and is a pain in the ass to debug,
but might save you some work if you are just interested to compile on
the common modern Unix-like OSs.
SunOS-5.1[01] BEST_STD_FLAG=
Is there SunOS-5.11? I am serious.
And what's the output of 'uname -s' and 'uname -r' on Open Solaris?
% uname -s;uname -r
SunOS
5.11
% uname -a
SunOS bhelliom 5.11 snv_81 i86pc i386 i86pc
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
On a related note, is the presence of OpenSolaris, as against Solaris
Express, the approved string for differentiating the different flavors
of Nevada? Thanks
-Siva
Richard L. Hamilton wrote:
Look again at standards(5).
Something like the following should work (simplified, i.e. I'm not using
make
in this example):
OSVERS=`uname -s`-`uname -r`
case ${OSVERS} in
SunOS-5.[89]) BEST_STD_FLAG=-D_XOPEN_SOURCE=500;;
SunOS-5.1[01]) BEST_STD_FLAG=-D_XOPEN_SOURCE=600;;
*) echo unsupported OS-version=${OSVERS}; exit 1;;
esac
# ok if not all the following directories exist. Use your own (if any) in
# place of /opt/local/bin, which is assumed to contain any tools that
# don't come with the system. Maybe you want /usr/sfw/bin or something
# else, too...
PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin:/opt/local/bin;export
PATH
cc ${BEST_STD_FLAG} foo.c -o foo
That works because _XOPEN_SOURCE=500 (or 600) implies the flags needed
for lesser included standards as well; the header files will take care of
that.
If you're curious about all the ugly details that you're _not_ really supposed
to depend on directly, look at sys/feature_tests.h
I agree it would be nice if the shmdt(2) man page had said
standard-conforming
version of shmdt() first appeared in XPG4 or something like that.
I don't know off the top of my head if autoconf/configure takes care of that
sort of thing for you by default, but I expect it could be made to without too
much trouble, and you could probably find plenty of examples to help you do
that sort of thing, although again, it's not something I've yet had to do
myself.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
Sivakumar Shanmugasundaram wrote: On a related note, is the presence of OpenSolaris, as against Solaris Express, the approved string for differentiating the different flavors of Nevada? Thanks There should be little you need to test for between the two flavors. The main difference is IPS, which should be as simple as testing for /usr/bin/pkg. Most other differences come down to which packages are installed, for which you could check for those packages. What other differences do you need to know about? -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
Alan Coopersmith wrote: Sivakumar Shanmugasundaram wrote: On a related note, is the presence of OpenSolaris, as against Solaris Express, the approved string for differentiating the different flavors of Nevada? Thanks There should be little you need to test for between the two flavors. The main difference is IPS, which should be as simple as testing for /usr/bin/pkg. Most other differences come down to which packages are installed, for which you could check for those packages. What other differences do you need to know about? Hypothetical question would be, if some one installed SUNWipkg on a SX*E, wouldn't the test for /usr/bin/pkg fail? I just need to get some tests (through shell) to differentiate the two flavors. Thanks -Siva ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
Sivakumar Shanmugasundaram wrote: Hypothetical question would be, if some one installed SUNWipkg on a SX*E, wouldn't the test for /usr/bin/pkg fail? Depends what you need to know. I just need to get some tests (through shell) to differentiate the two flavors. Thanks Why? What would you do differently between the two or do with this information? -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
On Sat, 2008-09-27 at 23:56 +0530, Sivakumar Shanmugasundaram wrote:
Alan Coopersmith wrote:
Sivakumar Shanmugasundaram wrote:
On a related note, is the presence of OpenSolaris, as against Solaris
Express, the approved string for differentiating the different flavors
of Nevada? Thanks
There should be little you need to test for between the two flavors.
The main difference is IPS, which should be as simple as testing for
/usr/bin/pkg. Most other differences come down to which packages
are installed, for which you could check for those packages.
What other differences do you need to know about?
Hypothetical question would be, if some one installed SUNWipkg on a
SX*E, wouldn't the test for /usr/bin/pkg fail?
I just need to get some tests (through shell) to differentiate the two
flavors. Thanks
In the desktop build environment install script I needed this
information in order to decide whether to install additional
packages using svr4 or IPS. The test I use are:
1) check if /usr/bin/pkg and /var/pkg/catalog exist
2) check if SUNWcs was installed using pkg
3) check if SUNWcsu was installed using pkgadd
shell scriptlet follows:
---8---
# check if the system is pkg(5) based or SVr4 based
# To identify, we check which system was used to install SUNWcs/SUNWcsu
# Output: set the PKG_SYSTEM variable to either pkg or svr4
check_pkg_system () {
if [ -x /usr/bin/pkg -a -d /var/pkg/catalog ]; then
/usr/bin/pkg -R $rootdir list SUNWcs /dev/null 21 {
PKG_SYSTEM=pkg
return
}
fi
/usr/bin/pkginfo -R $rootdir -q SUNWcsu {
PKG_SYSTEM=svr4
return
}
msg_err Could not identify the packaging system
exit 1
}
---8---
Note: this fragment was pasted from a CDDL-licensed script.
Note2: pkg list SUNWcs takes a couple of seconds...
Laca
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
I have a feeling that you are not the only test-for-individual-features
advocate who cannot explain how it would work in an actual case.
Refer to the Feature Test Macros section in
http://docs.sun.com/app/docs/doc/816-0220/6m6nkorrh?a=view. I think
test-for-features does depend on symbols predefined by the compiler. IMHO
test-for-features is a concept, whether one uses tools is an implementation
issue. I think one can achieve the goal without using autoconf, for example.
One can include those _POSIX_C_SOURCE=199309L stuff manually in a program.
Actually I did that in one of my programs:
#if defined __SUNPRO_C /* if Sun cc is used on Solaris */
#if defined __SunOS_5_9
#define _XOPEN_SOURCE
#define _XOPEN_VERSION 4
#elif defined __SunOS_5_10
#define _POSIX_C_SOURCE 200112L
#endif
#elif defined __GNUC__ defined __sun /* if a GCC-compatible compiler is
used on Solaris. GCC cannot
determine the Solaris version, so
the two Solaris 9 macros are used
because they are (expected to be)
valid in Solaris 10 (and above). */
#define _XOPEN_SOURCE
#define _XOPEN_VERSION 4
#endif
This is done in order to use the POSIX-conformed prototype of shmdt() on
Solaris, which requires the definition of _XOPEN_SOURCE and _XOPEN_VERSION=4.
And it is pain to find out which macro to #include because Sun fails to
indicate that in the man page of shmdt().
Another example is:
#ifdef __sun
#define _POSIX_PTHREAD_SEMANTICS /* POSIX conformance of sigwait()
on Solaris requires the definition
of _POSIX_PTHREAD_SEMANTICS */
#endif
static sigset_t usr2;
int func()
{
int ret, sig;
ret = sigwait(usr2, sig);
...
}
One can see that I still need to test for __sun and the Solaris version above.
That goes to my original question: whether there are such for Open Solaris.
Someone seemed to suggest that test-for-features would eliminate that need.
OK, tell me how in these actual cases.
And if one cannot do it by hand, then one can't do it by tools either.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
Look again at standards(5).
Something like the following should work (simplified, i.e. I'm not using make
in this example):
OSVERS=`uname -s`-`uname -r`
case ${OSVERS} in
SunOS-5.[89]) BEST_STD_FLAG=-D_XOPEN_SOURCE=500;;
SunOS-5.1[01]) BEST_STD_FLAG=-D_XOPEN_SOURCE=600;;
*) echo unsupported OS-version=${OSVERS}; exit 1;;
esac
# ok if not all the following directories exist. Use your own (if any) in
# place of /opt/local/bin, which is assumed to contain any tools that
# don't come with the system. Maybe you want /usr/sfw/bin or something
# else, too...
PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin:/opt/local/bin;export
PATH
cc ${BEST_STD_FLAG} foo.c -o foo
That works because _XOPEN_SOURCE=500 (or 600) implies the flags needed
for lesser included standards as well; the header files will take care of that.
If you're curious about all the ugly details that you're _not_ really supposed
to depend on directly, look at sys/feature_tests.h
I agree it would be nice if the shmdt(2) man page had said standard-conforming
version of shmdt() first appeared in XPG4 or something like that.
I don't know off the top of my head if autoconf/configure takes care of that
sort of thing for you by default, but I expect it could be made to without too
much trouble, and you could probably find plenty of examples to help you do
that sort of thing, although again, it's not something I've yet had to do
myself.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
Speaking of testing features rather than the OS/compiler/library, I have heard
quite a lot about it but I am not sure I understand it. Here is an example
where I want to write a function bind_thread() that can run on both Solaris and
Linux:
[code]
#if defined (__sun)
#include sys/pset.h /* P_PID, processor_bind() */
#include unistd.h /* getpid() */
#elif (defined (__gnu_linux__) || defined (__gnu__linux) || defined (__linux__))
#define _GNU_SOURCE
#include sched.h /* CPU_SET, CPU_ZERO, cpu_set_t, sched_setaffinity() */
#endif
#if defined (__sun)
int bind_thread(unsigned int cpu_id)
{
int ret;
ret = processor_bind(P_PID, getpid(), cpu_id, NULL);
if (ret == -1)
perror(bind_thread:processor_bind);
return ret;
}
#endif
#if (defined (__gnu_linux__) || defined (__gnu__linux) || defined (__linux__))
int bind_thread(unsigned int cpu_id)
{
int ret = 0;
cpu_set_t mask;
unsigned int len = sizeof(mask);
CPU_ZERO(mask);
CPU_SET(cpu_id, mask);
ret = sched_setaffinity(0, len, mask);
if (ret == -1)
perror(bind_thread:sched_setaffinity);
return ret;
}
#endif
[/code]
Here, the prototype of processor_bind() is actually in sys/processor.h which
is #included in sys/pset.h. Instead of testing the OS (Solaris vs Linux),
can anyone tell me how to test for individual feature in this case?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
I think the trick for testing individual features is that it does not depend on symbols predefined by the compiler. Rather, tools are used to generate a configure script, which in turn generates the Makefiles from prototypes, with suitable -D_has_feature_a -D_has_feature_b etc arguments (where feature_a and feature_b are just examples, of course). Typically that would be GNU autoconf and automake, I think. Don't ask _me_ how to set all that up from scratch, please; I've never tried. But enough free software builds (even on Solaris) with ./configure make make install that a lot of people must have figured it out already. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Identification macro for Open Solaris
What if one wants to self-document the OS and compiler versions under which the executable is compiled? I don't know of any other way; I can only think of using the macros defined by the compiler, so that the program would display some message like This executable is compiled using GCC 4.2.0 on Solaris 10, for example. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
