OK, I'll zero in on that. One thing I noticed was that the "swig/csharp/gdal" directory has a "makefile.vc", but not a GNUmakefile.
During one of my numerous experiments, I manually compiled "swig/csharp/gdal_wrap.o" by running gcc -shared -Wl,-soname,libgdal_wrap.so -o libgdal_wrap.so gdal_wrap.o (or something like that). Of course the strace output doesn't show any calls to *wrap*. Different naming convention. This might be irrelevant, but at this point I don't enough to rule out anything. I realize that from your perspective this looks like random flailing, and I have to admit it is. Once again thanks very much for the ideas. When I finally resolve this, I'll definitely created a detailed post. -----Original Message----- From: Tamas Szekeres [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2008 10:49 AM To: Evans, Frank Cc: gdal-dev@lists.osgeo.org Subject: Re: [Gdal-dev] c# Bindings in Mono/Linux Frank, It looks like either libgdalcsharp.la or one of it's dependencies is not available to load, or incorrect version can be loaded with the current LD_LIBRARY_PATH setting. Please check that the same version of gdal is loading that the csharp bindings have been compiled against. Best regards, Tamas 2008/7/22 Evans, Frank <[EMAIL PROTECTED]>: > I agree the dll.config isn't the main issue. I've tried renaming files, > linking statically, linking dynamically. After a while, experimentation > makes the baseline suspect, so I blast it and start over. Its definitely > something on my end. Some basic mistake. I need to get more > swig-knowledge. > > Thanks again for all your help. BTW, I ran "strace -e trace=open mono > GDALInfo.exe ..." > > > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > open("libgdalcsharp.la", O_RDONLY|O_LARGEFILE) = 4 > open("./.libs/libgdalcsharp.so.1", O_RDONLY) = 4 > > -----Original Message----- > From: Tamas Szekeres [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 5:04 PM > To: Evans, Frank > Cc: gdal-dev@lists.osgeo.org > Subject: Re: [Gdal-dev] c# Bindings in Mono/Linux > > > Frank, > > I've committed in the SVN trunk to produce well formed xml with the > development version. However I doubt if it causes this problem. > Probably your environment settings like incorrect LD_LIBRARY_PATH > prevents from loading the gdal so or the related so-s (like proj). > At the buildbot configurations those pathes have been set manually to > the correct directories. > > Best regards, > > Tamas > > > > 2008/7/21 fevans <[EMAIL PROTECTED]>: >> >> Tamas, with regards to mono/gdal bindings, I suspect I'm doing > something >> wrong in the build process. Clearly the buildbots are passing. >> >> One item that's been bothering me is line 50 of > "swig\csharp\GNUMakefile" >> Its generating a config-xml wrapper for the dll, but thet XML is > mal-Formed. >> >> echo "<dllmap dll=\""$*"_wrap\" target=\""$@"\">" >> > $*_csharp.dll.config >> >> Generates: <dllmap dll="gdal_wrap" target="libgdalcsharp.la"> >> Should be: <dllmap dll="gdal_wrap" target="libgdalcsharp.la" /> >> >> So either these wrappers are not used, or I'm digging in the wrong > place. >> The nightly builds at "http://buildbot.osgeo.org/gdal-full/"; are still >> inaccessible. >> >> >> ./mkinterface.sh >> make -f GNUmakefile >> >> ==================================================== >> make test >> LC_ALL=C mono createdata.exe Data pointlayer >> >> Unhandled Exception: System.TypeInitializationException: An exception > was >> thrown by the type initializer for OSGeo.OGR.gr ---> >> System.TypeInitializationException: An exception was thrown by the > type >> initializer for OSGeo.OGR.OgrPINVOKE --> > System.TypeInitializationException: >> An exception was thrown by the type initializer for > SWIGExceptionHelper ---> >> Systm.DllNotFoundException: libogrcsharp.la >> at (wrapper managed-to-native) >> SWIGExceptionHelper:SWIGRegisterExceptionCallbacks_Ogr >> > (OSGeo.OGR.OgrPINVOKE/SWIGExcepionHelper/ExceptionDelegate,OSGeo.OGR.Ogr > PINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGE > xceptinHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper > /ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionelper/ExceptionDele > gate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/ExceptionDelegate,OSGeo.OG > R.OgrPINVOKE/SWIGExceptionHeper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/S > WIGExceptionHelper/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionH > elpr/ExceptionDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelper/Exceptio > nDelegate,OSGeo.OGR.OgrPINVOKE/SWIGExceptionHelperExceptionDelegate) >> at OSGeo.OGR.OgrPINVOKE+SWIGExceptionHelper..cctor () [0x00000] --- > End of >> inner exception stack trace --- >> >> at OSGeo.OGR.OgrPINVOKE..cctor () [0x00000] --- End of inner > exception >> stack trace --- >> >> at OSGeo.OGR.Ogr..cctor () [0x00000] --- End of inner exception stack >> trace --- >> >> at CreateData.Main (System.String[] args) [0x00000] >> make: *** [test] Error 1 >> ==================================================== >> >> >> Tamas Szekeres wrote: >>> >>> 2008/6/11 Evans, Frank <[EMAIL PROTECTED]>: >>>> Tamas, thanks for the test-results link. I had read that tests were >>>> passing, but the log-detail provided a lot of useful info. I will > try >>>> SWIG 1.3.31 this weekend, and let everyone know. I can't switch mono >>>> versions, at least not easily. Are the library outputs for the > automated >>>> builds accessible? >>>> >>> >>> The build directory of the linux builders used to be accessible from >>> the following link: >>> http://buildbot.osgeo.org/gdal-full/ >>> http://buildbot.osgeo.org/gdal-quick/ >>> >>> But it seems like having a permission problem at the moment. >>> >>>> I know I'm asking for speculation, but do you think there's a >>>> 32-bit/64-bit issue? >>>> >>> >>> I`ve been trying on debian AMD64 as I`ve noted in my previous post so >>> I doubt that this is a 64 bit OS related issue. >>> The version of swig and mono might even more be an issue. >>> >>> Best regards, >>> >>> Tamas >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >>> >> >> -- >> View this message in context: > http://www.nabble.com/c--Bindings-in-Mono-Linux-tp17709337p18570865.html >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
