"_Gfortran_Pow_C8_I4" Error When Linking .O Files from G++ and Gfortran Using G++

__gfortran_pow_c8_i4 error when linking .o files from g++ and gfortran using g++

The following assumes you are using the GNU compiler tools. Things may be slightly different if you are using other compilers.

You can use either compiler to link the two together, but you need to provide the appropriate libraries.

Typically, you can use either

gfortran fortobj.o cppobj.o -lstdc++

or

g++ fortobj.o cppobj.o -lgfortran

This assumes that you are using a setup where both compilers know about each other's libraries (like if you installed through a linux repository).

---

In the case of the OP the C compilers came from XCode and gfortran is from homebrew. In that case, gfortran knows about the g++ libraries (since they were used to compile the compiler), but g++ doesn't know about the gfortran libraries. This is why using gfortran to link worked as advertised above. However, to link with g++ you need to add the path to libgfortran.* when you call the linker using the -L flag, like

g++ fortobj.o cppobj.o -L/path/to/fortran/libs -lgfortran

---

If for some reason your gfortran compiler is unaware of your g++ libs, you would do

gfortran fortobj.o cppobj.o -L/path/to/c++/libs -lstdc++

---

Note that there shouldn't be any difference in the final executable. I'm no compiler expert, but my understanding is that using the compiler to link your objects together is a convenience for calling the linker (ld on UNIX-like OS's) with the appropriate libraries associated with the language you are using. Therefore, using one compiler or the other to link shouldn't matter, as long as the right libraries are included.

libpthread.so.0: error adding symbols: DSO missing from command line

You should mention the library on the command line after the object files being compiled:

 gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init \
     -g -O2 -export-dynamic -o utilities/ovs-dpctl utilities/ovs-dpctl.o \
     lib/libopenvswitch.a \
     /home/jyyoo/src/dpdk/build/lib/librte_eal.a /home/jyyoo/src/dpdk/build/lib/libethdev.a /home/jyyoo/src/dpdk/build/lib/librte_cmdline.a /home/jyyoo/src/dpdk/build/lib/librte_hash.a /home/jyyoo/src/dpdk/build/lib/librte_lpm.a /home/jyyoo/src/dpdk/build/lib/librte_mbuf.a /home/jyyoo/src/dpdk/build/lib/librte_ring.a /home/jyyoo/src/dpdk/build/lib/librte_mempool.a /home/jyyoo/src/dpdk/build/lib/librte_malloc.a \
     -lrt -lm -lpthread 

Explanation: the linking is dependent on the order of modules. Symbols are first requested, and then linked in from a library that has them. So you have to specify modules that use libraries first, and libraries after them. Like this:

gcc x.o y.o z.o -la -lb -lc

Moreover, in case there's a circular dependency, you should specify the same library on the command line several times. So in case libb needs symbol from libc and libc needs symbol from libb, the command line should be:

gcc x.o y.o z.o -la -lb -lc -lb

Replacing extrordinarily slow pow() function

Just write your own pow function, put the .o file in a static library archive libmypow.a somewhere in the linker's library path, and pass -lmypow when linking.

Undefined reference to pow( ) in C, despite including math.h

You need to link with the math library:

gcc -o sphere sphere.c -lm

The error you are seeing: error: ld returned 1 exit status is from the linker ld (part of gcc that combines the object files) because it is unable to find where the function pow is defined.

Including math.h brings in the declaration of the various functions and not their definition. The def is present in the math library libm.a. You need to link your program with this library so that the calls to functions like pow() are resolved.

Undefined reference to `pow' and `floor'

You need to compile with the link flag -lm, like this:

gcc fib.c -lm -o fibo

This will tell gcc to link your code against the math lib. Just be sure to put the flag after the objects you want to link.

minpack fortran .dll for use in c#

Unmanaged dll can't be added as a reference to a C# application. GCC can not easily link COM object for you.

If the dll exports a number of global functions, then you should be able to use Platfrom Invoke (DllImport attribute) to call them from C#

Please look at this article or any other from Google search.

log(10.0) can compile but log(0.0) cannot with undefined reference?

gcc can use builtin functions in many cases, their documentation says:

Many of these functions are only optimized in certain cases; if they
are not optimized in a particular case, a call to the library function
is emitted.

so therefore gcc will not need to link against the math library when using the builtin function but since log(0) is not defined it probably forcesgcc to evaluate it at run-time since it has a side effect.

If we look at the draft C99 standard section 7.12.1 Treatment of error conditions in paragraph 4 it says (emphasis mine):

A floating result overflows if the magnitude of the mathematical
result is finite but so large that the mathematical result cannot be
represented without extraordinary roundoff error in an object of the
specified type. If a floating result overflows and default rounding is
in effect, or if the mathematical result is an exact infinity from
finite arguments (for example log(0.0)), then the function returns the
value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the
return type, with the same sign as the correct value of the function;
if the integer expression math_errhandling & MATH_ERRNO is nonzero,
the integer expression errno acquires the value ERANGE; if the integer
expression math_errhandling & MATH_ERREXCEPT is nonzero, the
‘‘divide-by-zero’’ floating-point exception is raised if the
mathematical result is an exact infinity and the ‘‘overflow’’
floating-point exception is raised otherwise.

We can see from a live example using -S flag to generate assembly and grep log to filter out calls to log.

In the case of log(0.0) the following instruction is generated (see it live):

call    log

but in the case of log(10.0) no call log instruction is generated, (see it live).

We can usually prevent gcc from using builtin function by using the -fno-builtin flag which is probably a quicker way to test whether a builtin is being used.

Note that -lm needs to go after the source file, for example (taken from linked answer) if main.c required the math library then you would use:

 gcc main.c -lm 

---

Related Topics