[neutron-mc] making shared object from mcstas-r.c, under WinXP

[Kristian Nielsen]

Emmanuel Farhi <farhi at ill.fr> writes:

> Hello Timur,
> 
> you have to compile mcstas-r.c with its mcstas-r.h header file, where the undefined symbols are defined as
> 'extern'. Indeed thier value is to be set in the instrument itself, not in the run-time library.
> If the problem persists, send us the full error output so that we see what undefined symbols should be added
> as 'extern'.
> 
> Emmanuel.
> 
> Timur Elzhov wrote:
> 
> > Dear McStas experts,
> >
> > I successfully compiled shared object libmcstas-r.so from mcstas-r.c
> > file, so now I'm able to compile instruments with --no-runtime option,
> > and link it with that library. That is all under _Linux_. But, when
> > I try to do the same under WindowsXP, I get linking error (MinGW compiler
> > was used):
> >   mcstas> gcc -Wno-unused -fPIC -O2 -c mcstas-r.c
> >   mcstas> gcc --shared -o libmcstas-r.dll mcstas-r.o
> >   C:\WINDOWS\TEMP/ccwVaaaa.o(.text+0x498d):mcstas-r.c: undefined reference to `mcinstrument_source'

I am not 100% sure, but I think you may have run into a Windows
limitation.

In Linux, when you load a shared object into a program, the program can
refer to symbols in the shared object, but the shared object can also
refer to symbols in the program. I believe you are using this on Linux.

As far as I know, when a Windows program loads a DLL, the DLL cannot
refer directly to symbols in the program. Thus when you link the shared
object, it complains about missing symbols at link time; at this point
the symbols are not available, since they are not defined until the
instrument code is compiled and linked.

Anyway, perhaps this brings you further. In any case I found it amusing
to see that soneone is finally finding a use for --no-runtime, a feature
I have never before seen used but put in originally many years ago just
because it felt like the rigth thing to do.

 - Kristian.