compiling c# mapscript on F7-x86_64

Tamas Szekeres szekerest at GMAIL.COM
Thu Jun 7 15:43:48 PDT 2007


Mike,

I haven't managed to reproduce this issue using the SVN trunk on my
SUSE10 vs MONO 1.2.4 configuration, the make test works fairly well.
I'll be trying to set up an FC7 system to make similar tests but I
guess it will take some days to complete.

Best regards,

Tamas



2007/6/7, Mike Leahy <mgleahy at golden.net>:
> Tamas,
>
> Thanks for the replies.  I'm fairly sure what you're suggesting is not the
> issue in my case.  This is a fresh setup, so there's no previous/other
> versions of mapserver.  I tried what you suggested as well, and I got the
> same output after setting the LD_LIBRARY_PATH to point to my mapserv
> binaries.  Besides that, I've never had to do anything with LD_LIBRARY_PATH
> before.  I'm pretty sure that mapscript_csharp.dll only relies on the
> libmapscript.so that accompanies it (and through that, all of the other
> mapserver dependencies).   As far as I can tell, libmapscript.so is linked
> from the current folder for the 'make test' operation.  If successful, I
> normally copy libmapscript.so to /usr/lib64, along with all the other
> libraries, where it is accessible to any Mono applications that use the
> csharp DLL.
>
> I figure this must be something specific to Fedora 7 and/or Mono-1.2.3.  I
> did try compiling MapServer/MapScript with minimal options to ensure it
> wasn't some of the additional dependencies I'm using (e.g., GDAL, PostGIS,
> etc...) and it still gave the same results.
>
> Any other recommendations?
>
> Regards,
> Mike
>
> On Thu, 7 Jun 2007 20:14:46 +0200, Tamas Szekeres <szekerest at GMAIL.COM> wrote:
>
> >You should check whether other version of mapserver is installed or
> >not. You probably have to set up your mapserver directory in
> >LD_LIBRARY_PATH when running the tests.
> >
> >Best regards,
> >
> >Tamas
> >
> >
> >2007/6/7, Mike Leahy <mgleahy at golden.net>:
> >> I ran ./configure for MapServer with all desired options, ran make, then
> >> went into mapscript/csharp and ran make there.  Is there something else I
> >> should have done?
> >>
> >> On Thu, 7 Jun 2007 18:10:37 +0200, Tamas Szekeres <szekerest at GMAIL.COM>
> wrote:
> >>
> >> >Did you compile the mapserver core and mapscript with the same
> >> >configuration (by using the same GEOS option for example)?
> >> >
> >> >Best regards,
> >> >
> >> >Tamas
> >> >
> >> >
> >> >2007/6/7, Mike Leahy <mgleahy at golden.net>:
> >> >> Hello List,
> >> >>
> >> >> I just finished upgrading one of my 64-bit machines to Fedora 7.  I've
> >> >> already noticed that binary MapServer packages are installable from the
> >> >> repositories.  However, it seems these lack the csharp mapscript module,
> >> >> which is something I use frequently.  So I did my usual routine to
> >> >> compile MapServer from source...everything looked okay, until I ran
> >> >> 'make test' for the c# mapscript module (see output below).  I haven't
> >> >> been able to try this on a 32-bit machine, so can only guess that it
> >> >> might an issue with the 64-bit environment (though FC6-x86_64 with an
> >> >> older version of Mono seemed to work fine).  I'm not sure what to make
> >> >> of this output from the make test - has anyone seen anything like this
> >> >> before, or can anyone make any suggestions?
> >> >>
> >> >> Thanks in advance for any help,
> >> >> Mike
> >> >>
> >> >> ==================================================================
> >> >>
> >> >> [mgleahy at localhost csharp]$ make test
> >> >> LC_ALL=C mono ./shpdump.exe ../../tests/point.shp
> >> >> Stacktrace:
> >> >>
> >> >>   at (wrapper managed-to-native) mapscriptPINVOKE.delete_shapeObj
> >> >> (System.Runtime.InteropServices.HandleRef) <0x00012>
> >> >>   at (wrapper managed-to-native) mapscriptPINVOKE.delete_shapeObj
> >> >> (System.Runtime.InteropServices.HandleRef) <0xffffffff>
> >> >>   at shapeObj.Dispose () <0x00067>
> >> >>   at shapeObj.Finalize () <0x00018>
> >> >>   at (wrapper runtime-invoke) System.Object.runtime_invoke_void
> >> >> (object,intptr,intptr,intptr) <0xffffffff>
> >> >>
> >> >> Native stacktrace:
> >> >>
> >> >>         mono [0x517025]
> >> >>         mono [0x4ddf9d]
> >> >>         /lib64/libpthread.so.0 [0x3fae00dd20]
> >> >>         /lib64/libc.so.6(cfree+0x3b) [0x3fad073acb]
> >> >>         ./libmapscript.so(msFreeShape+0x2c) [0x2aaaab573efc]
> >> >>         ./libmapscript.so(CSharp_delete_shapeObj+0x9) [0x2aaaab53cf69]
> >> >>         [0x4001f90c]
> >> >>
> >> >> Debug info from gdb:
> >> >>
> >> >> (no debugging symbols found)
> >> >> Using host libthread_db library "/lib64/libthread_db.so.1".
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> [Thread debugging using libthread_db enabled]
> >> >> [New Thread 46912496280112 (LWP 16759)]
> >> >> [New Thread 1075988816 (LWP 16761)]
> >> >> [New Thread 1073822032 (LWP 16760)]
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> (no debugging symbols found)
> >> >> 0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> >> >>    from /lib64/libpthread.so.0
> >> >>   3 Thread 1073822032 (LWP 16760)  0x0000003fae00d3d1 in nanosleep ()
> >> >>    from /lib64/libpthread.so.0
> >> >>   2 Thread 1075988816 (LWP 16761)  0x0000003fad0c9ad2 in select ()
> >> >>    from /lib64/libc.so.6
> >> >>   1 Thread 46912496280112 (LWP 16759)  0x0000003fae00a597 in
> >> >> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> >> >>
> >> >> Thread 3 (Thread 1073822032 (LWP 16760)):
> >> >> #0  0x0000003fae00d3d1 in nanosleep () from /lib64/libpthread.so.0
> >> >> #1  0x00000000004c1890 in ?? ()
> >> >> #2  0x0000003fae0061c5 in start_thread () from /lib64/libpthread.so.0
> >> >> #3  0x0000003fad0d062d in clone () from /lib64/libc.so.6
> >> >>
> >> >> Thread 2 (Thread 1075988816 (LWP 16761)):
> >> >> #0  0x0000003fad0c9ad2 in select () from /lib64/libc.so.6
> >> >> #1  0x0000003fb1c5646e in g_spawn_sync () from /lib64/libglib-2.0.so.0
> >> >> #2  0x0000003fb1c56838 in g_spawn_command_line_sync ()
> >> >>    from /lib64/libglib-2.0.so.0
> >> >> #3  0x00000000005170c7 in ?? ()
> >> >> #4  0x00000000004ddf9d in ?? ()
> >> >> #5  <signal handler called>
> >> >> #6  0x0000003fad073acb in free () from /lib64/libc.so.6
> >> >> #7  0x00002aaaab573efc in msFreeShape () from ./libmapscript.so
> >> >> #8  0x00002aaaab53cf69 in CSharp_delete_shapeObj () from ./libmapscript.so
> >> >> #9  0x000000004001f90c in ?? ()
> >> >> #10 0x00002aaaaacf8d20 in ?? ()
> >> >> #11 0x0000000000a86770 in ?? ()
> >> >> #12 0x0000000000000001 in ?? ()
> >> >> #13 0x0000003fae00fa28 in g_str_equal () from /lib64/libpthread.so.0
> >> >> #14 0x0000000000a29390 in ?? ()
> >> >> #15 0x0000000040223c80 in ?? ()
> >> >> #16 0x0000000040223ee0 in ?? ()
> >> >> #17 0x000000004001f862 in ?? ()
> >> >> #18 0x0000000000a37e68 in ?? ()
> >> >> #19 0x0000000040223ee0 in ?? ()
> >> >> #20 0x0000000040223e50 in ?? ()
> >> >> #21 0x00002aaaaacf8d20 in ?? ()
> >> >> #22 0x00002aaaaaad3e60 in ?? ()
> >> >> #23 0x0000000000a86770 in ?? ()
> >> >> #24 0x00002aaaaacf8d20 in ?? ()
> >> >> #25 0x0000000000a86770 in ?? ()
> >> >> #26 0x00002aaaaacf8d20 in ?? ()
> >> >> #27 0x00000000007ccc08 in ?? ()
> >> >> #28 0x000000004001f690 in ?? ()
> >> >> #29 0x0000000000a5f0b0 in ?? ()
> >> >> #30 0x0000000040223f50 in ?? ()
> >> >> #31 0x000000004001f5d8 in ?? ()
> >> >> #32 0x00002aaaaacf8d20 in ?? ()
> >> >> #33 0x0000000000a86770 in ?? ()
> >> >> #34 0x0000000000000001 in ?? ()
> >> >> #35 0x0000000000000011 in ?? ()
> >> >> #36 0x00002aaaaacf8d20 in ?? ()
> >> >> #37 0x00002aaaaacf8d20 in ?? ()
> >> >> #38 0x00002aaaaaad3e60 in ?? ()
> >> >> #39 0x0000000000a867e0 in ?? ()
> >> >> #40 0x0000000000000000 in ?? ()
> >> >>
> >> >> Thread 1 (Thread 46912496280112 (LWP 16759)):
> >> >> #0  0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> >> >>    from /lib64/libpthread.so.0
> >> >> #1  0x00000000004bf110 in ?? ()
> >> >> #2  0x00000000004c160d in ?? ()
> >> >> #3  0x00000000004c5b95 in ?? ()
> >> >> #4  0x000000000046ccc6 in mono_domain_finalize ()
> >> >> #5  0x00000000004dc754 in ?? ()
> >> >> #6  0x0000000000414678 in mono_main ()
> >> >> #7  0x0000003fad01daa4 in __libc_start_main () from /lib64/libc.so.6
> >> >> #8  0x0000000000413319 in g_str_equal ()
> >> >> #9  0x00007fff93e6c348 in ?? ()
> >> >> #10 0x0000000000000000 in ?? ()
> >> >> #0  0x0000003fae00a597 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
> >> >>    from /lib64/libpthread.so.0
> >> >>
> >> >>
> >> >> =================================================================
> >> >> Got a SIGSEGV while executing native code. This usually indicates
> >> >> a fatal error in the mono runtime or one of the native libraries
> >> >> used by your application.
> >> >> =================================================================
> >> >>
> >> >> make: *** [test] Aborted
> >> >>
> >>
>



More information about the MapServer-users mailing list