SGI Altix Compilation and Linking FAQ

User Information Home
Compute Resources
Software
Data
Security
Allocations
Consulting
Training
Strategic Applications Program

 

• How do I find the versions of the compilers?
• Why do I get the error "No more system resources available" when I try to compile?
• If I compile my code with Intel icc on cobalt, which debugger should I use?
• I am trying to port my code onto Cobalt. The code had been running on a 32 bit system. I am having problems in porting it to 64 bit machine.
• When I look at the dynamically loaded libraries, using the ldd utility, I see a shared object linux-gate.so.1. What is linux-gate.so.1?
• Can the Intel fortran compiler generated executable convert from little-endian to big-endian?
• My OpenMP program, which runs fine on a lower number of threads, fails to do so when I increase the number of threads.
• When I compile my MPI code, why do I get IPO error: unresolved for all MPI subroutines in my code?
• I have put all needed libraries with the -L -l flags in the command line when linking my code, why do I still get "unresolved reference" errors for some subroutines from those libraries?

---

How do I find the versions of the compilers?

Use the which command to find out the version of the compiler. Please note that this depends on the settings in your .soft file in your home directory. Here are a few examples:

Fortran	which ifort
C	which icc
C++	which icpc

Why do I get the error "No more system resources available" when I try to compile?

It is possible that the compiler needs more memory than is available with your interactive limits. Please send an exact copy of the error message, a pointer to your source code, and a reference to this FAQ entry to NCSA's Consulting Office.

If I compile my code with Intel icc on cobalt, which debugger should I use?

Depending on the nature of the code you are trying to debug, we would recommend either totalview or gdb.

I am trying to port my code onto Cobalt. The code had been running on a 32 bit system. I am having problems in porting it to 64 bit machine.

Please look at the compiler options to change the default sizes of real and integer types.

Also click the link "# Porting Linux Applications to 64-Bit Intel Architecture" in Vendor Documentation

When I look at the dynamically loaded libraries, using the ldd utility, I see a shared object linux-gate.so.1. What is linux-gate.so.1?

When you use the ldd utility on a reasonably recent Linux system you'll frequently see a reference to an ethereal entity known as linux-gate.so.1:

ldd /bin/sh

        linux-gate.so.1 =>  (0xffffe000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7fb2000)
        libc.so.6 => /lib/libc.so.6 (0xb7e7c000)
        /lib/ld-linux.so.2 (0xb7fba000)

What's so strange about that? It's just a dynamically loaded library, right? Sort of, for sufficiently generous definitions of dynamically loaded library. The lack of file name in the output indicates that ldd was unable to locate a file by that name. Indeed, any attempt to find the corresponding file, whether manually or by software designed to automatically load and analyze such libraries, will be unsuccessful. From time to time this is a cause of befuddlement and frustration for users as they go searching for a non-existent system file. You can confidently tell users on this futile quest that there's not supposed to be a linux-gate.so.1 file present anywhere on the file system; it's a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory. For more details on this please take a look at this article.

Can the Intel fortran compiler generated executable convert from little-endian to big-endian?

The Intel Fortran Compiler can write unformatted sequential files in big-endian format and also can read files produced in big-endian format by using the little-endian-to-big-endian conversion feature.

In order to use the little-endian-to-big-endian conversion feature, specify the numbers of the units to be used for conversion purposes by setting the F_UFMTENDIAN environment variable. Then, the READ/WRITE statements that use these unit numbers, will perform relevant conversions. Other READ/WRITE statements will work in the usual way.

In the general case, the variable consists of two parts divided by a semicolon. No spaces are allowed inside the F_UFMTENDIAN value. The variable has the following syntax:

F_UFMTENDIAN=MODE | [MODE;] EXCEPTION

where:

MODE = big | little
EXCEPTION = big:ULIST | little:ULIST | ULIST
ULIST = U | ULIST,U
U = decimal | decimal -decimal

where, MODE defines current format of data, represented in the files; it can be omitted. The keyword little means that the data have little endian format and will not be converted. This keyword is a default. The keyword big means that the data have big endian format and will be converted. This keyword may be omitted together with the colon. EXCEPTION is intended to define the list of exclusions for MODE; it can be omitted. EXCEPTION keyword (little or big) defines data format in the files that are connected to the units from the EXCEPTION list. This value overrides MODE value for the units listed. Each list member U is a simple unit number or a number of units. The number of list members is limited to 64. decimal is a non-negative decimal number less than 232. Converted data should have basic data types, or arrays of basic data types. For additional information please take a look at the Intel Compiler Vendor Documentation

My OpenMP program, which runs fine on a lower number of threads, fails to do so when I increase the number of threads.

Increasing the number of threads in your OpenMP program may result in an increase in the stack size when you run your executable. The default stacksize for OpenMP applications, denoted by the environment variable KMP_STACKSIZE, is 4M. You may try setting the KMP_STACKSIZE environment variable to 8M or 16M and see if it solves your problem.

When I compile my MPI code, why do I get IPO error: unresolved for all MPI subroutines in my code?

You might have used the -nus option when you compile your code. The -nus option will prevent the compiler from appending an underscore character to external user-defined names, while there is an underscore in all MPI subroutines. Drop off the -nus option may solve the problem.

I have put all needed libraries with the -L -l flags in the command line when linking my code, why do I still get "unresolved reference" errors for some subroutines from those libraries?

We have observed that with static libraries (.a), it may be due to where in the link command the -L -l flags are placed, and in the case of multiple libraries, the order of the libraries. Please put the L -l flags at the end of the link command, and if you are linking to multiple libraries, put the most dependent library first and so on, then try again.