Fortran - g95: undefined symbol

Author

g95: undefined symbol

Dominique Orban

2004-12-16, 4:05 pm

Hello,

I am building shared libraries to be loaded from within Python. I don't
believe my question is Python-specific and I am most likely missing
something obvious. The libraries are made of F77, F90 and C source code.

library1.so contains only F77 and F90 code and this F90 code has defined
modules.

library2.so contains an F90 interface to the code in library1.so and a C
interface to Python. When i compile it, i specify where to find module
information.

All compiles well and runs well with the Intel compiler.
All compiles well with g95, but when i try to run an example using
library2.so, i get

undefined symbol '_g95_section_info'

'nm' reveals that this symbol is indeed undefined in library2.so, but is
defined in library1.so.

As an additional clue, when i merge all the sources making up
library1.so and library2.so into a single library, all compiles and runs
well. I can't reasonably keep them merged though, for licensing reasons.

I must have missed something obvious, but what it is just isn't striking
me. I would really appreciate any help.

Thanks in advance,
Dominique

Dr Ivan D. Reid

2004-12-16, 8:57 pm

On Thu, 16 Dec 2004 13:32:27 GMT, Dominique Orban <Dominique.Orban@polymtl.ca>
wrote in <L7gwd.308075$0f.221527@charlie.risq.qc.ca>:

> All compiles well and runs well with the Intel compiler.
> All compiles well with g95, but when i try to run an example using
> library2.so, i get

> undefined symbol '_g95_section_info'

> 'nm' reveals that this symbol is indeed undefined in library2.so, but is
> defined in library1.so.

> As an additional clue, when i merge all the sources making up
> library1.so and library2.so into a single library, all compiles and runs
> well. I can't reasonably keep them merged though, for licensing reasons.

> I must have missed something obvious, but what it is just isn't striking
> me. I would really appreciate any help.

How are you linking the objects? Some (most?, many?) linkers
don't do "backtracking" -- i.e. when the library moves on from processing
library A to library B, it keeps no record about entry points in library A
that have not been referenced by that point; if library B then references
such an unrecorded entry point, the linkker does not know where to find
it. I've had problems with this back to PDP-11 days and beyond, but can't
point to any current state-of-play. Sometimes library order can be
manipulated to get all the references in the right order, other times it's
necessary to just include library A again after library B (I have vague
memories of one linker that allowed you to do this but specifying which
entry should be sought).

--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@brunel.ac.uk Room 40-1-B12, CERN
GSX600F, RG250WD. "You Porsche. Me pass!" DoD #484 JKLO# 003, 005
WP7# 3000 LC Unit #2368 (tinlc) UKMC#00009 BOTAFOT#16 UKRMMA#7 (Hon)
KotPT -- "for stupidity above and beyond the call of duty".

Sponsored Links