compiling c# mapscript on F7-x86_64
Tamas Szekeres
szekerest at GMAIL.COM
Tue Jun 12 08:19:02 EDT 2007
Mike,
I still couldn't reproduce this behaviour. Did the shpdump sample
display any features from the shapefile?
Is the following bug relevant to this problem?
http://trac.osgeo.org/mapserver/ticket/1598
Do the test run if you remove the shpdump test in the csharp makefile?
Best regards,
Tamas
2007/6/9, Mike Leahy <mgleahy at golden.net>:
> Hello again,
>
> I don't know if this helps at all, but I gave the C# dll I built a try
> with my application despite the output from the make test...turns out it
> actually works. Granted, my application does relatively little at the
> moment (it essentially creates a map object with a PostGIS layer, and
> draws the image), so this isn't a thorough test, but perhaps there's a
> problem with the make test operation instead (at least in my context)?
>
> Regards,
> Mike
>
> Tamas Szekeres wrote:
> > 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