Linux to SolarisTM 10 OS

Migration Guide

 

Linux to Solaris 10 OS Migration Guide 2

Contents

Overview of the Solaris 10 OS and Linux.................................................... ...............5

Assistance From Sun........................................................................................... .........6

Additional Resources......................................................................... ...........................7

Processor Architectural Issues............................................................. .......................10

Little-Endian vs. Big-Endian....................................................... ........................10

Application Data Storage.................................................................................... 11

Storage Order and Alignment..............................................................................12

Read Write Structures ............................................................ ............................13

32-Bit and 64-Bit Issues.................................................................................... ..13

Multithreaded Programming........................................................................... ....15

Compatible Solaris and POSIX APIs -- Semaphores.........................................18

Compiler Differences.......................................................................................... .......19

Source Code and Version Control....................................................................... .......20

Source Code Control....................................................................................... ....20

CVS vs. RCS................................................................................................. ......21

Application Building............................................................................................... ...24

Make Files........................................................................................................... 24

imake Utility............................................................................ ..........................24

Application Packaging...................................................................................... .........25

Development Tools............................................................................. ........................26

Linux Tools....................................................................................................... ..26

SunTM Studio Software................................................................................. .......26

Graphical Applications.................................................................... ....................27

Debugging and Code Optimization............................................................. ........27

Porting Applications Using LAMP............................................................... ......27

Memory Management.............................................................................. ...................28

System Calls and Library Calls.............................................................................. ....29

LinCAT ....................................................................................... ...............................29

A Demo of LinCAT............................................................... ..............................30

Conclusion............................................................................................. .....................31

References.................................................................................. .................................31

Compiler Options.................................................................................................. .....33

Linker Options....................................................................................... .....................42

Compatible #pragmas..................................................................................... ............45

Attributes of Variables................................................................................. .......45

Attributes of Functions........................................................................ ................46

Useful Sun Studio Compiler Options (Not Available on gcc)............................47

Inline Assembly............................................................................................ ..............49

make Options....................................................................................... .......................50

RCS, SCCS, and CVS Mappings.............................................................................. .51

Linux to Solaris 10 OS Migration Guide 3

Suggested Methodology.......................................................................................... ...52

Porting Assessment........................................................................................... ..53

Module-wise Porting....................................................................................... ....53

Integration and Functional Testing................................................... ..................53

System Testing ................................................................................................... 54

Deployment..................................................................................................... ....54

Linux to Solaris 10 OS Migration Guide 4

CHAPTER 1

Introduction

The purpose of this document is to provide a set of guidelines to enable the reader to

resolve issues faced during the migration of a Linux-based application to the SolarisTM

10 Operating System. By way of supporting information, we have also discussed similarities

and differences between the two environments in terms of operating system

features, architecture, system calls, and application development environments. We

also provide information on some very useful tools supplied by Sun that can aid the

migration effort.

Overview of the Solaris 10 OS and Linux

The Solaris 10 OS is a mature, reliable, secure, high-performing, and scalable operating

system for business-critical applications. Besides being highly feature rich, at its

core it is a POSIX-compliant UNIX® system and is derived from UNIX System V

Release 4 (SVR4), which was jointly created by Sun and AT&T. The Solaris OS by

default provides a rich set of commands, utilities, and libraries that are POSIX

compliant. The detailed POSIX standards revised as of year 2004 are available at:

http://www.opengroup.org/onlinepubs/009695399/toc.htm.

For greater compatibility with other UNIX variants, Solaris software also bundles

commands, utilities, and libraries found in UNIX variants of BSD heritage. The Solaris

OS runs on both SPARCTM and x86/x64 based systems and supports both 32-bit and

64-bit applications on both processor architectures. The Solaris OS has been certified

to conform to most of the leading industry standards, such as X/Open® XPG4, XTI,

UNIX98, POSIX, and FIPS.

Recently Sun started a project called OpenSolarisTM by open sourcing large parts of

Solaris source code. This is the first instance of a commercial branded UNIX going

open source. The open source community is already working on it, and the resulting

OpenSolaris operating system is available for use. The OpenSolaris project is thriving

on community development effort and is a great opportunity for collaboration by

developers and users who want to develop and improve the operating system with their

innovative extensions. Most of the leading-edge features of the Solaris 10 OS are also

available with the OpenSolaris OS. Hence much of what we discuss in this guide will

also be applicable to OpenSolaris as a target platform.

Linux, like OpenSolaris, is a popular open source OS and has seen tremendous growth

in terms of user base. It has matured over years and provides a nearly POSIXcompliant

development and deployment environment. Linux exhibits to different

degrees BSD UNIX- and SVR4-compliant behavior as well. During the last few years

Linux to Solaris 10 OS Migration Guide 5

leading Linux vendors have agreed to conform to what is now called Linux Standard

Base (LSB). Compliance to LSB ensures that a standard set of APIs are available for

applications that are meant to be portable. Even though Linux runs on a number of

architectures, deployment of Linux on x86/x64 architectures is more common. In this

document, for sake of brevity, we will consider Red Hat Enterprise Linux 3 (RHEL3)

and Red Hat Enterprise Linux 4 (RHEL4) to be the representative Linux environments.

Sun as a champion of open source software has built a number of features into the

Solaris 10 OS, designed to make it a leading platform for Linux interoperability. Sun

provides many Linux-compatible commands, utilities, and development tools as packaged

binaries for every version of the Solaris OS. Most of them are available as a part

of the Solaris 10 distribution in the Solaris Companion CD and install into the location

/usr/sfw. The latest versions of these packages, along with other relevant information,

are available at http://sun.com/freeware. Once installed on a Solaris

machine, these additional packages enable users to obtain Linux-like functionality even

within the Solaris environment.

Considering that both the Solaris OS and Linux provide POSIX functionality, and the

Solaris 10 OS bundles a lot of Linux interoperability features, the level of affinity

between Linux and the Solaris OS has never been better. Therefore, it is natural to

expect that porting of an application to Solaris from Linux should be easy. The fact

that most of the recent Linux distributions are LSB 2.0 compliant, makes the task

appear to be even easier. In reality however, porting of an application needs some

careful effort. Applications requiring additional effort are those using architecture- and

OS-specific extensions, kernel-space privileged accesses, direct access to devices,

unsupported compiler extensions, and so on. Applications that do not follow guidelines

for portable code are bound to require more involved effort.

Assistance From Sun

Sun provides tools, guidelines, and assistance for porting applications from Linux to

the Solaris OS.

For situations where the source code of the application is not available, Sun provides a

way to run Linux x86-based application binaries on x86/x64 systems using the Solaris

OS. This free utility called lxrun is available for download; see

http://www.sun.com/software/linux/compatibility/lxrun/.

lxrun is an emulator that sits between the Solaris and the Linux x86 binary executable

and remaps system calls "on the fly" allowing them to run unmodified on the

Solaris OS for x86 platforms. More about this utility can be had from the lxrun(1)

man pages.

It may however be better to go for a full-scale porting of the application and create

native binaries for the Solaris OS. This allows complex applications and ISV products

to maximize the benefits of the mature platform provided by the Solaris 10 release.

Prior to starting a project of this type where an existing Linux application requires

porting to the Solaris 10 OS, it is useful to identify the potential problem areas in the

code.

Sun provides one such code-scanning tool to analyze C/C++ source files and identify

code and function compatibility issues. This tool is called LinCAT (Linux Compatibility

Assurance Toolkit), and is also known as the Linux Analyzer for C/C++ Source

Linux to Solaris 10 OS Migration Guide 6

Code. This tool is based on JavaTM technology and can be used for identifying porting

issues in C/C++ source code files. This utility analyzes most of the known issues that

pose difficulty in porting source files from Linux to the Solaris OS. It can also help in

estimating the total effort required for the port.

LinCAT identifies potential problems and can provide information on:

• Names of function calls, their location and frequency of use

• Source lines with potential porting issues

• Solutions for resolving select porting issues

• Incompatible calls – suggests solutions by looking up function calls database

Using LinCAT can save a significant amount of time and effort for developers working

in large projects. The latest version of LinCAT can be downloaded from

http://developers.sun.com/prodtech/solaris/downloads/lincat

/index.html.

Reports generated by LinCAT also help in estimating the effort needed. Once the

required changes are identified, the task of making actual changes in the code,

compiling them, and building the application binary is relatively straight-forward.

Following the usual software development steps (such as build, test, and release), the

application is prepared for use on the Solaris platform without compromising in terms

of functionality. To address performance issues, if any, Sun also provides high-quality

tools like Dynamic Tracing (DTrace).

In real life, it is highly desirable to follow a systematic, process-oriented approach in a

migration project of this type. In Appendix G we have suggested a typical process flow

for migrating an application to the Solaris 10 platform.

Additional Resources

Sun offers additional web-based resources on this subject for both developers and

administrators. Sun offers courses specifically for Linux administrators covering a

thorough introduction to the Solaris OS and other associated IT infrastructure. Apart

from core technologies the courses focus on system, network, and application administration.

These courses provide valuable insight and help an administrator quickly gain

an understanding of the various issues concerning migration from Linux to the Solaris

OS. Similarly, for developers new to the professional developer tools like SunTM Studio

11 software, plenty of web-based resources are available.

For further details on migrating from Linux to the Solaris platform, see the Sun web

site's section on migration:

http://partneradvantage.sun.com/partners/migration/.

Linux to Solaris 10 OS Migration Guide 7

CHAPTER 2

Affinity of Linux With the Solaris 10 OS

The Solaris 10 OS is designed in a modular manner so that it can adapt to new processor

and hardware architectures. The design also allows new services to be added in

an evolutionary manner. Most of the well-known attributes of earlier Solaris versions

such as reliability, availability, security, scalability, manageability, and interoperability

have been improved and are at their best in the Solaris 10 release. A much more informative

white paper on the Solaris 10 OS can be found at:

http://www.sun.com/software/whitepapers/solaris10/classbyit

self.pdf.

The Solaris 10 OS, therefore, is one of the most popular platforms of choice for

hosting large-scale business critical applications, particularly those currently running

on Linux platform. Sun has built many features into the Solaris 10 OS to make it

compatible with Linux. The diagram below shows various services supported by the

Solaris platform.

In addition to all these, the Solaris 10 OS ships with hundreds of standard Linux

commands, tools, utilities, and services. These packages are built from the same open

source code base that feeds Linux. These packages are distributed as a part of the

Solaris companion CD and install to the directory /usr/sfw. The latest versions of

most of these packages and information on them are also available as free downloads

from http://sun.com/freeware.

Linux to Solaris 10 OS Migration Guide 8

The availability of these packages along with the normal Solaris functionalities offers a

great choice for any Solaris user. A user can choose to use these Linux-like packages

and thereby immensely increase affinity with Linux. Please note that you may need to

suitably alter the environment variables like PATH for your shell in order to give precedence

to these Linux-like commands and services.

Just so you can make an informed judgment, here is a partial list of popular Linux-side

tools in various categories, which are also found in the Solaris 10 OS.

Categories Name of the Tool

GNU Command Set All popular UNIX commands for access, file manipulation,

editing, communication, and so on

Shell Bash

Scripting Bash, Perl, Python, Tcl/Tk, gawk, sed

GUI and GUI Development GNOME, KDE, GTK+

GCC Compilers and Runtime Libraries C, C++, G77, glibc ...

GNU Software Development Tools Ld, ldd, lorder, ar, elmdump,Gmake, ant, nm, gprof, RCS, CVS

GNU Debugging Tools and derivative Gdb, DDB

Web Services Apache, Tomcat, JBoss

Java Services Sun JRE, Sun JDKTM

Given that the Solaris 10 OS already provides a very significant Linux baseline in

terms of platform services, commands, tools, libraries and software development environment,

the task of porting an application to the Solaris OS then boils down to the

actual code that needs to be modified. If the same development tools and compilers are

used on both sides, the tools-related complexities in porting become minimal.

It is important to note that the GNU Compiler Collection GCC and other GNU tools are

available on both Linux and the Solaris OS. Sun has made Sun Studio 11 compilers

and tools available on both the Solaris and Linux platforms with zero-cost licensing.

But normally one finds that developers prefer to use the GCC tool chain on the Linux

side and Sun-supplied development tools on the Solaris side. There may also be occasions

when a porting situation may require the use of the more professional tools on

the Solaris side. Sun Studio 11 software is one such option and is popular among

Solaris developers. The Sun Studio 11 product comes with its own set of compilers

and tools. In a situation like this the developer will need to understand the few subtle

semantic and syntactic differences between the GNU offerings and the Sun Studio 11

tools. We will cover some of those later in this document.

Linux to Solaris 10 OS Migration Guide 9

CHAPTER 3

Porting Issues

Processor Architectural Issues

Little-Endian vs. Big-Endian

Issues relating to the byte ordering in the source and the target platforms are a cause of

many potential problems. The method of storing information in a computer's memory

and the ordering of bytes in it is referred to as endianness. When the most significant

byte (MSB) of any multi-byte data field is stored at the lowest memory address, then

the system is said to be big-endian. When the least significant byte (LSB) of any multibyte

data field is stored at the lowest memory address, then the system is called littleendian.

Intel and AMD processors are little-endian, meaning the least significant byte

is stored at the lowest address. In contrast UltraSPARC® processors are big-endian.

Consider the following example.

Storing 0X01020304 on Intel or AMD processors in little-endian format, assuming

4-byte storage, looks as follows:

00000100 00000011 00000010 00000001

Memory Address: 100 101 102 103

Storing the same number 0X01020304 on UltraSPARC processors in big-endian

format, assuming 4-byte storage, looks as follows:

00000001 00000010 00000011 00000100

Memory Address: 100 101 102 103

The Solaris OS can be used both in big-endian mode (SPARC version) and in littleendian

mode (x86/x64 versions on Intel or AMD). Endianness is mandated by the hardware

platform used. One of the strengths of the Solaris OS is that it handles the endianness

issue transparently, so that ISVs or developers do not need to be too concerned

about how quickly their applications will be available on the Solaris OS for SPARC

platforms or the Solaris OS for x86/x64 platforms (for Intel or AMD). Sun's software

architecture allows big-endian applications for the Solaris OS on SPARC platforms to

be recompiled to run on the little-endian Solaris OS on x86/x64 platforms (for Intel or

Linux to Solaris 10 OS Migration Guide 10

AMD). In general, no re-engineering is needed. However, the endianness difference

can cause problems, particularly if an application uses low-level code that takes

optimal advantage of the hardware capabilities that it was initially written for.

Normally byte ordering within numeric data is also transparent to the application

except for some instances as stated below.

• Sending data over network: The standard C library provides these routines:

ntohl(), ntohs(), htonl(), and htons() to convert numeric data between

network byte order and host byte order. These routines are implemented on the host

platform to handle the conversion between host and network byte order, and they

should always be used to shield the application from the underlying architecture.

• Accessing the individual bytes of the numeric data using pointers: If you use

individual bytes of a numeric data type to store and retrieve values, you might get

different results due to the endian property of the underlying platform. In this case

the code is not portable.

For example:

Value 0X01020304 on Intel or AMD platform (little-endian format)

00000100 00000011 00000010 00000001

Memory Address: 100 101 102 103

int flagVal = 0X01020304;

char *cptr = (char *)&flagVal;

printf("Val is %d\n", *cptr);

In this example, the little-endian machine will print 4, and the big-endian machine will

print 1. To make this code portable, you should use individual character-type variables

to store these values rather than using a numeric data type. Alternatively, you may use

a structure variable with individual fields for every value, and get and set these values

using the structure field names.

Application Data Storage

File systems are neutral to endianness in general, and swapping files is not an issue

between SPARC and x86/x64 (Intel or AMD) versions of the Solaris OS. But applications

storing raw data that can be shared between platforms would be an issue. For

example, if an application on the Solaris OS for SPARC platforms writes the data

structures in a raw format to the files, then the data stored in these files would be

endian-dependent. Reading or writing these data files from a Solaris system based on

Intel or AMD processors can create problems regarding the endianness of the data. In

short, the binary data (raw data) stored on a file is generally not transferable between

the SPARC and x86/x64 (Intel or AMD) platforms.

Linux to Solaris 10 OS Migration Guide 11

Applications storing data that is shared between platforms can handle the endianness

issue in one of the following two ways:

• Store data in an application-defined, endian-neutral format using text files and

strings.

• Choose either the big-endian or little-endian convention and do byte swapping

(potentially using enabling technology such as XDR) when necessary.

The need for cross-platform compatibility is so well-understood that major applications

have been available on big-endian and little-endian Solaris environments for years

without problems. They range from personal productivity applications to major database

management systems from vendors, including Oracle, Informix, and Sybase.

Storage Order and Alignment

The order of storage of the data varies between platforms, therefore code that expects a

particular storage order is not portable. Consider this example:

struct date

{

char yr;

char mon;

char day;

char x; // struct var size is 4

} planned_date, end_date;

if ( (*(long * )&end_date) > (*(long *)&planned_date))

{

printf("Sorry, You missed the deadline for migrating to Solaris \n");

}

The code in this example assumes that year will be stored before month. This code

works properly on an x86 platform, but not on a machine based on UltraSPARC technology.

To avoid this type of potential error situations, portable code should compare

the individual fields of the structure variables separately and not rely upon storage

order. For example:

if (compare_dates(end_date, planned_date) > 0)

{

printf("Sorry, You missed the deadline for migrating to Solaris \n");

}

int compare_dates(struct date date_to_compare, struct date date_compare_against)

{

if (date_to_compare.year != date_compare_against.year)

return (date_to_compare.year – date_compare_against.year);

if (date_to_compare.month != date_compare_against.month)

return (date_to_compare.month – date_compare_against.month);

if (date_to_compare.day != date_compare_against.day)

return (date_to_compare.day - date_compare_against.day);

}

Linux to Solaris 10 OS Migration Guide 12

The alignment of the field members in a structure differs across platforms, resulting in

variable padding requirements and causing the structure to be a different size. In order

to make code portable, the structure size should always be accessed using the sizeof

operator.

Read Write Structures

Most programs read and write data to the permanent storage media as a complete structure

in binary form using standard C routines. These routines need the data size that is

being read or written. Due to the different alignment and data type sizes on different

platforms, the structure sizes vary, and therefore the sizeof operator should be used

to specify the number of bytes to read or write in these routines.

For example, if your program needs to read a record of the type MyRecord (that you

know has a total of 25 bytes of data), then you wouldn't write the following:

MyRecord myrecord;

fread(&myrecord, 25, 1, fp);

Instead, you would use the following convention:

MyRecord myrecord;

fread(&myrecord, sizeof(MyRecord), 1, fp);

32-Bit and 64-Bit Issues

Both the Solaris OS and Linux run on 32-bit and 64-bit processors. UltraSPARC processors

are 64-bit processors. x86-compatible processors from Intel and AMD are 32-bit

processors with a default 4 Gbytes of address space. The Intel EM64T and AMD64

families of processors are 64-bit wide and support 64-bit address space. However,

these processors can also run in 32-bit compatibility mode and run any legacy 32-bitcompatible

applications. The Solaris 10 OS is fully equipped to handle the inherent 32-

bit and 64-bit issues on the platform it runs on. The problem arises only when improperly

written applications make assumptions about the size of the various data types and

the conversion between them.

The C language specification does not specify any size for its integral data types, and it

only states their relationship as follows:

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

The size of the individual data types is determined by the data type model being used

by the operating environment. The 32-bit OS uses the ILP32 data model, which specifies

that the size of the int, long, and pointer data types is 32 bits (hence ILP32).

The industry-standard LP64 data type model is used in the 64-bit OS. The LP64 data

type model specifies a size of 64 bits for the long and pointer data types and does

not modify the size of other data types. The size relationship for various data types

under both the 32-bit and 64-bit OS is as follows.

Linux to Solaris 10 OS Migration Guide 13

C Data Type ILP32 Data

Model

(Size in Bits)

LP64 Data

Model

(Size in Bits)

char 8 8

short int 16 16

int 32 32

long 32 64

float 32 32

double 64 64

pointer 32 64

enum 32 32

long long 64 64

long

double 128 128

The 32-bit OS APIs are also supported on the 64-bit OS for backward compatibility,

and no changes are required to the application. When converting a 32-bit application to

a 64-bit application, an ideal case would only require recompilation and re-linking with

the 64-bit libraries. In actuality, most applications will require some code change and

clean-up in order to run on both the 32-bit and 64-bit OS.

If the 32-bit and 64-bit API versions differ, then it is preferable to have conditional

compilation using #ifdefs for the different code snippets. This is advantageous over

maintaining different source code files for both OS, though, for readability purposes,

you should make minimal use of it. Both Solaris and Linux platforms provide feature

test macros for data type models. For more information on the feature test macros for

the Solaris OS, refer to Solaris 64-bit Developer's Guide (available at:

http://docs.sun.com/app/docs/doc/816-5138).

The ILP32 data type model does not distinguish among int, long, and pointer

data types since they are all 32-bit long. Yet, in the LP64 data type model, the size of

long and pointer data types has changed to 64 bits. Hence, most code problems

may originate from improper use of these data types. The following guidelines will

help you eliminate possible 32-bit and 64-bit porting problems:

1. Interchangeable use of int, long, and pointer data types should be corrected to

prevent possible data loss.

2. Explicit arithmetic manipulation with addresses should be replaced with the

equivalent pointer arithmetic expression.

3. Union and structure fields should be checked for an impact on data type size change.

4. Check the internal data structures in all applications for holes. Use extra padding

between fields of the structure to allow long and pointer fields to grow to 64 bits

in the LP64 data type model.

Linux to Solaris 10 OS Migration Guide 14

5. The evaluation of expressions can be affected since standard C conversion rules are

influenced by a data type size change. You should use explicit casts and declare the

type of constants (use u, U, l, L, f, and F suffixes with integral constants) to get

desirable and consistent results.

6. When code is converted to 64 bits, always use explicit casting to achieve intended

results. This prevents sign extension problems that occur from conversion rules of the

C language. An example of this conversion problem is when an integer is promoted

to an unsigned int.

7. The C compiler assumes any function or variable that is used in a module and not

defined or declared externally to be an integer. Any use of these functions and

variables as long or pointer data type will lead to truncation in the LP64 data

type model.

8. In the LP64 data type model, the sizeof() operator has the effective type of an

unsigned long. Thus, care should be taken when it is passed or cast to an int data

type because this might lead to data loss.

9. Application performance might change due to a larger data size and may require

additional code modifications to improve performance.

10. If data is sent or received from external interfaces, ensure that the data size being

sent is the same size that the external interface is expecting, and vice versa.

Multithreaded Programming

Most modern operating systems use multithreading as a way of increasing the computational

granularity for more efficient use of resources in scalable environments. Both

kernel-mode and user-mode services rely on the underlying threads model implemented

by the operating systems. In order to maintain the integrity of various data structures

and provide controlled concurrency to all threads and processes running on the system,

entities like mutexes and semaphores are used. The implementation details, however,

vary significantly, even among UNIX-like operating systems; these details are potential

issues in a porting project.

The Solaris kernel inherently supports threads. The kernel internally schedules threads

to share the available CPU resources in an optimal manner. These kernel threads are

bound to what is called Lightweight Processes (LWPs).

Solaris versions over the years have supported multiple implementations of the threads.

Solaris threads have been particularly significant. However, the POSIX thread library

provided with the Solaris OS has emerged as the de-facto standard as it enables easy

portability of applications between UNIX platforms, including Linux. More detailed

explanation on Solaris threads can be found in the book Solaris Internals by Jim

Mauro and Richard McDougall, published by Sun Microsystems Press. Programming

with threads requires deeper skills. A useful reference on the topic is the book

Programming With Threads by Steve Kleiman, Devang Shah, and Bart Smaalders.

On the Linux side, there are multiple implementations of threads packages, and all of

them have seen significant improvements over years. By and large these implementations

are POSIX compliant. Variations in implementations result in performance

issues, though. Linux distributions based on kernel versions 2.2 and 2.4 support what

is called Linux threads. To facilitate easier porting of Solaris applications using Solaris

Linux to Solaris 10 OS Migration Guide 15

threads, yet another open source package called Solaris Compatible Thread Library

(SCTL) is available. Linux 2.6 kernel bundles a new threads model called Native

POSIX Thread Library (NPTL) and is known to be far more efficient.

In spite of these variations in implementations, the syntax of most of the calls to the

threads library is quite similar and follows the POSIX threads standard. Hence, from a

porting perspective, Linux-side calls to the threads library are quite portable to the

Solaris 10 OS. One may of course need to be aware of the order and names of the

thread library in the linker commands of the makefiles. Normally -lpthreads is the

linker option that is used for accessing POSIX threads on the Solaris platform.

If for any specific reason one would like to use Solaris threads on the Solaris side,

some additional effort will be required to make changes in the code and substitute the

POSIX thread calls with Solaris threads calls. Also one will need to analyze the

semantic accuracy of the code while doing this. The following table provides a

mapping between comparable Solaris threads and POSIX threads for reference.

Number POSIX Thread Function Solaris Thread Function

1 pthread_create() thr_create()

2 pthread_exit() thr_exit()

3

pthread_getschedpa

ram()

thr_getprio()

4

pthread_getspecifi

c()

thr_getspecific()

5 pthread_join() thr_join()

6

pthread_key_create

()

thr_keycreate()

7 pthread_kill() thr_kill()

8 pthread_self() thr_self()

9

pthread_setschedpa

ram()

thr_setprio()

10

pthread_setspecifi

c()

thr_setspecific()

11 pthread_sigmask() thr_sigsetmask()

12 sched_yield() thr_yield()

13

pthread_mutex_dest

roy()

mutex_destroy()

14

pthread_mutex_init

()

mutex_init()

15

pthread_mutex_lock

()

mutex_lock()

16

pthread_mutex_tryl

ock()

mutex_trylock()

Linux to Solaris 10 OS Migration Guide 16

Number POSIX Thread Function Solaris Thread Function

17

pthread_mutex_unlo

ck()

mutex_unlock()

18

pthread_cond_broad

cast()

cond_broadcast()

19

pthread_cond_destr

oy()

cond_destroy()

20

pthread_cond_init

()

cond_init()

21

pthread_cond_signa

l()

cond_signal()

22

pthread_cond_timed

wait()

cond_timedwait()

23

pthread_cond_wait

()

cond_wait()

The Solaris platform supports interprocess mutex locking and condition-variable

synchronization of resources. Apart from the POSIX specification, the Solaris OS also

provides a convenient read/write locking mechanism to control access to shared

resources.

However, some differences exist between the Solaris and the POSIX thread APIs. For

example, the following Solaris thread APIs are not supported by the POSIX API:

• thr_continue()

• thr_getconcurrency()

• thr_main()

• thr_minstack()

• thr_setconcurrency()

• thr_suspend()

Linux to Solaris 10 OS Migration Guide 17

Similarly, the following POSIX thread APIs do not have an equivalent Solaris thread

API:

• pthread_once()

• pthread_equal()

• pthread_cancel()

• pthread_testcancel()

• pthread_cleanup_push

• pthread_cleanup_pop()

• pthread_setcanceltype()

• pthread_setcancelstate()

However, both of the preceding sets of APIs can be safely used in the same program on

the Solaris OS.

Linux does not support shareable synchronization objects (mutexes, semaphores, and

conditional variables) that can be shared between different processes. Therefore, calls

to the following functions with a second parameter of PTHREAD_PROCESS_SHARED

will not work:

• pthread_mutexattr_setpshared

• pthread_condattr_setpshared

• pthread_rwlockattr_setpshared

Compatible Solaris and POSIX APIs -- Semaphores

For semaphores, both the Solaris OS and Linux provide POSIX interfaces. The Solaris

implementation is compatible with the POSIX implementation. On the Solaris side,

any one of the two sets of functions can be used.

Number POSIX Semaphore

Function

Solaris Semaphore

Function

1 sem_destroy() sema_destroy()

2 sem_init() sema_init()

3 sem_post() sema_post()

4 sem_trywait() sema_trywait()

5 sem_wait() sema_wait()

Linux to Solaris 10 OS Migration Guide 18

CHAPTER 4

Software Development Tools

Compiler Differences

It is interesting to note that the Solaris 10 release provides the GNU compilers and tool

chain as a part of the OS distribution. Sun Studio 11 development tools are also available

on the Solaris OS, and they are now available on Linux with no-cost licensing.

Thus both GNU and Sun Studio 11 tools are available to developers on both platforms.

However, traditionally Solaris developers have used Sun Studio compilers in the

Solaris environment, whereas most Linux programmers use GNU compilers. This can

cause some problems during the porting of an application. These compilers use

different command-line options to select different modes. No standard form of

command-line options exists, yet both compilers agree on the form and function of the

options shown.

Command-Line

Option

Description

-c Directs the compiler to compile, but not link

-o FILE Specifies output file

-I DIR Adds include search directory

-L DIR Adds library search directory

-lname Searches and adds a library with name libname.a

(or .so)

-Aname[(token)] Defines ISO C assertion

-Dname[=val] Defines preprocessor macro

-Uname Un-defines preprocessor macro

-g Directs compiler to emit debugging information

-E Performs only the preprocessing and writes the result

to standard output or to the file specified with -o

-S Instructs the compiler to compile, but not assemble, the

code

-w Inhibits printing warnings

Linux to Solaris 10 OS Migration Guide 19

For a list of differences in compiler command-line options, refer to Appendix A on

Compiler Options. For a list of linker options and their variations for the Solaris linker

and GNU, refer to Appendix B on Linker Options. Unless otherwise stated, the

command-line options are valid for all supported processors, namely SPARC, x86, and

x64.

Both the Sun Studio Compiler Collection and GNU compilers extend the C language.

The Sun Studio compiler uses #pragma for the extensions, whereas gcc uses the

<keyword> __<attribute>__ sequence followed by two open parentheses to

add information to a definition or declaration of an object.

GCC ignores the #pragmas option unless the -Wall option is used; in this case, it

only warns about ignored #pragmas. You should avoid using this language extension

convention since it can severely hamper code portability. Refer to Appendix C on

pragmas for a list of compatible #pragmas and <keyword> __<attribute>__

sequences. Appendix D shows the variations in the inline assembly facility as offered

in Sun Studio software.

Source Code and Version Control

In any major project involving large teams and large volumes of code, it is essential to

have a suitable, rather productive Software Configuration Management (SCM) in

place. It helps to introduce discipline into the practice of code change with appropriate

levels of version control, integrity, traceability, and accountability. In porting projects

it is equally desirable to have a SCM tool that is transparent to the platforms,

languages, and scripts used in the project. Some of the newer tools like Subversion and

Ant provide excellent opportunities for this.

However, in C/C++ applications developers still prefer to use traditional UNIX tools

like SCCS, RCS or CVS. Sun Studio software offers similar tools. We provide an

introduction to issues that you may face in source code control.

Source Code Control

Linux provides RCS (Revision Control System) for source code management, while

The Solaris OS provides SCCS (Source Code Control System). These packages

provide compatible functionality, yet use different formats for storing both code

changes and the commands to manipulate them. In order to port source code from one

system to another, you should extract the latest code from the Linux system, and then

transfer it into the Solaris system manually or using a customized script.

CVS (Concurrent Versions System) is the dominant open source network-transparent

version control system that can be installed on both the Solaris OS and Linux. CVS is

useful for individual developers as well as large, distributed teams. Appendix F

provides a list of common RCS commands and their mappings to SCCS and CVS.

Linux to Solaris 10 OS Migration Guide 20

CVS vs. RCS

RCS is simple to set up and is useful in small projects. By supporting the file-locking

feature, it does not allow multiple developers to modify the same file.

CVS builds on top of RCS and allows more flexibility than RCS. CVS is more

powerful and flexible than RCS, and CVS can support script usage to deliver any level

of file locking capabilities. The main intent of CVS is to provide a set of grouping

functions that allow you to treat a collection of RCS files as a single object. CVS

provides client-server support, and teams can use the same CVS repository from

different sites over a network.

Other features offered by CVS that are not supported directly by RCS include:

• Unreserved checkouts, which enables multiple developers to work on the same file

simultaneously

• Automatic importing of “vendor branches” from other source code control systems

and merging the changes

• Serialization of commits

In a Linux to Solaris porting project it is more likely that one will come across a situation

of migration of the repository from RCS to CVS. This task is relatively straightforward

as RCS files are directly supported as a part of the CVS repository. Much of

the migration effort revolves around structuring the repository, adding new files

required by CVS (modules, loginfo, and so on), and physically moving the RCS files

into the new CVS repository. To convert from RCS to CVS, one can follow these

steps:

1. Find all RCS files using the find command.

2. Create the appropriate CVS directories.

3. Copy each RCS file into a corresponding directory in the CVS repository.

More information on the use and documentation of CVS can be found at

http://www.nongnu.org/cvs/.

ForteTM Developer Code Management Software

This code management system is not formally a part of Sun Studio 11 software.

However, traditionally developers on the Solaris OS who prefer to use Sun-supplied

tools have been using the Forte Developer Code Management Software (formerly

TeamWare). This is a multi-platform software management tool set used by development

teams and allows for parallel development. In addition, it supports both an individual

developer environment as well as a full cluster environment. More information

on the deployment and use of the product can be had from a Sun document,

SPARCworks/TeamWare & ProWorks/TeamWare Solutions Guide, at

http://docs.sun.com/app/docs/doc/802-3637/6i7h52fqh.

Linux to Solaris 10 OS Migration Guide 21

Forte Developer Code Management Software is geared toward a collaborative development

environment. Files and directories facilitate code organization -- files are placed

in a special workspace directory and are accessible concurrently for modification.

Since traditional Solaris developers are familiar with Sun-supplied tools, their existing

Forte Developer Code Management software may be used in a project for porting to the

Solaris OS. However, please note that this code management software has reached its

End of Service Life.

Some of the essential details of this code management system are given below.

Configuration Management

General

• Supports public and private workspaces or views as configurations

• Workspaces are manipulated as standard UNIX directories and are

arranged in a hierarchy for simple organization, manipulation, and

management of data

• Workspace hierarchies can be closely mirrored to the file system structure

• Snapshot baseline of a workspace can be taken at any time

• Older file versions can be recreated from workspace baselines

• Descriptive workspace labels and a history file browser are provided

Release Management

• Manages multiple releases simultaneously

• Uniform workspace model is applied to the baseline, as well as patch

releases, to allow a standard approach to the release management

Integration Support

• Automatic tracking and handling of renamed files

• Conflict management and resolution for workspace configurations is

supported

• Configurable menus allow alternate views

• SCCS flags change features are included

Version Control

• Supports ASCII and binary files

• Graphical interface to view version history and perform file version

comparisons

• Compatible with SCCS development utility

• Check-out, edit, and check-in paradigms provided

Linux to Solaris 10 OS Migration Guide 22

Change Control

• Distributed repository model enables serial and parallel changes

• Branching allowing concurrent lines of development

• Three-way merger of two-file versions against a common baseline is

performed graphically

• Automatic merger of non-overlapping changes

• Custom change control policy enforcement enabled for workspace owners

through putback validation checking

• Undo transaction command to restore workspace to the previous state

Build Management

• Compatible with Solaris make and Forte Developer Code Management

Software build utilities

• Executes build jobs in parallel on multiple machines distributed on a network,

and provides visual review of the execution and completion status

System Administration

Security

• Cooperative access control for all workspace operations based on

a user or net group

• Access control specified per workspace

Backup/Restore

• Workspaces can be backed up or restored using standard Solaris

software administrative tools

Startup and Maintenance

• No system administrator required for startup or maintenance

• Easy incorporation of standard UNIX and SCCS files

• Conversion of RCS to SCCS

Interfaces

• Command-line interface

• Intuitive Motif GUI that supports drag-and-drop capabilities

• Easily able to register and launch other tools from the GUI

• User-specified text editor

Linux to Solaris 10 OS Migration Guide 23

Application Building

Make Files

Both the Solaris OS and Linux provide the make utility, which can be used to build

applications from its source files. The make utility works recursively on a makefile

that describes the relationship between the target file and its dependencies.

On Linux, GNU make searches for the makefile in the following order:

1. ./GNUmakefile

2. ./makefile

3. ./Makefile

In addition, GNU make implicitly can extract a file from RCS/SCCS directories if

necessary.

The Solaris make utility searches for the makefile in the following order:

1. Non-POSIX Mode

• ./makefile

• If .