WHIZARD does not work with NAG 5.2 32bit compiler

[Juergen Reuter]

Here, make check etc. do not work because of unresolved or not found symbols in the O'Mega library. This is a typical error message:

NAG Fortran Compiler Release 5.2(686)
Option warning: Unrecognised option -shared passed to loader
libtool: link: (cd ".libs" && rm -f "processes.so.0" && ln -s "processes.so.0.0.0" "processes.so.0")
libtool: link: (cd ".libs" && rm -f "processes.so" && ln -s "processes.so.0.0.0" "processes.so")
libtool: link: ar cru .libs/processes.a  zh.o ww.o processes.o
libtool: link: ranlib .libs/processes.a
libtool: link: ( cd ".libs" && rm -f "processes.la" && ln -s "../processes.la" "processes.la" )
| Loading process library 'processes'
*** Fatal error: /afs/physik.uni-freiburg.de/home/reuter/Physik/progs/omwhiz/svn/trunk/src/.libs/libomega.so.0: undefined symbol: exit_
WHIZARD run aborted.

[Juergen Reuter]

I reproduced this with the newer NAG version 717. Still the same. Here is the output from nm libomega.so.0:

0007d640 t __do_global_dtors_aux
0045b420 d __dso_handle
0045400c d __DTOR_END__
00454008 d __DTOR_LIST__
00454014 a _DYNAMIC
00465458 A _edata
004d76e0 A _end
         U exit_
         U file_utils_MP_free_unit
0044a014 T _fini
0007d6a0 t frame_dummy
004539f8 r __FRAME_END__
00472cf4 b _ftf_.10154
00467f94 b _ftf_.10586
00468b94 b _ftf_.10586
00476404 b _ftf_.10815
004663ac b _ftf_.10819
00466bd0 b _ftf_.10859
00476408 b _ftf_.10912
0047640c b _ftf_.11320

It appears together with file_utils.free_unit. Does this come from the 3SHL model and its Fortran modules? Cyclic dependencies? libomega -> libwhizard -> libomega

[kilian]

Just reproduced it. It's not specific to 32bit. And it appeared very recently.

I'd also guess that this is the 3SHL stuff.

(Without blaming anyone, I'd recommend to disable this for RC1 if the issue is not easily solved.)

[kilian]

I have a workaround almost ready -- (early tomorow)

[Christian Speckner]

OK, I'm dreadfully sorry, my bad, I am using exit in my 3SHL library as part of the error handling system (although the code will never be called when used within WHIZARD), and forgot that this is nonstandard - NAG is the first compiler I meet that doesn't know it. Therefore, the symbol is unresolved when using NAG, and it then depends on the interpretation of the "1" in dlopen (see #136) whether this triggers an error - for example, I couldn't reproduce it myself with NAG. I checked in a fix which makes the unresolved symbol vanish, and ldd shows that it is indeed gone. Sorry again for the trouble.

[Juergen Reuter]

Milestone v2.0.0final deleted