Re: [Flightgear-devel] MSVC build error
Selon bass pumped : Hi everyone, I tried to compile the latest version of flightgear today in MSVC 7. It compiled fine... but then I had problems when it tried linking. Any ideas on how to fix it would help. Thank you in advance. Start ouput Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Don't use that option. Be sure you compiled all programs and libraries with the same 'Code Generation' options. /MT is fine if it is everywhere. .\Debug/FlightGear.exe : fatal error LNK1120: 119 unresolved externals You have to add all the files containing the unresolved symbols in you solution in order to compile and link them to fgfs.exe For exemple, in the line : environment.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_turbulence_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual double __thiscall FGEnvironment::get_turbulence_magnitude_norm(void)const ([EMAIL PROTECTED]@@UBENXZ) it is said that the SGEnviro class ( the name before :: ) is missing. A quick search in the source tree tells me that it is in simgear/environment/visual_enviro.cxx that has to be added in the simgear project file. Do that until you have no unresolved external. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
On Wednesday 21 September 2005 19:54, Oliver Schroeder wrote: The problem lies in XDR_encode_double() and XDR_decode_double(). Making all arguments const did the trick. You can find my updated version here: http://www.o-schroeder.de/fg_server/tinyxdr.tgz please test it. I can confirm that it works perfectly here, thanks. AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Oliver Schroeder wrote: The problem lies in XDR_encode_double() and XDR_decode_double(). Making all arguments const did the trick. You can find my updated version here: http://www.o-schroeder.de/fg_server/tinyxdr.tgz It's committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Andy Ross wrote: This is the relevant code from simgear/compiler.h. Apparently it thinks that Solaris machines lack a stdint.h header file. This is incorrect, at least on the Solaris 10 box I have access too. The workaround should be to just eliminate the || defined(sun) bit. #if defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed __int64 int64_t; typedef unsigned charuint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; #endif Note that it also includes these definitions for mingw builds, which is incorrect. The mingw compiler is a gcc variant, which includes stdint.h as part of the compiler suite; it is not a platform header. As far as I can see, MSVC is the only compiler we use that lacks this. This has been fixed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear patch for 64 bit and GCC3
Alex Perry wrote: I get a compiler type cast error without this (or equivalent). This has also been committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] new multiplayer patch
Erik Hofman Oliver Schroeder wrote: The problem lies in XDR_encode_double() and XDR_decode_double(). Making all arguments const did the trick. You can find my updated version here: http://www.o-schroeder.de/fg_server/tinyxdr.tgz It's committed. Erik That seems to break Simgear under Cygwin: swap_test.cpp:12: error: invalid conversion from `uint32_t*' to `unsigned int*' swap_test.cpp:12: error: initializing argument 1 of `void sgEndianSwap(unsigned int*)' I don't think swap_test.cpp does anything, so I've removed it from the makefile here Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Vivian Meazza wrote: swap_test.cpp:12: error: invalid conversion from `uint32_t*' to `unsigned int*' Ok, this is fixed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] type conversion problem for amd64
George Patterson wrote: lowlevel.cxx:84: error: invalid conversion from `uint64_t*' to `long long unsigned int*' I noticed this too. The problem is that on 64 bit systems the glibc headers have: typedef unsigned long int uint64_t; Which is correct, because a long is a 64 bit type on x86_64. Unfortunately (any C++ standards nutjobs on the list might want to clarify), it seems to be illegal according to the spec to cast between pointers to long and long long, even on platforms where they are of the same size. The identical code compiles fine with no warnings under ANSI C. I suspect the real bug here is that glibc picks a type for uint64_t that C++ thinks is different from the *other* (more portable) 64 bit integer type. But the fix for us is trivial: just change unsigned long long to uint64_t and it works. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Elevation Contours and DEM experiment results
Hi all, as we had the original discussion about elevation contours on the flightgear-devel list, I'm crossposting this to flightgear-devel and to terragear-devel, however I'd suggest replying to terragear-devel as this is essentially a TerraGear issue. After the discussion about integrating elevation contours into TerraGear-generated scenery I did some experiments using digitised elevation contours from current topographical maps and interpolations from the standard SRTM DEM data. I used GRASS to digitise contour data from scanned topographical maps and generate a DEM model with about 4m/pixel resolution for a small region using the v.surf.rst tool from GRASS. The resolution is quite arbitrary, as it is the resolution of my scanned topomaps. Then I interpolated the SRTM data for the same region and resolution using a cubic interpolation. I found that both the interpolated SRTM DEMs and the DEMs generated from the contour lines are quite similar. Generating contours from the interpolated SRTM DEMs and laying them over the digitised contours confirmed this finding. The contours do not differ substantially from each other. I then interpolated the SRTM DEMs for some other regions, generated contours and overlaid them to the topomaps. Again, the contours from the interpolated SRTM DEMs quite well match those from the topomaps - at least I think that the differences in terrain won't be noticable for the human eye. Unfortunately I've thrown away the manually digitised countour lines - being a bit frustrated by the result - and for copyright reasons I cannot post an overlay of the contours generated from the SRTM DEMs and the topomaps I'm using. I'll however repeat the digitalisation for another area and post that together with the respective SRTM DEM contours if anybody is interested in a direct comparison. I then tried to import the fitted irregular elevation grid generated by Terra into GRASS and created an appropriate DEM for a small region. v.surf.rst does a spline interpolation, which will differ substantially from the flat approximation done by Terra and FlightGear for obvious reasons. I haven't found an appropriate tool in GRASS to do a linear interpolation, however I tried v.surf.rst with a smoothing setting of 0, making the interpolated surface go directly through the points of the irregular grid instead of approximating them smoothly. I calculated the differences between this interpolation and the interpolated SRTM DEM and found a standard deviation of about 43m. The irregular grid was generated using a maximum error of 40m and a maximum number of 1000 nodes. However the maximum deviation between the two DEMs is about 240m at at least one point. However this could be due to the non-linear interpolation of the grid. My conclusions from this are twofold: 1. There is no need to digitise contour data manually instead of extracting them from SRTM if your map material is based on SRTM - which seems to be the case for all of the maps I'm using. 2. The only advantage of integrating contour lines directly into the terrain would be to effectively bypass the fitting done by Terra. I'll try to get some comparisons up with real-life photos and Terra-fitted terrain, but I already got the impression that at least in the area we're working on with our custom scenery the hills and mountains just don't look right ;-) Maybe applying an interpolation in Terra similar to the one done by GRASS could yield some better looking results. Just thinking out loud here. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear and OpenAL files/Cygwin
Hi AJ, thank you for your prompt reply, therefore this as a feedback: I tested it with Normans precompiled version and the (older) stuff I need for building FG 0.9.8 but still got the same error messages when typing ./configure from SimGear-0.3.8. Just downloading all the actual CVS stuff for SimGear and FlightGear I will have another try with the more actual files, hopefully ... :-/ If I am not lucky I will ask again as I started to work seriously with FlightGear this August and though spending a lot of time reading all docs and testing things I am a bloody beginner! Once again, thank you for your help and time Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
On 9/22/05, Frederic Bouvier [EMAIL PROTECTED] wrote: Selon bass pumped : Hi everyone, I tried to compile the latest version of flightgear today in MSVC 7. It compiled fine... but then I had problems when it tried linking. Any ideas on how to fix it would help. Thank you in advance. Start ouput Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Don't use that option. Be sure you compiled all programs and libraries with the same 'Code Generation' options. /MT is fine if it is everywhere. .\Debug/FlightGear.exe : fatal error LNK1120: 119 unresolved externals You have to add all the files containing the unresolved symbols in you solution in order to compile and link them to fgfs.exe For exemple, in the line : environment.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_turbulence_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual double __thiscall FGEnvironment::get_turbulence_magnitude_norm(void)const ([EMAIL PROTECTED]@@UBENXZ) it is said that the SGEnviro class ( the name before :: ) is missing. A quick search in the source tree tells me that it is in simgear/environment/visual_enviro.cxx that has to be added in the simgear project file. Do that until you have no unresolved external. -Fred Hi Fred, Thanks a lot for your suggestion. It helped and I managed to get rid of some of the linking errors. But I'm still stuck with another 74 errors I hope you will be able to help me locate and fixed. I've noticed the errors revolve around the gz function, the sgsoundmanager (which to me looks like an maybe an openal error??)... If you could take a quick look at the error output and point me in the right direction. Thank you very much. Start output Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LIBCMTD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in LIBCMT.lib(malloc.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in LIBCMT.lib(malloc.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: _calloc already defined in LIBCMT.lib(calloc.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: _realloc already defined in LIBCMT.lib(realloc.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: _free already defined in LIBCMT.lib(free.obj) LIBCMTD.lib(dbgheap.obj) : error LNK2005: __msize already defined in LIBCMT.lib(msize.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in LIBCMT.lib(sbheap.obj) LIBCMTD.lib(isctype.obj) : error LNK2005: __isctype already defined in LIBCMT.lib(isctype.obj) LIBCMTD.lib(isctype.obj) : error LNK2005: ___isctype_mt already defined in LIBCMT.lib(isctype.obj) LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library new_gui.obj : error LNK2001: unresolved external symbol class puFont FONT_SANS_12B (?FONT_SANS_12B@@3VpuFont@@A) new_gui.obj : error LNK2001: unresolved external symbol class puFont FONT_HELVETICA_14 (?FONT_HELVETICA_14@@3VpuFont@@A) main.obj : error LNK2019: unresolved external symbol __imp__alListenerf referenced in function public: void __thiscall SGSoundMgr::set_volume(float) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) fg_fx.obj : error LNK2001: unresolved external symbol __imp__alListenerf SimGear.lib(soundmgr_openal.obj) : error LNK2001: unresolved external symbol __imp__alListenerf main.obj : error LNK2019: unresolved external symbol __imp__alListenerfv referenced in function public: void __thiscall SGSoundMgr::set_listener_pos(float *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) SimGear.lib(soundmgr_openal.obj) : error LNK2001: unresolved
