Compiling mapscript-csharp on Linux [solved]

[Tamas Szekeres]

Mike,

I consider this issue might be dedicated to a configuration issue
rather than solely a mapscript C# issue.

But in fact the csharp makefile.in passes the FLAGS parameter to the
swig command line so as to avoid some further problems.

Normally the FLAGS contains the configure specific switches and the
includes. From this aspect it is slightly unfriendly that the mygis
specific  MYGIS_INC contains other funky options that the SWIG cannot
recognize. I will look into this for a workaround ASAP.

I think the fastcgi dependency is not needed for the mapscript csharp
library and should be
disabled when compiling the code. However it would be difficult to
support all of these variations during the same configuration phase.
So I guess you should make different compilations accordingly.

Best Regards,


Tamas Szekeres


2006/11/7, Mike Leahy <mgleahy at golden.net>:
> Hello again,
>
> I finally figured out my problem.  I found that if I tried compiling
> MapServer/MapScript-CSharp with minimal options, it seemed to work okay.
>   After this, I was ultimately able to determine that the error comes
> after I compile MapServer with FastCGI enabled, then compile the
> mapscript csharp module.  Once I dropped this option, from my
> configuration, it worked fine (though I still have the original issue I
> posted about the MySQL-related "Unrecognized options" reported by SWIG,
> which have to be commented-out in the Makefile).  I figure it should be
> safe to recompile the mapserver CGI executables with FastCGI after I've
> finished making the csharp module.  Beside this problem I've found with
> the mapscript module, is there any reason should I not enable FastCGI?
>
> Thanks again for any info,
> Mike
>
>
> Mike Leahy wrote:
> > Hello again,
> >
> > It looks like I am having problems with the mapscript_csharp library.
> >
> > Earlier, I had neglected to run 'make test', and now that I do, I find
> > I'm getting an Unhandled Exception (see below).  It seems that it is the
> > libmapscript.so that has this problem, since if I use the
> > mapscript_csharp.dll in windows with a pre-compiled copy of
> > mapscript.dll, it works fine as far as I can tell.  Once I try to do the
> > same in Linux with the libmapscript.so that I compiled, it fails with
> > the same errors as the make test output.  I'm not sure why I would get a
> > System.DllNotFoundException - I tried copying the library to my lib
> > folder.  If it try 'ldd libmapscript.so', the output also looks okay.
> >
> > I might also point out that I had a number of funny error messages about
> > incompatible libraries at the end of the compile process, when the
> > php_mapscript.so library is created.  These messages look something like
> > "/usr/bin/ld: skipping incompatible /usr/lib/lxml2.so when searching for
> > -lxml2", and the list is pretty long.  So far, it seems the library
> > loads fine in PHP, though I haven't had a chance to test it with an
> > actual map yet.  Could the fact that I'm running on an x86_64 version of
> > Fedora 6 be a problem?
> >
> > I hope somebody on the list can give me some insight into this problem.
> >
> > Mike
> >
> > ============ output from 'make test' in mapscript/csharp ==========
> >
> >
> > mgleahy at localhost csharp]$ make test
> > LC_ALL=C mono ./shpdump.exe ../../tests/point.shp
> >
> > Unhandled Exception: System.TypeInitializationException: An exception
> > was thrown by the type initializer for mapscriptPINVOKE --->
> > System.TypeInitializationException: An exception was thrown by the type
> > initializer for SWIGExceptionHelper ---> System.DllNotFoundException:
> > libmapscript.so
> >   at (wrapper managed-to-native)
> > SWIGExceptionHelper:SWIGRegisterExceptionCallbacks_mapscript
> > (mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate,mapscriptPINVOKE/SWIGExceptionHelper/ExceptionDelegate)
> >
> >   at mapscriptPINVOKE+SWIGExceptionHelper..cctor () [0x00000] --- End of
> > inner exception stack trace ---
> >
> >   at <0x00000> <unknown method>
> >   at mapscriptPINVOKE..cctor () [0x00000] --- End of inner exception
> > stack trace ---
> >
> >   at <0x00000> <unknown method>
> >   at shapefileObj..ctor (System.String filename, Int32 type) [0x00000]
> >   at ShapeDump.Main (System.String[] args) [0x00000]
> > make: *** [test] Error 1
> >
> >
> >
> >
> > Mike Leahy wrote:
> >> Hello list,
> >>
> >> I just finished compiling MapServer on FC6, and I was wondering about
> >> some errors I had when I compiled the C# mapscript library.  There is
> >> a line related to the MySQL support in the csharp Makefile that looks
> >> like so:
> >>
> >> MYGIS_INC=  -I/usr/include/mysql -g -pipe -Wp,-D_FORTIFY_SOURCE=2
> >> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> >> -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> >> -D_LARGEFILE_SOURCE -fno-strict-aliasing -fwrapv
> >>
> >> If I leave it as-is, I get the following errors when I attempt to
> >> compile the module with make:
> >>
> >> swig error : Unrecognized option -g
> >> swig error : Unrecognized option -pipe
> >> swig error : Unrecognized option -Wp,-D_FORTIFY_SOURCE=2
> >> swig error : Unrecognized option -fexceptions
> >> swig error : Unrecognized option -fstack-protector
> >> swig error : Unrecognized option --param=ssp-buffer-size=4
> >> swig error : Unrecognized option -m64
> >> swig error : Unrecognized option -mtune=generic
> >> swig error : Unrecognized option -fno-strict-aliasing
> >> swig error : Unrecognized option -fwrapv
> >> Use 'swig -help' for available options.
> >> make: *** [interface] Error 1
> >>
> >> So...I removed everthing on that line starting with '-g', and it
> >> compiled fine.  My question is whether this is something that I'm
> >> likely to run into trouble with later on - I don't generally use
> >> MySQL, so my guess is no.  If anyone has any insight related to this,
> >> I'd be interested to hear it.
> >>
> >> Thanks,
> >> Mike
> >>
> >
>