OK... now it gets through the whole build without "errors," but it doesn't end up making the csplugin dll. I get some crap like this during the csplugin build:
/bin/sh ../../../libtool --mode=link g++ -O1 -D_REENTRANT -D_MT -mthreads -g -Wall -I/c/vos-projects/current/vos /inplace/include -mthreads -L/c/vos-projects/current/vos/inplace/lib -o libvos_csplugin.la -rpath /usr/local/lib -no-undefined -module -L../../../inplace/lib libvos_csplugin_la-csvosa3dl.lo libvos_csplugin_la-voscone.lo libvos_csplugin_la-voslight.lo libvos_csplugin_la-vosmodel.lo libvos_csplugin_la-vossector.lo libvos_csplugin_la-vosbillboard.lo libvos_csplugin_la-voscube.lo libvos_csplugin_la-voslightmapcache.lo libvos_csplugin_la-vosobject3d.lo libvos_csplugin_la-vossphere.lo libvos_csplugin_la-vosclone.lo libvos_csplugin_la-voscylinder.lo libvos_csplugin_la-vosmaterial.lo libvos_csplugin_la-vospolygonmesh.lo libvos_csplugin_la-vostexture.lo -lvutil -lvip -lvos -lmetaobject_a3dl -lmet aobject_misc -lircclient -L/c/vos-projects/current/vos/inplace/lib -lcrystal space -lzlib -L/C/vos-projects/CrystalSpaceLibs1.0_001/mingw-gcc-3.4/lib - L/C/vos-projects/CrystalSpaceLibs1.0_001/mingw/lib -L/C/vos-projects/Crystal SpaceLibs1.0_001/common/lib -lm -Wl,--warn-unresolved-symbols -Wl,-E -g3 -L/ usr/lib/w32api -lgdi32 -lshell32 -lboost_thread-mgw-mt-1_33_1 -lws2_32 *** Warning: linker path does not have real file for library -lcrystalspace. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libcrystalspace and none of the candidates passed a file format test *** using a file magic. Last file checked: /c/vos-projects/current/vos/inplace/lib/libcrystalspace.a *** Warning: linker path does not have real file for library -lzlib. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libzlib and none of the candidates passed a file format test *** using a file magic. Last file checked: /c/vos-projects/current/vos/inplace/lib/libzlib.dll *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libvos_csplugin. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. libcrystalspace.a exists and "file" detects it just fine, so I don't know what's going on there. libzlib.dll is an empty (size-0) file, so I really don't know what's going on there. More mysteriously... libtool doesn't complain when it links terangreal... but when run, it complains about no iVosA3DL plugin, obviously. Even stranger -- the first make run made a size-0 wxterangreal.exe. Re-running "make" on the terangreal directory copied over a fully-formed wxterangreal.exe. Looks like some sort of file system synch problem.... perhaps something similar occurred with libzlib; but I can't figure out where that file comes from. I'll probably get more time to hack with this on tuesday. But just in case anyone has any ideas, I'll throw it out there :P -Ken ----- Original Message ----- From: "Ken Taylor" <[EMAIL PROTECTED]> To: "VOS Discussion" <vos-d@interreality.org> Sent: Saturday, February 24, 2007 11:36 PM Subject: Re: [vos-d] Compiling 0.24 with mingw on windows2000 > New fun: > > > g++ -DHAVE_CONFIG_H -I. -I. -I../../../libs/vos -I../../../libs -I../../../i > nplace/include -DVOSTOOLBOX_EXPORTS -D_REENTRANT -D_MT -mthreads -I/c/vos-pr > ojects/current/vos/inplace/include -D_REENTRANT -O1 -D_REENTRANT -D_MT -mthr > eads -g -Wall -I/c/vos-projects/current/vos/inplace/include -MT > reciprocalpropfilter.lo -MD -MP -MF .deps/reciprocalpropfilter.Tpo -c > reciprocalpropfilter.cc -DDLL_EXPORT -DPIC -o .libs/reciprocalpropfilter.o > In file included from > ../../../libs/vos/vostoolbox/reciprocalpropfilter.hh:10, > from reciprocalpropfilter.cc:3: > ../../../libs/vos/vutil/stringutil.hh:15: error: function `std::string > VUtil::numToString(const int&)' definition is marked dllimport. > ../../../libs/vos/vutil/stringutil.hh:22: error: function `std::string > VUtil::numToString(const unsigned int&)' definition is marked dllimport. > ../../../libs/vos/vutil/stringutil.hh:29: error: function `std::string > VUtil::numToString(const long int&)' definition is marked dllimport. > ../../../libs/vos/vutil/stringutil.hh:36: error: function `std::string > VUtil::numToString(const long unsigned int&)' definition is marked > dllimport. > ../../../libs/vos/vutil/stringutil.hh:48: error: function `std::string > VUtil::numToString(const double&)' definition is marked dllimport. > ../../../libs/vos/vutil/stringutil.hh:57: error: function `std::string > VUtil::numToString(const float&)' definition is marked dllimport. > ../../../libs/vos/vutil/stringutil.hh:66: error: function `std::string > VUtil::numToBigString(const double&)' definition is marked dllimport. > > > I guess it doesn't like having the function definitions in the header if > they're dllimport. > > -Ken > > ps: sorry no IRC. I was multitasking between the computer and other things > this afternoon... > > > ----- Original Message ----- > From: "Reed Hedges" <[EMAIL PROTECTED]> > To: "VOS Discussion" <vos-d@interreality.org> > Sent: Saturday, February 24, 2007 4:23 PM > Subject: Re: [vos-d] Compiling 0.24 with mingw on windows2000 > > > > Reed Hedges wrote: > > > Ken Taylor wrote: > > >> dateformatfilter.cc: In member function `void > DateFormatter::reformat()': > > >> dateformatfilter.cc:107: error: `localtime_r' undeclared (first use > this > > >> function) > > >> dateformatfilter.cc:107: error: (Each undeclared identifier is reported > only > > >> once for each function it appears in.) > > >> > > >> this looks like another function that mingw doesn't define (it's not in > the > > >> time.h that I have) > > > > > > Hmm, well we can put one in the windows version of VUtil if configure > > > doesn't find it on the system. It would just be a call to localtime() > > > with a mutex lock during, I think. > > > > OK, I added this to VUtil but someone on windows needs to test it. The > > configure script checks for localtime_r, and libvutil implements its own > > VUtil::localtime_r() function accordingly. > > > > Reed > > > > _______________________________________________ > > vos-d mailing list > > vos-d@interreality.org > > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > > > > > _______________________________________________ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d > _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
