All builds I've tested (up to 1.8.17 and 1.10.0-patch1) segfault when being built on Linux with icc and ifortran 16.0.3. Any idea what's going on? gcc and gfortran builds build correctly.

My makefile

FC = ifort
FCFLAGS= -O3 -xHost

TARGETS= clean birrp
OBJSOC= strlen.f diagnostic.f math.f rtpss.f zlinpack.f coherence.f fft.f rarfilt.f utils.f dataft.f filter.f response.f weight.f  birrp.f
   
all:  $(TARGETS)    
clean:$
        rm -f *.o *.mod
        rm -f birrp
        
birrp:$(OBJSOC)
        $(FC) $(FCFLAGS) -o $@ $(OBJSOC)

# General compile rules
.SUFFIXES: .f .o 

.f .o:    
    $(FC) $(FCFLAGS) -c -o $@ $< 

I have now birrp exe and when I try to run it

./birrp < n128.in

I got some results.But the problem is that it does not read some input files at all.I have double checked this by changing these files,resultsFazer downloadb.tar.gz are the same.I have inserted write(*,*) line in dataft.f to print on the screen but nothing happens.I have attached all the files.

program Bug
  call main()

!    contains
end program Bug


Module errorModule

double precision,allocatable,dimension(:) :: readInArray, tmpWork
integer :: n,i
character(len=300) :: filout


end Module errorModule


subroutine main()

use errorModule

n = 59925

allocate(tmpWork(n+10))
do i=1,n+10
    tmpWork(i) = i
enddo

allocate(readInArray(62267))
 write(filout,'("PhysicalMapInput.txt")')

open(unit=1001,file=trim(filout),status="old")



read(1001,*) readInArray(tmpWork(1:n))


print *,readInArray

deallocate(readInArray)
deallocate(tmpWork)

end subroutine main

I believe I have found an error in the intel ifort compiler (the 2017 version). I have tested this with ifort 16 and the bug is not there.

I have written the above program to demonstrate this.

When I run the following:

ifort error.f90 -traceback -g -debug all -warn all -check bounds -check format -check output_conversion -check pointers  -ftrapuv -check all -gen-interfaces -warn interfaces 

I get the following error: 

forrtl: severe (194): Run-Time Check Failure. The variable 'var$76' is being used in 'error.f90(36,1)' without being defined

Image              PC                Routine            Line        Source             

a.out              000000010D72464C  _main_                     36  error.f90

a.out              000000010D725574  _MAIN__                     2  error.f90

a.out              000000010D723CAE  Unknown               Unknown  Unknown

As already mentioned. This does not happen in the 2016 version. 

Hi,

I am trying to hybridize a pure-MPI code with OpenMP. But I am not expert on it, and I face a problem related to copyin the variables initialized from modules.

The arrays are initialized in 2 different modules, and they are then revalued and used to generate the output array in a do loop. Therefore, I have to copyin them in the OMP threads. However, these arrays are private in the modules, while the OMP part is in the subroutine outside the modules. And the calling relationship are a bit of complicated.

I really appreciate any suggestion on how to solve this problem. Thanks a lot in advance!

Regards,

Liu

!---------------------------------------------------------------------------------------

The following is the structure of the code:

!---------------------------------------------------------------------------------------

subroutine main()

      use module1

      call initialize_module1 ! In module 1, a list of arrays are given initial values.

      call step1()

      call finalize_module1

end subroutine main

subroutine step1()

      use module2

      call initialize_module2 ! In module 2, a list of arrays are also given initial values...

      do loop (very big --> OpenMP) ! Here I think I have to copyin the arrays initialized in both module1 and module2, because in step2 they are revalued...

            call step2()

      end do

      call finalize_module2

end subroutine step1

subroutine step2()

      use module1

      use module2

      call work_module1()

      call work_module2()

      use_the_arrays_and_calculate_some_ouput_arrays

end subroutine step2

module module1

      private array11, array12, ...

      contains

      subroutine initialize_module1() ! Give initial values of array11, array12, etc

      subroutine work_module1() ! Here array11, array12 are revalued...

      subroutine finalize_module1()

end module1

module module2

      private array21, array22, ...

      contains

      subroutine initialize_module2()

      subroutine work_module2() ! revalue array21, array22,...

      subroutine finalize_module2()

end module2

Following Steve Lionel'sadvicee with warn interface I got this warning for the code I am compiling

math.f(2079): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic.   [IPAR]

In my subroutine fzero I have vector if integer parameters ipar.The guy who wrote the code declared

 dimension rpar(*),ipar(*)

How should I change this to function properly,not just to silence the compiler?

Hi there

here is the example:

Module Mod_1
  Type :: T_1
    integer :: n
    Integer, allocatable :: a(:)
  contains
    Procedure, Pass :: Init => SubInit
    Procedure, PAss :: getA => FunGetA
  End type T_1
  Interface
    Module Subroutine SubInit(this,n)
      Class(T_1), Intent(Inout) :: this
      Integer, Intent(in) :: n
    End Subroutine
    Module Function FunGetA(this)
      Class(T_1), Intent(Inout) :: this
      Integer, Dimension(size(this%a)) :: FunGetA
    End Function
  End Interface
End Module Mod_1

Submodule(Mod_1) Routines
contains
  Module Procedure SubInit
    Implicit None
    allocate(this%a(n))
  end Procedure
  Module Procedure FunGetA
    Implicit none
    if(allocated(this%a)) Then
      FunGetA=this%a
    End if
  End Procedure
End Submodule Routines

Program Test
  use Mod_1
  Implicit None
  Type(T_1) :: TA
  Integer, allocatable :: b(:)
  call TA%Init(5)
  b=TA%getA()
End Program Test

when compiling it chrashes with

SubMod_1.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for SubMod_1.f90 (code 1)
make: *** [makefile:31: SubMod_1.o] Error 1

The only workaround is to set the dimension specification in the interface definition of FunGetA to an integer value (eg. 10). Setting is to this%n causes the same crash.

Since I usually prefer subroutines I am not an expert in functions, so I might do something wrong here. But if it were obviously wrong I would expect a more informative compiler message.

Any idea.

Thanks

Karl

When I debug some problem like a segfault in a fortran program, the first three frames in the backtrace (0-2) always point to some functions in the intel library libifcoremt.so and in the system library libpthread.so, and only in frame 3, the actual cause in my code is shown:

raise ()                      libpthread-2.12.so             0x0000003DE2A0F6AB
for__issue_diagnostic ()      libifcoremt.so.5               0x00002AFBB1E83348
for_emit_diagnostic ()	      libifcoremt.so.5               0x00002AFBB1E83913
somefunc (somepar=somevalue)  somefile.f90:1364	somebinary   0x00000000029EAA3B

I am not completely sure but I believe it has not always been like that, but I don't know what could have changed in my setup.

Can someone help me figure out what is going on here, and whether there's a possibility to make _my_ relevant code become frame 0 again?

I am trying to parallelize an algorithm using DAG-Scheduling via OpenMP tasks and there many programs are killed by the Linux kernel due to Out-Of-Memory after a calls to the parallelized code although the allocated memory is only 1% of the servers main memory. But this happens only if I use the Intel Compilers from 2015, 2016 or even the new 2017 edition.

Here is a small example building the same task dependency graph as the algorithm crashing:

    PROGRAM OMP_TASK_PROBLEM
        IMPLICIT NONE

        INTEGER M, N
        PARAMETER(M = 256, N=256)
        DOUBLE PRECISION X(M,N)

        X(1:M,1:N) = 0.0D0

        CALL COMPUTE_X(M, N, X, M)

        ! WRITE(*,*) X (1:M, 1:N)

    END PROGRAM


    SUBROUTINE COMPUTE_X(M,N, X, LDX)
        IMPLICIT NONE
        INTEGER M, N, LDX
        DOUBLE PRECISION X(LDX, N)
        INTEGER K, L, KOLD, LOLD


        !$omp parallel default(shared)
        !$omp master
        L = 1
        DO WHILE ( L .LE. N )
            K = M
            DO WHILE (K .GT. 0)
                IF ( K .EQ. M .AND. L .EQ. 1) THEN
                    !$omp  task depend(out:X(K,L)) firstprivate(K,L) default(shared)
                    X(K,L) = 0
                    !$omp end task
                ELSE IF ( K .EQ. M .AND. L .GT. 1) THEN
                    !$omp  task depend(out:X(K,L)) depend(in:X(K,LOLD)) firstprivate(K,L,LOLD) default(shared)
                    X(K,L) = 1 + X(K,LOLD)
                    !$omp end task
                ELSE IF ( K .LT. M .AND. L .EQ. 1) THEN
                    !$omp  task depend(out:X(K,L)) depend(in:X(KOLD,L)) firstprivate(K,L,KOLD) default(shared)
                    X(K,L) = 2 + X(KOLD,L)
                    !$omp end task
                ELSE
                    !$omp  task depend(out:X(K,L)) depend(in:X(KOLD,L),X(K,LOLD)) firstprivate(K,L,KOLD, LOLD) default(shared)
                    X(K,L) = X(KOLD, L) + X(K,LOLD)
                    !$omp end task
                END IF

                KOLD = K
                K = K - 1
            END DO

            LOLD = L
            L = L + 1
        END DO
        !$omp end master
        !$omp taskwait
        !$omp end parallel
    END SUBROUTINE

After compiling it using `ifort -qopenmp -g omp_test.f90` and running it via `valgrind` it reports:

==23255== 1,048,576 bytes in 1 blocks are possibly lost in loss record 22 of 27
==23255==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23255==    by 0x516AF47: bget(kmp_info*, long) (kmp_alloc.c:741)
==23255==    by 0x516AC6D: ___kmp_fast_allocate (kmp_alloc.c:2012)
==23255==    by 0x51CFAC7: __kmp_task_alloc (kmp_tasking.c:997)
==23255==    by 0x51CFA36: __kmpc_omp_task_alloc (kmp_tasking.c:1134)
==23255==    by 0x40367E: compute_x_ (omp_task_problem.f90:31)
==23255==    by 0x51DC412: __kmp_invoke_microtask (in /scratch/software/intel-2017/compilers_and_libraries_2017.0.098/linux/compiler/lib/intel64_lin/libiomp5.so)
==23255==    by 0x51AC186: __kmp_invoke_task_func (kmp_runtime.c:7055)
==23255==    by 0x51AD229: __kmp_fork_call (kmp_runtime.c:2361)
==23255==    by 0x5184EE7: __kmpc_fork_call (kmp_csupport.c:339)
==23255==    by 0x4034D3: compute_x_ (omp_task_problem.f90:24)
==23255==    by 0x4030CC: MAIN__ (omp_task_problem.f90:10)
==23255==
==23255== 1,048,576 bytes in 1 blocks are possibly lost in loss record 23 of 27
==23255==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23255==    by 0x516AF47: bget(kmp_info*, long) (kmp_alloc.c:741)
==23255==    by 0x516AC6D: ___kmp_fast_allocate (kmp_alloc.c:2012)
==23255==    by 0x51CE30A: __kmp_add_node (kmp_taskdeps.cpp:204)
==23255==    by 0x51CE30A: __kmp_process_deps (kmp_taskdeps.cpp:320)
==23255==    by 0x51CE30A: __kmp_check_deps (kmp_taskdeps.cpp:365)
==23255==    by 0x51CE30A: __kmpc_omp_task_with_deps (kmp_taskdeps.cpp:523)
==23255==    by 0x403A11: compute_x_ (omp_task_problem.f90:35)
==23255==    by 0x51DC412: __kmp_invoke_microtask (in /scratch/software/intel-2017/compilers_and_libraries_2017.0.098/linux/compiler/lib/intel64_lin/libiomp5.so)
==23255==    by 0x51AC186: __kmp_invoke_task_func (kmp_runtime.c:7055)
==23255==    by 0x51AD229: __kmp_fork_call (kmp_runtime.c:2361)
==23255==    by 0x5184EE7: __kmpc_fork_call (kmp_csupport.c:339)
==23255==    by 0x4034D3: compute_x_ (omp_task_problem.f90:24)
==23255==    by 0x4030CC: MAIN__ (omp_task_problem.f90:10)

The line numbers of the `compute_x_` function in the backtrace correspond to the `!$omp task` statements. These memory leaks accumulated rapidly to an amount of memory such that the program crashes.

Using gcc-6.2 for this `valgrind` ends up with:

   ==21246== LEAK SUMMARY:
    ==21246==    definitely lost: 0 bytes in 0 blocks
    ==21246==    indirectly lost: 0 bytes in 0 blocks
    ==21246==      possibly lost: 8,640 bytes in 15 blocks
    ==21246==    still reachable: 4,624 bytes in 4 blocks
    ==21246==         suppressed: 0 bytes in 0 blocks
    ==21246==

where the leaks are only from the first initialization of the OpenMP runtime system.

So my question is: Why does the Intel Compiler/Intel OpenMP runtime system produce theses leaks or alternatively is there an error in the way I have
designed the task parallelism.

I am currently developping a user subroutine for ANSYS using ifort version 12.1.0 (The version needed to link the user subroutine to ANSYS) with the compiler installed on a Linux platform.

Toidentify the dependencies of the various subroutine and modules before compiling them, i used the command (All f90 files reside in the main folder when i do the operation.):

ifort -gen-dep:depend.mak -save-temps *.f90 1>>dump.std 2>>dump.err

ifort returns this into the depend,mak file for a few of the fortran file, mainly for subroutines which require a module:

statesType.o : \
  statesType.f90 /usr/include/tensorstype.modintr /usr/include/tensorstype.modintr \
  /usr/local/gcc-4.2.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/include/tensorstype.modintr \
  /usr/local/include/tensorstype.modintr \
  /raid/home/public/intel/composer_xe_2011_sp1.7.256/compiler/include/tensorstype.modintr \
  /raid/home/public/intel/composer_xe_2011_sp1.7.256/compiler/include/intel64/tensorstype.modintr \
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/include/tensorstype.modintr \
  ./tensorstype.modintr tensorstype.modintr /usr/include/tensorstype.mod \
  /usr/include/tensorstype.mod \
  /usr/local/gcc-4.2.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/include/tensorstype.mod \
  /usr/local/include/tensorstype.mod \
  /raid/home/public/intel/composer_xe_2011_sp1.7.256/compiler/include/tensorstype.mod \
  /raid/home/public/intel/composer_xe_2011_sp1.7.256/compiler/include/intel64/tensorstype.mod \
  /opt/intel/composer_xe_2011_sp1.7.256/mkl/include/tensorstype.mod \
  ./tensorstype.mod tensorstype.mod

ifort seems to adequatetely identify the needed module but seems to add junk path before the file and additional .modintr files. Is there something i'm doing wrong ?

Hi, I get a 

configure: error: Fortran 2003 Interoperability with C required, but compiler lacks support

when trying to compile a code with v11.0.069 Ifort. Would anyone know if this should be expected and what might solve this?

Thank you, 

Artem

Hi all,

the following code writes an incorrect result:

program p
 implicit none

 call fs((/"abc","d  "/))

contains

 subroutine fs(text)
  character(len=*), intent(in) :: text(:)
  integer :: i

   write(*,*) "size(text) = ", size(text)
   write(*,*) "len_trim   = ", (len_trim(text(i)) , i=1,size(text))
   write(*,*) "sum(...)   = ", sum((/(len_trim(text(i)) , i=1,size(text))/))

 end subroutine fs

end program p

Using "Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.181 Build 20160204" I get

 size(text) =            2
 len_trim   =            3           1
 sum(...)   =          259

where I would expect, for sum(...), 4.

This might also be related to this old post: https://software.intel.com/en-us/comment/1878150#comment-1878150 .

I have this error and my code is just below, can someone help me?

read_co2atm.f90(1): error #5082: Syntax error, found '(' when expecting one of: <END-OF-STATEMENT> ;
       program read_co2atm(futr_scen, nco2rec, yrco2rec, atmco2rec)
--------------------------^
read_co2atm.f90(21): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: <REAL_KIND_CON> <REAL_CONSTANT> <DBLPRC_CONSTANT> <DBLPRC_KIND_CON> <QUAPRC_CONSTANT> ...
       OPEN(luco2+1, FILE='splmlo_co2_noces.dat', FORM='formatted',
--------------------------------------------------------------------^
read_co2atm.f90(22): error #5082: Syntax error, found '&' when expecting one of: <LABEL> <END-OF-STATEMENT> ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...
      &     STATUS='old')
------------^
read_co2atm.f90(22): error #5276: Unbalanced parentheses
      &     STATUS='old')
------------------------^
read_co2atm.f90(22): error #5082: Syntax error, found ')' when expecting one of: <END-OF-STATEMENT> ;
      &     STATUS='old')
------------------------^
read_co2atm.f90(33): error #5082: Syntax error, found '&' when expecting one of: <LABEL> <END-OF-STATEMENT> ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...
      &      yrco2rec(irec),atmco2rec(irec)
-------------^
read_co2atm.f90(39): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: <REAL_KIND_CON> <REAL_CONSTANT> <DBLPRC_CONSTANT> <DBLPRC_KIND_CON> <QUAPRC_CONSTANT> ...
       WRITE(*,*) 'Atm. CO2:  No. of entries for 1-box atmosphere =',
---------------------------------------------------------------------^
read_co2atm.f90(40): error #5082: Syntax error, found '&' when expecting one of: <LABEL> <END-OF-STATEMENT> ; TYPE INTEGER REAL COMPLEX BYTE CHARACTER CLASS DOUBLE ...
     &            nco2rec
------------------^
compilation aborted for read_co2atm.f90 (code 1)

My code

       program read_co2atm(futr_scen, nco2rec, yrco2rec, atmco2rec)

       IMPLICIT NONE

       INTEGER maxrec, nmxr
       PARAMETER (maxrec=1200, nmxr=700)

       REAL yrco2rec(maxrec), atmco2rec(maxrec)
       INTEGER luco2, irec
       INTEGER nco2rec
       INTEGER is, ireadf
       INTEGER nsipl, nstab

       REAL futco2(nmxr,8)
       REAL dummy

       CHARACTER*4 futr_scen

       luco2=50
       OPEN(luco2+1, FILE='splmlo_co2_noces.dat', FORM='formatted',
      &     STATUS='old')

       WRITE(*,*)'  '
       WRITE(*,*)'--------------------------------------------------'
       WRITE(*,*)'Atm. CO2 from fit to Siple-Mauna Loa record'
       WRITE(*,*)'--------------------------------------------------'

       DO irec=1,maxrec

        READ(luco2+1,*,ERR=222,END=222)
      &      yrco2rec(irec),atmco2rec(irec)
        nco2rec = irec
       END DO

 222   CONTINUE

       WRITE(*,*) 'Atm. CO2:  No. of entries for 1-box atmosphere =',
     &            nco2rec

       CLOSE(luco2+1)

       RETURN
       END

I'm failing to install and activate Intel Fortran compiler on CentOS7 via network license manager.
When activation, select "2. Use Intel(R) Software License Manager" and enter correct ip and port number of the license server.
After that, no response from the installer over few hours. so I need to give up the activation.

The client Linux is located in AWS. The license server is in company office.

I verified that port 28518 is open in packet level. Are there any things should I do?

Client : CentOS7 on AWS
License Server : Window 2008 Server in local
Application : Intel Parallel studio xe 2016 composer edition for fortran

Thank you for using Intel® software development tools. We are committed to making the best possible software and platforms to meet your development needs. Your personal experience with our products is extremely valuable to us and we want to know how we can do better.

Click here to share your thoughts by completing a 10-min survey on Intel® Parallel Studio XE, as well as your general tool usage.  We value your opinion and look forward to your feedback.  If you have any questions, post a comment below.

If you reside outside of the United States and decide to participate in this survey, you are agreeing to have your personal data transferred to and processed in the United States. Refer to Privacy for more details.

On 7 September 2016, I received an email that indicates that Intel Fortran 2017 has been released.  Great news !  I installed it. Softwares to be installed include, among others:

- Intel Math Kernel Library for OS X 2017

- Intel Data Analytics Acceleration Library for OS X 2017 

Now, on 21 September 2016, I  received a new email announcing 2 software updates:

- Intel Math Kernel Library for OS X 11.3, update 4

- Intel Data Analytics Acceleration Library for OS X 2016, update 4
 

I guess that the 7 September 2016 Fortran 2017 release supersedes the 21 September 2016 release, and that I can discard these updates number 4, right ? (In my old 2016 installation, I had update 3).

ifort does not compile the attached code, which I think is legal

program p
 implicit none
 character(len=*), parameter :: text = "message text"

 associate( msg => text )
 write(*,*) msg
 end associate
end program p

The error is

ifort test.f90 -o test
test.f90(6): error #6404: This name does not have a type, and must have an explicit type.   [MSG]
 write(*,*) msg
------------^
compilation aborted for test.f90 (code 1)

and happens for both versions:

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.0.098 Build 20160721

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.181 Build 20160204

Marco

Has anyone successfully compiled and installed fgsl using the intel fortran compiler?

I've found this post:

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/271209

which mentions a fgsl install, but I suspect it's for OSX.

I've downloaded fgsl v. 1.1.0 from http://www.lrz.de/services/software/mathematik/gsl/fortran/

and followed the instructions.  Apparently, compilation with ifort was successful, and I was also able to create a sample program which tried to invoke a fgsl function.  However, when I run the program I get an 'undefined symbol' error message...

It's related to allocating an allocatable component of a user-defined type array with source or mold option, I'm not sure whether this is a wrong way of using mold/source or is a known issue and will be fixed in 2017 version. Anyway, here is the example:

program main
	implicit none
	type t_test
		real(8), allocatable :: T(:)
	end type
	real(8) :: B(2)
	type(t_test) :: A(1)

	do
		allocate(A(1)%T,mold=B)
		!allocate(A(1)%T,source=B)
	enddo

end program

and memory leaks!

if change "A(1)" to a scale "A", then allocate statement will raise a "allocatable array is already allocated" error. I'm not sure whether this error is normal or mold/source should reallocate automatically if shape doesn't match?

compiled with Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.3.210 Build 20160415

Hi 

I get the following message:

tiny.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.

I've attached a tiny example to reproduce the problem.  

Compiling with 

ifort -c tiny.f90

ifort version: ifort (IFORT) 14.0.1 20131008

Obviously this is an old version of the compiler. Can you test this with the latest version - I currently don't have access to the latest version.

Thanks.

With regard to this

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/675652

I went back to 16.0.4 which gave me my dynamic library .................. but the code below failed with a segfault, while 17 is giving the correct results:

Module mod_t1
  Implicit None
  Type t1
    Private
    Integer :: a=8
  contains
    Procedure, Pass, Public :: getA => FunGetA
  End type t1
  Private FunGetA
contains
  Function FunGetA(this)
    Class(t1), Intent(In) :: this
    Real, Allocatable :: FunGetA
    FunGetA=this%a
  End Function FunGetA
End Module mod_t1
Program Test
  use mod_t1
  Type(t1) :: b
  write(*,*) b%getA()
End Program Test

Thus, I either rewrite heaps of allocatable functions ................ or I forget about getting a dynamically linked library.