Technical guidance from Solaris to Linux porting applications

zhaozj2021-02-16  103

Both Solaris and Linux have some relationships with UNIX, then there are many common situations? However, the fact is not the case - the difference between them leads to a lot of "gotcha" issues. Let us use this transplant technology to show you how to transplant the Solaris application to the Linux platform.

Transplant overview

The transplantation process itself is very simple:

1. Clean up code and header files and delete parts and non-standard practices related to the architecture.

2. Compile the code and correct the problem found during the compilation process.

3. If necessary, correct the paragraph failure and unlined access.

4. Re-build the code, if necessary, repeat the above process.

Transplant guidance

Porting Solaris applications require at least two platforms: a source platform and a (or more) Linux target platform. When you run the application to the Linux target platform, you should consider many factors:

Which Linux target platform is to be ported? For example, there are many hardware platforms support Linux, and the byte order is determined based on the target system (such as the number and the small number). Which Linux distribution and kernel version want to use? (Red Hat, TurboLinux, Caldera, SUSE, or other?) Linux target platform must support all hardware requirements? For example, is it necessary to rely on a third-party network card? Do you need to support network and storage needs? Do you have all required third-party packages (such as class libraries, application server tools, and application development tools on the Linux target platform? Does the target platform support the same (or compatible) version of these products? Does certain changes in the process of porting to the target platform? For example, is the application wants to change to another database system? Does 32-bit Solaris applications need to be ported to 64-bit Linux platform? Does the Solaris application use affinity processor sets? Solaris has kernel HOOK (a library) and a command line tool for assigning a process to a specific processor set. There is no comfort in linux. Do you need a separate public source code library? For example, do you need to support multiple platforms? It is understood that the application architecture will make the transplantation process. For example, it is a client / server model or an N-layer application component? You need to decide which software components are first transplanted.

If only hardware and operating systems have been changed, then you are truly transplant. You can use different ways to achieve your goals. The following option describes two steps of the migration method:

Option A: Because the SPARC platform also supports Linux, the modified code can be tested and executed on the SPARC platform before porting to the Linux target platform. You can get a comprehensive software for Solaris operating environments from Sun, which can provide interoperability and versatility in Linux and Solaris environments. Sun's development tool makes it easier to create a compatible source code and help to migrate extremely important utility code to avoid rewriting, and reduce installation time. This option helps Linux experience limited developers to transplant the Solaris source code to the Linux target platform. The following Web site provides the Solaris GNU tool: http://www.sun.com/solaris/freeware.htmlhttp://www.sunfree.com/ After building and tested the transplanted code, you can follow One option is to transplant the code to the Linux target platform. Option B: Migrate the code to the Linux target platform. Compare the test results with the Solaris platform to verify that the operation is correct. The modified code must be unrelated to the mantissa, or must be compiled with the condition to support the small tail platform. To start transplant, please check the Solaris source code carefully and test these code to ensure that it is running correctly. The inspection process should include complete compilation, reconstruction construction, and test cycles. In most cases, the code will be wrong on the Linux target system because the original source code is installed in the original source tree. Therefore, unless you have tested the code, you can't believe in the assertion that will usually hear when transplant ("it has no problem on the source system!").

The following references also help you carry Linux transplantation:

Solaris transplant guidance article written by Malcom Zung and Brian Thoma, it is: IBM.com/developerWorks/library/l-solar/ red Hat Solaris-To-Linux Porting Guide is a good summary of transplant information, It is located in: http://www.redhat.com/devnet/WhitePapers/Solaris_Port/book1.html About the Zseries platform PORTING UNIX Applications to Linux, it is: ibm.com/servers/eserver/zseries/library/techpapers/ GM130115.html

Transplantation process

The following recommendations are not the only way to transplant the Solaris application to the Linux environment. You can use your own transplantation to build your own migration.

Choose a transplant development platform

SPARC platform: This approach allows Solaris developers to easily implement migration and transplant Linux applications on other target platforms. Because Sun provides a public library and build environment, it will develop the source code of the source code compatible in the Linux and Solaris operating environment, so the first step is to modify the transplant code on the Solaris platform. These tools include the following guidelines:

How to identify the difference between the library calls that may occur in the C / C source code. How to convert the shell script. How to recreate Linux system configuration data under Solaris. For more information, see: http://www.sun.com/software/linux/compatibility/ultralinux/

After testing and building a Linux application on the Solaris platform, you can port to the Linux target platform. This method has the following advantages:

It minus changes, so that these changes are more likely to understand, easier to manage, and more easily promoted. It minus the number of new problems generated during the transplantation. Each change has corrected a known issue. Linux Target Platform: Experienced Linux Developers can modify the code to be transplanted on the Linux target platform. You need to make sure the correct version of the library and compiler, such as GCC, TCL / TK, GLIB, GNOME, and KDE.

Use grep command

After determining the transplant development platform, you will need to search for the following, which may result in a transplant problem in the source code:

Regular expression Printf, sprintf, scanf, and SSCANF routines macros may change the structure of data and joint #Else .... #ENDIF statement system header files (such as limits.h, types.h, etc.)

After searching for issues that may be generated, you need to decide whether you want to keep a separate source code base to support multi-platform (Solaris, Linux, and other platforms).

Find a potential problem

After using the GREP command, you also need to check if there is low efficiency or irresolute code. The following list can help you find a transplant question:

Find out source of source code and are not compatible in the library. Implement more stringent type inspection rules than compilers. Find potential issues related to variables. Find potential issues related to functions. Find out problems related to process control. Find out legitimate structures that may generate errors or reduce efficiency. Find out unused variables and function declarations. Find out that there is a possibility that you may be portable.

Transplant tool

The following tools are already available, or among the development:

Porting Manager is a Perl script that accepts the source tree as an input. It scans C / C code to find the API only for Solaris and tag them out. It also provides a document that describes how to transplant the Solaris API to Linux with its fairly API. The scanning process is based on a table (the tool provides the table and tag of the API to check). It will generate a list of APIs to check. It also checks the header file and some compile instructions (PRAGMA). The transplant manager has a GUI front end, because it is written in Perl, so it is possible to run on Solaris and Linux, which is estimated to run on any platform running in Perl. The developerWorks Solaris-To-Linux Migration Tool is a web application that checks how the API used by the Solaris application is compatible on Linux. The following Web site provides access to the web application tool: ibm.com/developerworks/linux/tools/l-solar.html Migratec Transplant Set by Migratec, this company specializes in migrating applications between platforms . The transplant set includes Migration Workbench, which provides a complete API mapping from Solaris to Linux: http://www.migratec.com/migratec/migration_suite.htm

Fixed the problem when compiling

Usually, it is necessary to repeat several times to compile the code without problems. Make sure to use the -wall option to capture all warning messages.

Test and debugging procedure

You can use the GDB tool to debug the modified code. To learn more about GDB, see the GNU GDB debugger.

Compare Linux and Solaris

This section will discuss the catalog, file system, signal, mantissa problem, system-derived data type and absolute address.

table of Contents

The structure of the Linux directory is standardized. Each directory has a defined task. Typical Solaris and Linux installations will create the directory shown below: Solaris directory function Linux directory function / bin user command. / bIN contains the binaries required after the normal user starts and after the startup. / Boot contains the files needed to start the LILO boot program that starts the startup process. The kernel file resides in / boot. / DEV contains symbolic link entries in / devices, most of the real device entries are created in / devices. / DEV contains real blocks, characters, and other device files, such as FD0 (first floppy drive) and HDA1 (first partition on the first hard drive). / Devices should create an entry in this directory for each real device in the system. / Etc Other commands, network configuration files and scripts, etc. / etc reserve a configuration file belonging to the machine itself. There is no binary file in / ETC. The X-Windows Profile XF86Config is stored in / etc / x11. / HOME is usually used as the user's home directory. / HOME is usually used as the user's home directory. / kernel contains the kernel module. The corresponding kernel file is in / boot and / lib module. / OPT application package. / Platform Specific over the platform UNIX and device drivers for start-up. / PROC contains information about the active process and threads, and provides an interface to control these processes and threads. Each process directory has some file entry, which contains the kernel structure of the process. / PROC contains a file system view that deep into the kernel. For each process, there are multiple directorys, in addition, there is also a directory and file corresponding to the system counter and limit. / Lib only contains libraries that need to perform binary files in / bin and / sbin. / lib / modules contains the loadable kernel module. The / Lost & Found / MNT system administrator conducts the installation point used by the temporary installation. / Root This is the main directory of the root user, in addition to the root user's profile information, there is usually no important files. / sbin system control command, such as Mount and Umount. / SBIN is only used by the ROOT user, but only the executables that need to install / usr and perform system recovery operations. / TMP is also a special file system that maps to system memory. / TMP is the same as the Solaris system, the USR compiler, management properties. / USR Most application software installation location. / Var includes LPD and Mail Spool. Also used by various applications (such as system messages) that require recording log files (such as system messages). / Var includes LPD and Mail Spool. It is also used by various applications that need to record log files.

File system

Linux can use several types of file systems. Each file system has its own format and a set of features (such as file name length, maximum file size, etc.). Linux also supports several third-party file system types, such as MS-DOS file systems. The table below lists various file system types that Linux can use:

Third Extended Filesystemext3fsext2fs file system type name Comment Second Extended Filesystemext2fs most common Linux file system journaling file system Extended Filesystemext has been replaced Minix Filesystemminix earliest Minix file system ext2fs Xia FilesystemXia with ext2 similar UMSDOS Filesystemumsdos used on DOS partition LinuxMS -DOS Filesystemmsdos using the MS-DOS file processing tp / proc Filesystemproc system V Filesystemsysv information providing system for read-only access access systems VHPFS FilesystemhpfsHPFS Journal partition has Filesystemjfs logging file system ReiserFS FilesystemreiserFs using classical balanced tree (balanced tree) algorithm The most common file system type of the above variable is second extended filesystem, or EXT2FS. EXT2FS is the most effective and flexible file system; it allows file names to last 256 characters, and the file system size can reach up to 4,000 megabytes. You can also upgrade EXT2FS to EXT3FS. You can find which file systems currently supported in your kernel in the / proc / filesystem directory.

Byte order problem

The SPARC architecture is BIG Endian (BE), which has a forward byte order. The 0th is the least important bit, while the 0th byte is the most important byte. Note that when transplant from Solaris to PSeries or IBM EServer ZSeries, byte order issues do not have an impact because they are BE platforms. The Intel X86 architecture is Little Endian (le), so the 0th byte is the least important byte (LSB). Figure 1 illustrates the byte order of the BE and Le Expression:

Figure 1. Dadi and hidth addresses

Data type does not match

When the 4-byte integers are treated as an integer data type, Le and BE are viewed in the opposite direction to view the individuals and bytes in the integer.

INT A = 0x11121314; Char B, * PTR; PTR = (char *) & a; // Pointer PTR Points to a b = PTR [1]; // b IS 0x13 in le and 0x12 in be

Use solutions that are unrelated to the mantissa can solve the byte order of the LE and BE.

#define intb16to23 (a) ((a >> 16) & 0xff) B = INTB16TO23 (a); // b IS 0x12 in Be and LE

Telecommunication

If you want to transfer the multi-byte value between the BE and LE systems, then what we have to do is just the code to exchange bytes. For network communication, functions such as htons () and ntohs () are also used to convert port numbers to network byte order.

Common mandate solution guide

Use solutions that have nothing to do with the mantissa to solve data types do not match problems. Use macros and instructions. To make the code, you can use the following macros and condition compile instructions: #define big_endian 0 #define Little_endian 1 #define Byte_Order Big_endian uses the compile time option. Another option that implements this is the value of the BYTE_ORDER in the compilation command line. You can only change your Makefile to build an application, or you can use the GCC Compilation option to select the right-specific code snippet.

signal

Linux accepts four defaults as signals: ignore, stop processes, termination processes, or generating core dumps after terminating processes. Linux supports almost every signal provided by System V, BSD, and POSIX, except for the following special circumstances:

SiGEMT, SIGINFO, and Sigsys are not supported. SigabRT is the same as SIGIOT. SIGIO, SigPoll and Sigurg are the same. Sigbus is defined as SIGUNUSED. From a technical point of view, there is no "bus error" in the Linux environment.

The following Web site provides more details about Linux signals: http://www.linux-mag.com/2000-01/Compile_01.htmlhttp: //www.linuxhq.com/guides/lpg/node138.html % 20-% 20section00112000000000000000000

Note: POSIX.1 only defines SA_nocldStop. When porting an application using a signal operation, you may have to modify the value of sa_flag to get the right behavior.

Solaris has SIG2STR () and STR2SIG () APIs, which are used to switch back and forth in signal names between signals and strings. Because Linux does not support these APIs, the following code does not work on transplants:

#include #include #include int main (int argc, char ** argv) {char sign [SIG2STR_MAX]; SIG2STR (atoll (ATOLL (Argv [1]), SIGNAME ); Printf ("Received Signal =% S / N", SIGNAME); RETURN 0;}

Here is the correct code for transplanting to Linux:

#include #include #include int main (int Argc, char ** argv) {const char * str int signo_ = atoll (argv [1]); str = SYS_SIGLIST [SIGNO_]; Printf ("Received Signal =% S / N", STR); RETURN 0;}

The following table lists the signals commonly used in the Solaris and Linux operating systems.

SolarisSolaris default action LinuxLinux default termination of operations SIGHUP SIGHUP ignored SIGINT ignored SIGINT terminate SIGQUIT termination, termination SIGQUIT core, core SIGILL termination, termination SIGILL core, core SIGTRAP terminated core SIGTRAP ignored SIGABRT termination, termination SIGABRT core, core SIGEMT termination, the core SIGEMTLinux not support SIGFPE terminated core SIGFPE terminated core SIGKILL to terminate SIGKILL to terminate SIGBUS terminated core SIGBUS terminated core SIGSEGV terminated core SIGSEGV terminated core SIGSYS termination, does not support the core SIGSYSLinux SIGPIPE terminate SIGPIPE ignore SIGALRM terminate SIGALRM ignore SIGTERM termination SIGTERM termination SIGUSR1 terminate SIGUSR1 ignored SIGUSR2 termination SIGUSR2 ignored SIGCHLD ignored SIGCHLD ignore SIGPWR ignored SIGPWR ignored SIGWINCH ignored SIGWINCH process stops SIGURG ignored SIGURG ignored SIGPOLL termination does not support SIGSTOP process stops SIGSTOP process to stop SIGSTP process to stop SIGSTP process stops on SIGPOLLLinux SIGCONT ignored SIGCONT ignored SIGTTIN the process stops SIGTTIN process to stop SIGTTOU process to stop SIGTTOU process stops SIGVTALRM terminate SIGVTALRM termination, the core SIGPROF termination SIGPROF ignored SIGXCPU terminated core SIGXCPU terminated core SIGXFSZ terminated core SIGXFSZ termination, does not support the core SIGWAITING ignored SIGWAITINGLinux SIGLWP negligible support SIGFREEZE on SIGLWPLinux Ignore Sigfreezelinux does not support Sigthaw ignore SigThawlinux does not support Sigcancel ignore Sigcancellinux does not support SigrtMAX Termination SigRTMINLINUX does not support SigrtMax termination SigrtMaxLinux does not support system derived data types.

The system-derived data type can have different bytes. The derived data type is the type of derived type defined by typedef, or with a type defined by a known basic type. The following sections will compare the data types of the most common system derived in Solaris and Linux.

Data type GID_T, MODE_T, PID_T and UID_T data type GID_T is used to represent the user's group ID, and UID_T is used to represent user IDs. Data type mode_t is used to represent the mode of the file, and the PID_T is used to identify different processes in unique numbers.

OSgid_tmode_tpid_tuid_tSolarislongunsigned longlonglongLinuxunsigned intunsigned intintunsigned int Size_t, ssize_t and wint_t ssize_t and data types should be combined size_t size of memory to use the object, and returns the byte count or an error indication. When the program uses multiple bytes and wide character subroutines, data type WINT_T is required to indicate wide character code values ​​and file tail marks.

Ossize_tssize_twint_tsolarisunsigned intintlonglinuxUnsigned longintunsigned int INT

Absolute address

Each platform may use different memory locations to store program stacks, system libraries, stacks, and more. Therefore, it is difficult to ensure portability of other systems using hard-coded addresses. Some addressing methods also ignore high-class, so hard-encoded addresses 0x80000000 (high order 1) will be converted to 0x00000000, which is likely to be illegal, and it is definitely not what you want. When generating an address, the arithmetic operation of the address can also make the high order position to 1. If the application uses an absolute address that causes a segment conflict or other errors, then it must be changed. / Proc / / MAP will show how an active process uses the storage range of its internal address space. If the code must use an absolute address, then this MAP can be used to find the range of addresses that have not yet been retained.

Some application development tools

C / C application infrastructure

Operating System Red Hat Linux V7.1 SUSE V 7.2 (Intel) Runtime Library GLIBC V2.2

Use of C / C application tools

IBM WebSphere Studio Application Developer Rational RoseIDE analysis and design with C / C plug-in Metrowerks CodeWarrior lower edit / compile / debug GNU Compiler Collection V3.0 GNU GDB Debugger V5.0 Insure V5.2 build GNU make V3.79 Automake package RPM V4.02 Test Dejagnu Tetware Professional v1.3 Performance Tuning and Benchmark GNU Profiler V2.9.1 LMBENCH Source Code Management Rational Clearcase Accurev / CM V2.6 RCS and CVS Maintenance and Fault Detection Rational Clearquest Client Gnats v3.113 bugzilla

Usage of Java application tools

Analysis and Design Rational Rose, ObjectDomain 2.5ide Idera Jsync 1.50 Anyj Netbeans Developer 2.1 Source NavigatorJVM Sun JVM IBM JVM Compiler JIKES Performance Tools Optimizeit Source Management Rational Clearcase Maintenance and Fault Detection Rational ClearQuest Client

Solaris Make to GNU Make

Solaris Make and GNU Make define the same basic suffixes and implicit rules. The following goals, macros, and variables are the same:

Goal: .default,. Ignore, .precious, .silent and .suffix internal macros: $ *, $%, $?, $ @, $$ @, $ (f) and $ (d) predefined Macro: Ar, AS, CC, LD, LEX, LINT, M2C, PC, RM -F and YACC environment variable: Makeflags variable: CC, CFLAGS, CPPFLAGS, FC, FFLAGS, LEX, LFLAGS, YACC, YFLAGS, LD and LDFLAGS

Note: GNU Make does not fully support%. Only the first% will be replaced.

Below is an example:

#Begin makefile foo = Abc def bar = $ (foo:% = DIR1 /%. O DIR1 /% _ CLTN.O) BAR2 = $ (foo:% = DIR1 /%. O) $ (foo:% = DIR1 /% _Cltn.o) All: @echo foo is $ (foo) @echo bar is $ (bar) @echo bar2 is $ (bar2) #END Makefile On Sun, the board command will print:

Foo Is Abc Def Bar IS Dir1 / Abc.o Dir1 / Abc_Cltn.o Dir1 / Def.o Dir1 / Def_Cltn.o Bar2 IS Dir1 / Abc.o Dir1 / Def.o Dir1 / Abc_Cltn.o Dir1 / Def_Cltn.o

On Linux using the GNU, the board will print:

Foo IS ABC DEF BAR IS DIR1 / ABC.O DIR1 /% _ CLTN.O Dir1 / Def.o Dir1 /% _ CLTN.O Bar2 IS Dir1 / Abc.o Dir1 / Def.o Dir1 / ABC_Cltn.o Dir1 / Def_Cltn.o

In order to solve this problem, you need to modify the code as shown below:

BAR = $ (foo:% = DIR1 /%. O) BAR = $ (foo:% = DIR /% _ CLTN.O) bar2 = $ (foo:% = DIR /%. O) bar2 = $ {foo :% = DIR1 /% _ CLTN.O)

Make's suffix

Make's own built-in suffix rules allow developers to greatly simplify Makefile. The following single-enclosed and double suffix table contains the default reasoning rules for the Solaris and GNU Make commands.

Single suffix reasoning rules

Suffix Make Single Suffix Rules. Csolaris $ (CC) $ (CPPFLAGS) $ (LDFLAGS) $ @ $ <$ (ldlibd) GNU $ (CC) $ (CFLAGS) $ (LDFLAGS) $ (TARGET_ARCH) $ (LDLIBES) $ (LDLIBS) -O $ @. Csolaris $ (CCC) $ (CPPFLAGS) $ (LDFLAGS) -O $ @ $ <$ (ldlibs) GNU $ (CXX ) $ (CXXFLAGS) $ (LDFLAGS) $ (TARGET_ARCH) $ (LDLIBES) $ (LDLIBS) -O $ @. CCSolaris $ (CCC) $ (CPPFLAGS) $ (LDFlags) - O $ @ $ <$ (ldlibs) GNU $ (CXXFLAGS) $ (CPPFLAGS) $ (LOADLIBES) $ (LDLIBES) $$ @. Fsolaris $ (FC) $ (fflags) $ (LDFLAGS) -O $ @ $ <$ (ldlibs) GNU $ (FFLAGS) $ (LDFLAGS) $ (LDLIBES) $ (LDLIBS) -O $ @. Fsolaris $ (FC ) $ (FFLAGS) $ @ $ <$ (ldlibs) GNU $ (FC) $ (LDFLAGS) $ (TARGET_ARCH) $ (LDLIBES) $ (LDLIBS) -O $ @ .MODSOLARIS $ (M2C) $ (M2FLAGS) $ @ -e $ @ $ $ @ @ gnucat $ @ c @ g x $ @ 双 后 后Reasoning rules

The suffix make Double Suffix Rule. C. OSolaris $ (CC) $ (CFLAGS) $ (CPPFLAGS) -C $ (Output_Option) $ $ @ GNU @ $ (r) $ (lex) $ (lflags) -t $ <> $ @. L.lnsolaris $ (rm) $ *. C $ (lex) $ ( LFLA GS) -t $ <> $ *. C $ (LINTFLAGS) $ (CPPFLAGS) -O $ @ -i $ *. C $ (RM) $ *. C GNU @ $ (rm) $ *. C $ (lex) $ (lflags) -t $ <> $ *. $ (CPPFLAGS) $ (Target_arch) -i $ *. C -O $ @ $ (r) $ * .c.Mod.OSolaris $ (M2FLAGS) $ (M2FLAGS) -O $ @ $

.y.csolaris $ (YACC) $ (YFLAGS) $ (YFLAGS) $ (YFLAGS) $ @. Y.Lnsolaris $ (YACC ) $ (YFLAGS) $ (Lintflags) $ (CPPFLAGS) -O $ @ -i y.tab.c $ (rm) Y. Tab.c Gnu $ (YACC) $ (YFLAGS) $ $ (LINT) $ (LINTFLAGS) $ (TARGET_ARCH) -C $ * Y.TAB.C $ (RM) Y.Tab.cc Compiler Options

Sun Workshop (Forte) Compiler and GCC support extended C language. The SUN Workshop compiler is almost equivalent to GCC. The form of extended compilation indication is unique. GCC usually does not use compilation instructions, but when the -wall option is used, it will warned to ignore the compile instruction.

The -m486 option on the GCC is used to compile the X486 machine's binary, which will only change some specific optimization. There is a version of GCC to be well optimized for 586, but it is very unreliable, especially when setting in high optimization. For Pentium GCC, see:

FTP: / /TSX-11.Mit.edu/pub/linux/alpha/pentium-gcc/.

For PSeries and RS / 6000, the "-MCPU" option will be disabled "-mpower" or "-mpowerPC" option. Our recommendation is to use the default "-MCPU = Common".

For SPARC, use the "-mcpu" option to select the architecture for the machine type.

The GNU C library also has a thread awareness. When you link to thread processing libPthread (with GCC command line parameters pthread), some functions in libc.so will be overwritten by the function in the thread tension library.

The table below contains the common options for the C compiler on the Solaris and GNU GCC.

Sun WorkshopGCC Description - # - V Opens detailed mode, displaying each called component. -Xa-ANSI specifies compatibility with ANSI / ISO standards. GCC supports all ISO C89 programs. You can use "-std" to specify special versions of ISO C. -xinline-finLine-functions is only inserted into those specified functions. -p -p generates additional code to write profile information that applies to the analyte profile. -xa-AX generates additional code, used to write profile information of the basic block, record the number of times each basic block being executed. -xspace-o0 does not optimize. -xunroll = -finroll_loops Only the number of iterations can be looped when cyclic up to cycles when compiling or runtime. -XTARGET = Name-b = Machine Parameter Machine Specifies the target machine to compile. In addition, each target machine type here can have its own special options, starting with "M", selecting in various hardware models or configurations. -XO-O, -O1, -O2, -O3, -OS control various optimizations. -O controls various optimizations. -xmaxopt ensures that GCC does not use compilation instructions. -xnolib-Nostdlib defaults to any library. -FSINGLE-FSINGLE-Precision-Constant treats floating point constants as single precision constants, rather than implicitly converting it to double precision. -C-c tells the pre-processor not to discard the comment. Working with the "-e" option. -Xtrigraphs-Trigraphs supports ISO C Trigraph. -E-E prepresses all specified C source files and outputs the result to a standard output or specified output file. -XM-M only runs the pre-processor on the specified C program, requiring the Makefile dependence information and sends the result to the standard output. -XPG-PG generates an additional code to write profile information that applies to the analyte gprof. -c-c Command Compiler Do not link with LD and generate .o files for each source file. -o-o Named Output File. The -s-S command CC generates a set source file but does not assemble the program. -XTemPTMPDIR If a TMPDIR environment is set, you specify the directory to use for a temporary file. -xhelp = f-HELP displays online help information. -Xtime-Time Reports the CPU time used by each child process in the compilation sequence. -w-q prohibits compiler warning. -rroff =% NONE-W Displays a warning message. -rrwarn-Werror converts all warning messages into error messages. Link program call

SUN and GNU linkers are accepted as many options. The table below explains the most common options for the SparcWorks link program with the function of the GNU linker.

Solaris WorkshopGLD Option Description -A-Static Enables default behavior of static mode to prevent links to the shared library. The linker creates an executable file and an undefined symbol that causes the error message. The GNU LD has the -static option, which can also enable this behavior. -b Do not compile the source code without the -fpic / -fpic option, thereby implementing the same functionality of the GNU link program. -g-g generates debugging information in native format of the operating system. -G-shared generates a shared object. The same is -shared with the GNU linker. -m (-m) Print link program mapping. -M option prints some things that can be compared, just their format, and the content is slightly different. -S-S / -S uses the GNU link program-S (it only deletes debugging information), implements the same effect as the -s option. -h name-Soname Name sets the name to the name of the shared object. If you use the GNU link, you must use the -soname option. -o filename-o FileName places the output in the file. Regardless of the type of output generated, it applies. The default is to place the executable in "a.out". -L Directory-LDIR Adds the directory DIR to the list of directory. -R path-rPath path Specifies the search direction of the runtime link. The GNU linker uses the -rpath option. Each Linux shared library is assigned a special name called Soname, which includes the name and version number of the library. Do not link to libraries outside of specific versions unless you have special reasons. Typically use the standard -l libName option for the C compiler or link program. The linker will look for file lib libli, which is a symbolic link to the correct version of the library.

GCC options specific to PSERIES and RS / 6000

Option Description -FPIC generation and location-independent code (PIC) in order to use in the shared library. -mpower, -mno-power, -mpowerpc, -mno-powerpc, -mnpowerpc64, -mno-powerPC64 Specifies that the GCC will generate instructions for various architectures. -mcpu = CPU_TYPE Sets the architecture type, the registration program, the selection of the help notes, and the command scheduling parameters of the specific machine type. -mtune = CPU_TYPE Sets the command scheduling parameters for a particular machine type. -mlittle compiles the Power PC processor's code with a small mantle mode. -MBIG compiles the Power PC processor's code with a large mantissa mode. -mcall-linux compiles the Power PC's code based on Linux-based GNU system.

Solaris Thread Library (STL)

Applications written for Solaris often use non-standard proprietary functions, which makes it difficult to transplant Linux. A temporary STL is supported on the Linux (Intel platform), which will reduce the trouble of migrating these applications. It provides the implementation of the Solaris thread API based on the POSIX thread library. STL is a component of the Solaris Compatibility Libraries, SCL, and you can get this part of the SCL free of charge by open source. You can get it from the SourceForge project initiated by Compaq, this project is:

http://sourceforge.net/projects/sctl

limitation

SCL STL does not support the following features:

Replication of each thread when the support of the system-level synchronization object

To allow developers to use STL libraries, you need to pay attention to thread limitations and problems. For example, the POSIX thread's suspend and thread continues to be supported. A article entitled "Building An Open-Source Solaris-Compatible Threads Library" (Proceedings of The Freenix, June 2001) contains more details and implementation. You can get the copy from the following Web site: http://www.opensource.compaq.com/the_source/linux_papers/scl_solaris.htm

We want future Linux version STLs to support other Linux target platforms (RS / 6000, Power PC, etc.).

System interface

Below this section will discuss the application of the thread in Solaris, using the POSIX thread's application, the Solaris thread library, and POSIX thread library, and support for interfaces and definitions.

Application of threads in Solaris

The application using the Solaris Thread Programming Interface (API) is basically unmiglable, such as THR_CREATE (), Mutex_lock (), COND_SIGNAL (), and more. The main aspects of the Solaris thread function not supported in the POSIX thread are:

Daffening Thr_create Add to any thread (Solaris allows you to add any thread with TID 0) Thread Publishing and Thread Continue

If you need to satisfy any one of the previously described, it takes a certain degree of work to port if the application using the Solaris thread is required. Otherwise, the mapping between the Solaris thread API and POSIX thread API is very simple.

We do not recommend that you mix the STL with the POSIX thread API. If possible, you should use the locale because it will allow you to maximize the thread.

The table below will compare the Solaris thread API and POSIX thread API.

Solaris Thread APILINUX POSIX Thr_create () pthread_create () Creates a new control thread. THR_EXIT () PTHREAD_EXIT () Terminate the execution of the call thread. THR_GETPRIO () pthread_getschedparam () retrieves the priority parameters of the thread. Thr_getspecific () pthread_getspecific () Binds the newly thread-specific value to the key. THR_JOIN () pthread_join () Tempse Thread until the end of the target thread. THR_KEYCREATE () PTHREAD_KEY_CREATE () Creates a key to locate the threaded data. THR_KILL () pthread_kill () sends a signal to another thread. THR_SELF () pthread_self () Returns the thread ID of the process that is called. THR_SETPRIO () pthread_setschedparam () Modify the priority parameters of the thread. Thr_setspecific () pthread_setspecific () Binds the newly threaded value to the key. THR_SIGSETMASK () pthread_sigmask () changes or checks the signal mask of the calling thread. THR_YIELD () SCHED_YIELD () makes the current thread to another thread. THR_SETCONCURRENCY () PTHREAD_SETCONCURRENCY () Sets the thread concurrency level. THR_GETCONCURRENCY () pthread_getconcurrency () Gets the threaded concurrency level. THR_SETSPECific () pthread_setspecific () Sets the data key specific to the thread. THR_GETSPECific () pthread_getspecific () Gets threaded data keys. THR_SUSPEND does not support execution of the suspended specified thread. THR_CONTINUE does not support recovery of the execution of the suspended thread. Note: The POSIX standard does not provide any mechanism that causes thread A to hold thread b in the case where the thread b is not cooperated. The only way to achieve a suspended or restart mechanism is to let the thread b periodically check a global variable, find the suspended request, then hung yourself when you find the condition variable (another thread can send a signal after this, Restart B).

Application of POSIX threads in Solaris

The application of the POSIX thread in Solaris is easy to transplant to Linux, just some exceptions in the process sharing feature.

Comparison of Solaris Thread Library and POSIX Thread Library

Linux supports POSIX 1003.1C. Solaris supports both POSIX 1003.1c and supports proprietary signal APIs. The following table is compared to the POSIX 1003.1C API implemented in the proprietary Sun routine and Linux.

One of the main differences between Solaris and Linux interfaces is that Solaris defines these functions in libthread, and Linux defines these functions in LibPthread.

Solaris library (LIB thread) Linux POSIX library (LIBP thread) Operation SEMA_DESTROY () SEM_DESTROY () destroy the signal state. SEMA_INIT () SEM_INIT () initialization signal. SEMA_POST () SEM_POST () adds signals. SEMA_WAIT () SEM_WAIT () blocks the signal count. SEMA_TRYWAIT () SEM_TRYWAIT () reduces signal counts. Mutex_destroy () pthread_mutex_destroy () destroys or disables the status of the mutual exclusive object. Mutex_init () pthread_mutex_init () initializes the mutex. Mutex_lock () pthread_mutex_lock () locks the mutually exclusive objects and blocks until the mutual exclusive object is released. Mutex_unlock () pthread_mutex_unlock () releases the mutex. COND_BROADCAST () pthread_cond_broadcast () Releases the blocking of all threads. COND_DESTROY () pthread_cond_destroy () destroys any status associated with the conditional variable. COND_INIT () pthread_cond_init () initializes the condition variable. COND_SIGNAL () pthread_cond_signal () Release the blocking of the next thread waiting for the conditional variable. COND_WAIT () pthread_cond_wait () blocks the condition variable and releases it at the end. Rwlock_init () pthread_rwlock_init () initializes the read / write lock. rwlock_destroy () pthread_rwlock_destroy () Locks the read / write lock. Rw_rdlock () pthread_rwlock_rdlock () reads the lock on the read / write lock. RW_WRLOCK () pthread_rwlock_wrlock () writes the lock in the read / write lock. RW_UNLOCK () pthread_rwlock_unlock () Releases the read / write lock. RW_TRDLOCK () pthread_rwlock_tryrdlock () reads the lock on the non-block read / write lock. RW_TRLOCK () pthread_rwlock_trywrlock () writes the lock in non-block read / write lock. To use the POSIX thread's READ / WRITE LOCK extension, you must define when compiling:

_Xopen_source = 500

It is necessary to complete before joining the header file, but also define:

_POSIX_C_Source = 199506L

Linux threads do not implement mutual exclusion, conditions, and signals of shared processes. The purpose of this extension is to allow different processes (processes with different address spaces) å æ æ æ æ, 分 分 分 分 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同 同For example, if pthread_mutex_attr_setpshared, pthread_rwlockattr_setpshared, pthread_condattr_setpshared is set in PTHREAD_PROCESS_SHARED in PTHREAD_PROCESS_SHARED, the call to these functions will fail.

When migrating from the platform of support with these function sharing processes, if a pthread_process_shared flag is set, you must override the application because if you use this flag in the above functions, the Linux kernel will return -1. For signals and condition variables of mutual exclusion and simple lock / unlock types, PTHREAD * calls may have to be replaced by code written by the user. Before you get the right Linux kernel support, you should use traditional interactive process communication to synchronize different processes: System V signal, message queue, pipeline or socket. Support for interfaces and definitions

Linux is written using the interface and defined hierarchy. Use the default interface _GNu_Source, the application can take advantage of all the compiler features. This gives the most convenient programming environment. The following macro is required in a consistent environment:

_Posix_source _xopen_source _posix_c_source _Unix_std

Other tips and skills

Below is some useful information that did not talk in the previous section.

Make's syntax

Always enter a tab at the beginning of the command, not a few spaces. Do not use tabs before any other row. If you use a space to use a tab, or if you have a reveilized thing, Makefile will not work.

Use the GCC FPIC logo instead of the -fpic flag.

-fpic logo will generate a code-independent code that can be linked and loaded at any address.

GCC Dependency tools used to generate makefile information

-M generates Make dependencies. -Mm is similar to -m, but ignores the system header file. -Md is similar to -m, but puts the output in the A.D file. -Mmd is similar to -md, but ignores the system header-mg treats the lost header as the generated file.

Options that do not use LD for links

Just use the compiler front end to link:

GCC -O Progname foo.o bar.o main.o

The GCC front end will insert all correct modules to make the appropriate link. Adding the -v parameter also allows you to see the details of the GCC operation.

Check the dynamic load library

Use LDD to call executable; it dumps dependency information for these files.

Use ld_library_path

Linux systems are only searching / lib and / usr / lib over the default. If you are linked to a library that is shared in your program, you will not find these libraries, and the system will refuse the program.

One practice is to use the -w1, -rpath option when the link program is time. Another approach is to set the LD_Library_Path environment variable when running the program.

Memory allocation

Malloc () should always be used to perform memory allocation, rather than using other system calls.

LIBSocket lost in Linux

For Solaris, Makefile contains the -lsocket library sign, but there is no libsocket in Solaris in linux. *. There is no need to link any specific libraries because they are automatically linked. Just take the -lsocket to take it out of Makefile.

Avoid incorrect reference symbols

A common error is to compile the program with an apostrophe (') instead of the back point (`). You can enter (`) as long as you press the key on the left of" 1 ". for example:

GCC-Wall -o Intro INTRO.C `gtk-config -cflags -libs`

Static link some libraries, and dynamic links Other libraries

Please use the following: gcc -o some-program some-program.c-xiinker -bstatic -llib1 -lib2 -Xlinker -bdynamic -llib3

Hard coded constant

Avoid hardcoding the size of the data type; but should use sizeOf (). Please avoid hardcoding constants using malloc (). Please use SIZOF (Void *) to get the appropriate pointer size.

Data alignment

Most processors require data items in each memory to perform data alignment in 2 bytes, 4 bytes, or 8-byte boundaries; otherwise the processor must perform multiple read operations, resulting in performance degradation, or have to cause hardware Abnormal, allowing the operating system to process, resulting in additional performance degradation.

In order to solve this problem, the GCC compiler adds a padding byte (called fill, padding) in front of each without alignment, ensuring that alignment is performed in the correct boundary. Although the filler by the compiler is invisible in the application code, they do exist, and the data structure layout in the memory is also different from the expected.

Transplant thr_suspend

Please note that thr_suspend () has always been very dangerous, it is easy to cause contention. First, we cannot control the target thread where the target thread is really stopped: even if there is mutual exclusive, it is likely to stop in the middle of the critical section. For these reasons, you should not use mutual exclusion, and the conditions are used.

Compliance with ANSI

The following example is with code that does not conform to ANSI, but examples can run in the Solaris Forte compiler:

Const reference

#include Class test {public: // use a constant ref. to a variable whose value can be change Void Test1 (COUT << newEvent << endl;}; {Test T; char * const ptr = "a"; T. Test1 (* PTR); Return 0;}

If you compile with G , you will get the following error:

Error "Discarding" const "Applied to a reason"

Const Char & is a reference for constant values; CHAR Const & reference is constant, but referenced is not constant.

Here is the correct code:

Void Test1 (Char const1) {cout << newEvent << endl;};

Unselected reference

The following code sample contains an undefined reference:

Error "ANSI C Forbids Declaration 'Abc' with no type" error "(s) undefined reference to a :: x" #include class test {public: a (int in) {x = q;} ABC (intc) Y); private: static int x;}; A :: ABC (INT Z) {cout << z << endl;} int main () {a test (10); test.abc (20); returnograph; }

Here is the correct code:

#include class test {public: a (int} {x = q;} int abc (int y); private: static int x;}; int A ;; x = 1; int A :: ABC ( INT Z) {cout << z << endl;} int main () {a test (10); test.abc (20); return 0;} Objects Net Descriptors from FSTREAM Objects

On Solaris, you can use the fstream :: rdbuf (). Fd () method to get a file descriptor from the FSTREAM object. However, the Basic_FileBuf class on Linux does not have an FD () method available. This is the non-standard C code.

For standard C code, you first use Open (POSIX) to open the file, then get the file descriptor FD. The File object is then opened with FDOpen (POSIX) and name it Myfile. The FileBuf object is then created with MyBuf (MYFILE) and name it Mybuf. After that, you can call its member function str.rdbuf (MyBUF) (standard C ) to associate the buffer with the IFStream or OFSTREAM object STR.

Target hardware platform

Sparc

Many distributors offer Linux of Sun's SPARC architecture. Sun is in the development direction of Solaris as a software partner of Linux and open source. Sun has a tuning strategy for Linux and migrating Linux applications to Solaris, but Sun does not support or recognize any specific Linux distribution.

psery

IBM plays a positive role in the Linux PowerPC community. The development of the latest generation processor Power3 and Power4 needs to add other features, which are added to the Linux 2.4 kernel.

SUSE Version 7.1 using Linux 2.4 kernel is the first announcing support for RS / 6000 systems, including B50, 150, F50, 170, 260, 270, and P640 models.

Yellow Dog Linux also has a PowerPC distribution version that supports RS / 6000 systems. TurboLinux and Red Hat also released a PPC version.

According to reports, the latest version of Linux 2.4 is well retracted on the four to six processors in the SMP system. This version can work well on PSeries and RS / 6000 systems, such as B50, 150, 260, 270, and P640 and the p620 and p660 systems that are about to appear. To learn about Linux for PSeries System Guide, see:

IBM.com/servers/server/pseries/linux/guide.html

The following software has a Linux package on the PSeries:

Enhydra Java / XML Lutris Application Server Myricom MYRINET SCALABLE Cluster Interconnect Absoft's CodeWarrior for PowerPC / Linux MetrowerKs

Any application can be developed with Linux and then deployed to the machine running Linux on the PSeries, or deployed on AIX using Linux technology. After developing and deploying, Linux-based applications are this AIX application, which means they can achieve the same scalability and performance as other AIX applications. However, if you don't recompile Linux for PSeries, you cannot run Linux on the PSeries. Similarly, applications developed for PSeries on Linux cannot operate in binary form on AIX. Linux on PSeries and AIX active code compatibility. To learn more about Linux on PSeries, see: IBM.com/servers/server/pseries/linux/

ZSERIES

Due to the unity of the server structure and the reduction of the number of servers, the consolidation of large-scale farms to ZSERIES mainframes makes customers' management and energy costs. IBM provides Linux on ZSERIES for hardware support, such as Z900, and S / 390 processors supporting Linux for S / 390, such as G5, G6, and MultiPrise 3000. Currently, the distribution can be obtained from SUSE, TurboLinux and And Red Hat.

Supported applications and languages ​​are rapidly increased, and the number is so many, it is difficult to list. They include C / C , Perl, TCL, Python, Scheme, Regina (REXX), and Java JDK 1.3. Databases include MySQL, Postgres, DB2 UDB, and DB2 Connect. The middleware includes WebSphere 3.5, MQ Client, Tivoli, and Apache. There are some distribution to support Linux kernel 2.4, HiPersockets Support, logical volume management, and logging file system Reiserfs. You can download a 64-bit kernel for Beta test. If you need a web page that describes the available applications, see:

IBM.com/servers/server/zseries/solutions/s390da/linuxproduct.html

For additional information on the port of Linux specific to S / 390 and ZSERIES, see:

IBM.com/servers/esdd /articles/linux_s390/index.html

IBM.com/servers/server/zseries/OS/linux

XSeries

Almost all Linux distribution editions (Redhat, Caldera, Mandrake, SUSE, Debian, TurboLinux, etc.) are constantly supported on the Intel platform. However, Linux has not been greatly successful in Intel desktop, but there is a small outcome in the server market.

IBM E-Business Hosting is adding Red Hat Linux 6.2 to a range of operating systems supported by its server hardware. The newly provided content is: a basic service, a group of additional value-added services, and the price list that customers can choose (enabled, manage, monitor, and protect their Linux e-commerce servers). The server environment is provided as follows:

Operating System: Red Hat Linux 6.2 Support Server Hardware: IBM Netfinity Models 3500, 4500, 5000, 5100, 5500, 5600, 6000R, 7000, 7100 Availability Monitoring Service: PING and URL Monitoring Management Services: In-depth monitoring capabilities in the code and Enhanced event filtration will provide positive and active monitoring and intelligent alert notifications. The optional console will provide a graphical representation of the client's application environment on all servers to achieve comprehensive, overall end-to-end browsing. Visual alarm Notifications will capture the "Point In Time" data, then the event viewer will help end users quickly find problems and resolve. There is also a short historical report for trend analysis. You can customize all views and save them between sessions. Safety Services: The NSA scanner uses the NSA scanner to defect scanning of about 2500 of the host's target IP addresses. The service is done between the devices of the Internet address on the Internet. The scan service will be configured (filtered) according to the security control defined by the IBM, and labeled the defect. The security assessment team will review the scan results to ensure that the work is correctly executed. The report will be sent to IBM site administrators (or designated supporters) to review so they can take appropriate initiatives. Backup and Recovery Services: A process that implements customer data backup and recovery in managed shared data environments. According to customer needs, special backups and resume resources are also available. There are other R-class (Band R) services, including Offset Storage, Storage Assist, special B and R services, and library portioning. To learn more about Linux on xSeries, see:

IBM.com/servers/server/linux/xseries/

About author

Lee Cheng is currently a senior consultant for RS / 6000 and AIX software vendors. She provides these suppliers to the application benchmark, performance tuning, application transplant, and internationalization support. Before joining the RS / 6000 ISV Technical Support group, she is a developer of a compiler and AIX system management component. She holds a master's degree in computer science at the University of Kentucky.

Wayne Huang is a senior consultant for eserver / penies and AIX systems, focusing on e-commerce, banking, financial and securities industry. He provides application design, problem identification, system performance tuning, and application benchmark based AIX support to ISV. He holds a bachelor's degree in Physics in Taiwan and a master's degree in computer science at the Texas University of Austin.

Nam Keung is a senior programmer, which is committed to AIX communication development, AIX multimedia, SOM / DSOM development, and Java performance work. His current work includes helping ISV for application design, deploying applications, performance tuning, and education about PSERIES platforms. He has been an IBM programmer since 1987.

Paul Sutera is a programmer, he is committed to evaluating the application from 1995 and porting the application to the IBM ZSERIES. His current work includes helping customers and vendors build applications and other packages and deploy them to ZSeries Linux and z / OS UNIX system services. He is the programmer of IBM since 1984.

转载请注明原文地址:https://www.9cbs.com/read-10631.html

New Post(0)