link symbol underscoring for gfortran on MinGW

[Qianqian Fang]

hi list

I am trying to port a Fortran95 program of mine to windows. The
program depends on liblapack and libumfpack on Linux. So, I first
tried to download/compile these libraries on Windows. After reading a
number of online tutorials, I successfully compiled these libraries
and produced the .a files.

Then when it came to compile/link my program with gfortran. It went
flawlessly up to linking, then a large number of "undefined reference
error" started to show up. Here is a snip of the message:

rb2_dualmesh.o: In function `meshinitializematerial':
d:\Gitroot\Project\redbird\src/rb2_dualmesh.f90:1187: undefined
reference to `dgemm_'
rb2_inversion.o: In function `tikhnovsolve_overrealsimp':
d:\Gitroot\Project\redbird\src/rb2_inversion.f90:1616: undefined
reference to `dgemm_'
d:\Gitroot\Project\redbird\src/rb2_inversion.f90:1632: undefined
reference to `dgemv_'
...
libumfpack.a(umf_zi_local_search.o):umf_local_search.c:(.text+0x426):
undefined reference to `ztrsv_'
libumfpack.a(umf_zi_local_search.o):umf_local_search.c:(.text+0x51f):
undefined reference to `zgemv_'
libumfpack.a(umf_zi_blas3_update.o):umf_blas3_update.c:(.text+0xe4):
undefined reference to `ztrsm_'
libumfpack.a(umf_zi_blas3_update.o):umf_blas3_update.c:(.text+0x195):
undefined reference to `zgemm_'
libumfpack.a(umf_zi_blas3_update.o):umf_blas3_update.c:(.text+0x216):
undefined reference to `zgeru_'

Strangely, if I do "nm rb2_dualmesh.o" or "nm libumfpack.a", all the
lapack function names are shown with a preceeding underscore, i.e.
"_dgemm_", "_dgemv_" etc.

I tried compiling my program with "gfortran -fno-leading-underscore",
the output .o files contains lapack symbol names without the leading
underscore, however, I got numeous linking errors such as "undefined
reference to malloc" or "undefined reference to
gfortran_runtime_error_at".

My question is: when I need to use lapack/blas and umfpack (umfpack is
in C) on Windows, what underscoring options I should be using when I
compile them with gfortran and gcc, respectively? what option I should
use to compile my program which calls these libraries?

My gfortran/gcc version is 4.5.2, the MinGW platform was installed
with mingw-get installer.

I appreciate if anyone can share your experience on this matter.

Qianqian

[Tobias Burnus]

Qianqian Fang wrote:
> Then when it came to compile/link my program with gfortran. It went
> flawlessly up to linking, then a large number of "undefined reference
> error" started to show up. Here is a snip of the message:
>
> rb2_dualmesh.o: In function `meshinitializematerial':
> d:\Gitroot\Project\redbird\src/rb2_dualmesh.f90:1187: undefined
> reference to `dgemm_'
>

> Strangely, if I do "nm rb2_dualmesh.o" or "nm libumfpack.a", all the
> lapack function names are shown with a preceeding underscore, i.e.
> "_dgemm_", "_dgemv_" etc.

I can explain why there is a leading underscore: Microsoft's ABI
requires it. Thus, 32bit Windows programs start with a leading
underscore - independent whether one uses STDCALL or CDECL.
See for instance:
http://msdn.microsoft.com/en-us/library/zkwh89ks%28v=vs.71%29.aspx

I still do not quite understand the "dgemm_" vs "_dgemm_" issue. With
the same compiler, one expects the same names. (I expect "_dgemm_".) I
assume you have compiled the library and your program both with the same
version of gfortran and without any odd compiler/linker flags? Do you
use any !GCC$ directives or BIND(C)? [I think you don't, hence, I just
ask to be sure.]

My first bet would be that the library is not compiled by GCC.

Tobias

[Tim Prince]

A pre-built BLAS library intended for Visual-Studio compatible compilers
will be difficult to use with gfortran, even under mingw. An absolute
minimum requirement would be to use exclusively 32-bit (x86) or 64-bit
(X64) versions of compilers and libraries throughout. You may find it
necessary to build the BLAS functions yourself with your gfortran.

--
Tim Prince

[Qianqian Fang]

hi Tobias

As a matter of fact, the libraries and my program were both compiled
by the same gcc/gfortran in MinGW.

Here is what I did:

I first followed this page:
http://gcc.gnu.org/wiki/GfortranBuild#LAPACK_.28Linear_Algebra_PACKage.29
and compiled liblapack.a with gfortran

Then, I downloaded umfpack 5.1+ufconfig+amd and compile them with
make/gcc

then I copied the .a files to my source folder, and compile my
code with gfortran, and link .o files and *.a files to produce
a binary (which is failed).

I tried adding/removing leading underscores when compiling liblapack.a
the error message is always the same: something like "dgemm_"
undefined.
Strangely, even I see "dgemm_" in the output of nm liblapack.a, the
error
still showed up.

this is so frustrating ...

Qianqian

>
> Tobias

[Qianqian Fang]

On Nov 14, 5:06 pm, Tim Prince <tpri...@computer.org> wrote:
> A pre-built BLAS library intended for Visual-Studio compatible compilers
> will be difficult to use with gfortran, even under mingw.  An absolute
> minimum requirement would be to use exclusively 32-bit (x86) or 64-bit
> (X64) versions of compilers and libraries throughout. You may find it
> necessary to build the BLAS functions yourself with your gfortran.

hi Tim

I wasn't using pre-built libraries. I compiled lapack/blas by
gfortran. See my reply to Tobias for more details.

Qianqian

>
> --
> Tim Prince

[dpb]

On 11/14/2011 4:26 PM, Qianqian Fang wrote:
...

> I tried adding/removing leading underscores when compiling liblapack.a
> the error message is always the same: something like "dgemm_"
> undefined.
> Strangely, even I see "dgemm_" in the output of nm liblapack.a, the
> error
> still showed up.
>
> this is so frustrating ...

...

I'm no expert (in fact, never used gfortran/gcc) but I wonder...

Fortran in general generates uppercase symbols whereas C is
case-retentive. Is that perhaps the problem?

--

[Richard Maine]

Qianqian Fang <fan...@gmail.com> wrote:

> On Nov 14, 4:51 pm, Tobias Burnus <bur...@net-b.de> wrote:
> > Qianqian Fang wrote:
> > > Then when it came to compile/link my program with gfortran. It went
> > > flawlessly up to linking, then a large number of "undefined reference
> > > error" started to show up. Here is a snip of the message:
> >
> > > rb2_dualmesh.o: In function `meshinitializematerial':
> > > d:\Gitroot\Project\redbird\src/rb2_dualmesh.f90:1187: undefined
> > > reference to `dgemm_'

> then I copied the .a files to my source folder, and compile my
> code with gfortran, and link .o files and *.a files to produce
> a binary (which is failed).
>
> I tried adding/removing leading underscores when compiling liblapack.a
> the error message is always the same: something like "dgemm_"
> undefined.
> Strangely, even I see "dgemm_" in the output of nm liblapack.a, the
> error
> still showed up.

Well, considering it is a linking error, I'd think it important to see
the actual command that you link with. "link .o files and *.a files" is
presumably not the actual command. Yes, it can matter.

In particular, I'm suspicious of a link order problem. It sounds much
more like that than a problem with the symbol names. I think the
confusing underscores might be leading you down a completely irrelevant
track. Link order can matter - a lot. Having the right symbols in the .a
file doesn't do any good if the file is in the wrong place in the link
command. The .a file generally needs to be after the references to
things in it. If the .a file is too early, then the linker isn't yet
looking for those names when it scans the .a file; by the time it is
looking for the names, it is no longer looking at the .a file. I
personally happen to think this is a poor way for linkers to work, but
that's the way most of the current ones do.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Steven G. Kargl]

No.

--
steve

[Qianqian Fang]

On Nov 14, 6:21 pm, nos...@see.signature (Richard Maine) wrote:
> Well, considering it is a linking error, I'd think it important to see
> the actual command that you link with. "link .o files and *.a files" is
> presumably not the actual command. Yes, it can matter.

hi Richard

thanks for your reply. In order to replicate the problem by anyone
who want to help, I created a simple test case.

first of all, my windows is an XP. The MinGW
was installed using the mingw-get installer:

http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20110802/

I selected C/C++/Fortran in the installation dialog, which
installed gcc/gfortran 4.5.2 for me.

Then, I went to http://www.netlib.org/lapack/#_lapack_version_3_2_1

and downloaded/unzipped Lapack. I replaced the content of
lapack-3.2.1/make.inc by the recommended config at

http://gcc.gnu.org/wiki/GfortranBuild#LAPACK_.28Linear_Algebra_PACKage.29

I opened an MSYS terminal, navigate to lapack-3.2.1/SRC, typed "make",
this created liblapack-3.2.1/liblapack.a. The output of "nm
liblapack.a"
showed both pre/post underscores (like "_dgemm_" etc)

The next step, I used 3 simple units to test lapack. The links to
these
files are:

http://sourceforge.net/p/blit/code/ci/862d2efb4fabe33325b7fa1b390dae451170d0cb/tree/trunk/blit_f90/src/blqmr/blit_const.f90?format=raw
http://sourceforge.net/p/blit/code/ci/862d2efb4fabe33325b7fa1b390dae451170d0cb/tree/trunk/blit_f90/src/blqmr/blit_matrixutil.f90?format=raw
http://sourceforge.net/p/blit/code/ci/862d2efb4fabe33325b7fa1b390dae451170d0cb/tree/trunk/blit_f90/src/blqmr/blit_matrixutil_sub.f90?format=raw

these saved to blit_const.f90, blit_matrixutils.f90 and
blit_matrixutils_sub.f90. Copy liblapack.a generated previously
to the f90 unit download folder. Navigate to this folder in
MSYS, and type

gfortran -c blit_const.f90
gfortran -DBLIT_SELF_TEST -cpp -c blit_matrixutil.f90
gfortran blit_matrixutil.o blit_const.o liblapack.a -o testlapack

(the -cpp option enables gfortran to interpret the C-styled
preprocessors)
the last command failed with

liblapack.a(dgetrf.o):dgetrf.f:(.text+0x35f): undefined reference to
`dtrsm_'
liblapack.a(dgetrf.o):dgetrf.f:(.text+0x41a): undefined reference to
`dgemm_'
liblapack.a(dgetri.o):dgetri.f:(.text+0x224): undefined reference to
`dswap_'
liblapack.a(dgetri.o):dgetri.f:(.text+0x360): undefined reference to
`dgemv_'
liblapack.a(dgetri.o):dgetri.f:(.text+0x5a2): undefined reference to
`dtrsm_'
...

I really appreciate if anyone can point me to the right direction
on how to solve the above issue.

thanks

Qianqian

[Qianqian Fang]

sorry guys, I think I figured out what happened. I forgot to link with
blas.a!

after appending blas.a (compiled from lapack-3.2.1/BLAS), the linking
of the toy problem went through.

I went back to my other program, the lapack linking errors
disappeared.
The only issue left is to link with umfpack. It still complained:

libblqmr/umf4_f77wrapper.o:umf4_f77wrapper.c:(.text+0x77): undefined
reference t
o `umfpack_di_defaults'
libblqmr/umf4_f77wrapper.o:umf4_f77wrapper.c:(.text+0x8a): undefined
reference t
o `umfpack_zi_defaults'
...

the umf4_f77wrapper.o was compiled from (umf4_f77wrapper creates
aliases)

http://sourceforge.net/p/blit/code/ci/862d2efb4fabe33325b7fa1b390dae451170d0cb/tree/trunk/blit_f90/src/blqmr/umf4_f77wrapper.c

by command

cc -I"C:\MinGW\usr\include\suitesparse" -c -o \
libblqmr/umf4_f77wrapper.o libblqmr/umf4_f77wrapper.c

while all other f90 units were compiled by gfortran:

gfortran -I"C:\MinGW\usr\include\suitesparse" -g -cpp -Wextra -Wall \
-pedantic -O3 -fimplicit-none -J ./output -fbounds-check -o \
UNITNAME.o -c UNITNAME.f90

therefore, the issue is rather a linking-C-library-in-Fortran problem.

any comments?

Qianqian

[Richard Maine]

Qianqian Fang <fan...@gmail.com> wrote:

> On Nov 14, 6:21 pm, nos...@see.signature (Richard Maine) wrote:
> > Well, considering it is a linking error, I'd think it important to see
> > the actual command that you link with. "link .o files and *.a files" is
> > presumably not the actual command. Yes, it can matter.
>

> thanks for your reply. In order to replicate the problem by anyone
> who want to help, I created a simple test case.
>

> first of all, my windows is an XP.....

[details elided]
...

> gfortran blit_matrixutil.o blit_const.o liblapack.a -o testlapack
>
> (the -cpp option enables gfortran to interpret the C-styled
> preprocessors)
> the last command failed with
>
> liblapack.a(dgetrf.o):dgetrf.f:(.text+0x35f): undefined reference to
> `dtrsm_'
> liblapack.a(dgetrf.o):dgetrf.f:(.text+0x41a): undefined reference to
> `dgemm_'
> liblapack.a(dgetri.o):dgetri.f:(.text+0x224): undefined reference to
> `dswap_'
> liblapack.a(dgetri.o):dgetri.f:(.text+0x360): undefined reference to
> `dgemv_'
> liblapack.a(dgetri.o):dgetri.f:(.text+0x5a2): undefined reference to
> `dtrsm_'
> ...
>
> I really appreciate if anyone can point me to the right direction
> on how to solve the above issue.

Ok. That doesn't look like the link order problem I was thinking of. I
don't have a Windows system handy to duplicate it with, though I'm sure
several people here do and that's certainly specific enough data. I did
glance at some of the material you cite, even though I don't have a
duplicate of your system to run it on quite identically.

However, I'll venture another quick guess. My last one looks to have
been wrong, but I'll try again. Looks to me like you did not link in a
copy of the BLAS stuff. The LAPACK distribution includes a copy of a
BLAS implementation, although it recommend using a tuned BLAS for best
performance. Although there is a BLAS implementation included with
LAPACK, I'm not sure that you actually compiled that; or if you compiled
it, I don't see evidence of it being linked in.

See the comments about BLAS in the README in the lapack distribution.
ALso see the BLAS stuff right before the LAPACK stuff on the page that
you cite from the gcc wiki:

<http://gcc.gnu.org/wiki/GfortranBuild#LAPACK_.28Linear_Algebra_PACKage.
29>

I don't see you mentioing having done anything about that. That make.inc
file that you say you used includes instructions to replace
/path/to/blas with the path tothe blas library that you just compiled

I'm suspicious that the things like _dgemm_ that you see in the output
of "nm liblapack.a" do not indicate that dgemm is actually in that
library; I wouldn't expect it to be there anyway. I suspect that instead
what you are seeing is the references to dgemm - the ones that aren't
satisfied because you didn't build or link in a BLAS.

I still think that all the fuss about underscores is just a distraction
from something simpler. My current guess of "something simpler" is that
you aren't compiling and linking the BLAS.

P.S. Not that it probably has anything to do with yourt problem, but I'm
minorly surprised that you are using a 2-year-old version of lapack for
a new installation. When I glanced at the lapack site, I did look at the
version you specified, but I couldn't help noticing that it was several
versions old.