'Beta' releases of the VC dependencies packages

[CrazyEddie]

STLport 4.5.3 is not a requirement of the CEGUI library.

The only reason I provide the dependencies package compiled that way (with 4.5.3) is because it is in sync with the instructions over at the Ogre site. You are free to use any STLport version you wish, but you'll have to compile your own dependencies.

I can't seriously be expected to provide a dependencies download package for every possible combination of compiler, STLport, etc...

[saetrum]

STLport 4.5.3 is not a requirement of the CEGUI library.

The only reason I provide the dependencies package compiled that way (with 4.5.3) is because it is in sync with the instructions over at the Ogre site. You are free to use any STLport version you wish, but you'll have to compile your own dependencies.

I can't seriously be expected to provide a dependencies download package for every possible combination of compiler, STLport, etc...

Are you sure? I could have sworn you'd mentioned somewhere that you promised to be our personal code monkey

The pre-built dependencies were/are a great help to many people (myself included) don't get frustrated if they don't meet everyone's needs.

Thanks!

[Toxic]

Sorry, no offense ment.

Its just 30 degree celsius and im trying to get this to work since 2 days.

[Toxic]

Anyone knows about the autolink mechanism of boost? I found this in the CEGUI code:
// setup auto-link for boost.signals (works only with _MSC_EXTENSIONS on and with MSCV or Borland compilers, so they say...)
// if this can't be used obviously you need to link with the appropriate version of the library manually.
#define BOOST_LIB_NAME boost_signals
#include "boost/config/auto_link.hpp"

I would love to manually link, but even if I comment this out obviously some lib gets linked twice (or a wrong lib gets linked).

Any ideas?

[CrazyEddie]

@saetrum:
Oi! Don't tell people that I'm glad the deps packages worked for you (and many others), I did it mainly as a courtesy since I know it can be a pain for some to get right.

@Toxic:
No offense taken really, but I do get frustrated sometimes I have built and tested everything on all supported platforms (that is Win32: VC6, VC7.0, VC7.1 all with various native/STLport combinations, plus the Linux build - even though _mental_ did all the work there, I still took the trouble to compile and test it myself). For every version, the dependencies were built seperately to test and make sure it all works as it should. Throughout all these test runs, I had no problems at all. Therefore, I know for a fact that it can work without any trouble

The boost autolink is only used in that one place (though I thought I'd used it twice, but apparently not ). The main reason I'm using the auto link is to make it easier (I know that sounds like a joke) if people are using a different version of boost - since they will not have to edit the project config and mess with lib names like whatever-mt-p-gd-1_31.lib or such like. I'll have a play about with this side of things and see if I can come up with any suggestions for you.

There is an include order issue that you may be experiencing; basically when you include CEGUI.h in your project, it has to be the first include, otherwise you may get problems. This is one issue that I've yet to nail down, but nail it down I will

Ideally I would like to remove boost from the public headers; that is, CEGUI would still require boost, but projects using CEGUI would not also have to have it available. Currently this is looking doubtful due to the way templates work. It is possible at some stage I may write my own replacement for boost:signals, but this would not be for quite a while yet.

I will say that the learning curve for the system seems to many to have a mountain at the beginning, but once you get over this initial stage, people are finding that it's plain sailing from then on (save for the odd bug and what have you, all reports and/or patches are happily received) – so please stick with it and don’t give up

I have not tested with CVS boost, only the last actual release (1.31), I have successfully compiled with STLport 4.5.3 and STLport 4.6.2, the system also compiles with no STLport (though VC6 requires a minor adjustment to CEGUI::String, and this option is not really supported).

Anyway, can you tell me where you're at currently with regards to what parts you have compiled, what parts you have not, and so on...

CE.

[Toxic]

Maybe Im doing something stupidly wrong building boost? What I do is:
>bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_VERSION=4.6" "-sSTLPORT_PATH=D:\cvs\STLport-4.6"

[CrazyEddie]

You definately want to add:

"-sBUILD=<stlport-iostream>on"

to that command line. Without that you should have been getting "unable to find library" errors. Since you don't seem to be getting those errors, then the linker is still picking up what it thinks are the "right" files from somewhere else.

If you're using the rest of the pre-built dependencies, then you absolutely must remove the ./dependencies/include/boost directory, and also remove the boost libs from ./dependencies/lib/ otherwise you're just going to get the version clashes that I mentioned earlier.

Edit:
I've checked the auto_link.hpp usage. This is automatically configured by boost itself, so my use of it is redundant, this is why removing those lines has no effect

Edit2:
I intend to remove my redundant usage of autolink, and probably disable autolink for when the includes are used in client code (i.e. not actualy building CEGUIBase). To disable autolink, define this macro: BOOST_ALL_NO_LIB

HTH

CE.

[Toxic]

I couldnt get it to work, so I now got me VC7.1.

So far everything worked (compiling boost from cvs and CEGUI from cvs) but the linking fails. CEGUI wants to link:

libboost_signals-vc71-mt-gd-1_31.lib

Now I wonder how the name of this lib is generated. Im using boost from cvs which produces:

libboost_signals-mt-gd-1_32.lib

If I simply (I know I shouldnt do that) rename the lib I end up with the same "already defined" error I got with VC6. I checked several times, that CEGUI uses the correct include files (those from cvs boost).

Sorry if I bother You with this, I try to find out the error myself, but maybe You got a better understanding of boost/its automatic naming/linking.

[CrazyEddie]

Now I wonder how the name of this lib is generated.

It is generated automagically via the boost headers. It definately seems like a versioning conflict. But rahter than go on and on about that, what I'll do is get CVS boost and see if I get any similar issues, because right now this is looking more and more like an issue with the cvs version of boost.

Sorry if I bother You with this, I try to find out the error myself, but maybe You got a better understanding of boost/its automatic naming/linking.

It's not you that bothers me More that most issues witht he system are caused by my use of boost. I think I'll devote a weekend sometime to ripping it out...

I'll report back when I have the results of testing with CVS boost.

CE.

[Toxic]

I finally could build CEGUI. *happy*

Im not sure why, but after I removed everything, then recompiled bjam, boost and CEGUI I only had a slight difference in Lib names:

libboost_signals-vc71-mt-gd-1_32.lib
vs.
libboost_signals-mt-gd-1_32.lib

which doesnt seem to make a difference after renaming.

And there was a slight problem with casting int to bool in a boost header - the settings for CEGUI treat this as an error.

"#pragma warning (disable : 4800)" in line 24 of named_slot_map.hpp

did help.

[CrazyEddie]

Cool I'm so glad you managed to get it to work.

One thing's for certain; boost is one funky piece of coding. It just seems to take over, do what it wants, and if something breaks, you're really in trouble

CE.

[Nihilus]

Not sure if this is the place to post this, but I tried building with the beta-1 dependancies package, stlport 4.6.2 and vc 6.0s5. Had lots of unresolved boost dependancies. So I compared the dependancies packages for this release with the previous one (which compiles ok) and noticed that the libboost_regex-vc6-mt-gdp-1_31.lib for the new dependancies pack is significantly smaller in size than the old pack. (6,545,364 vs 9,993,534). I reverted to the old dependancies and things compiled ok.

[CrazyEddie]

Thanks for the report. I'll probably remove that package until I can fix it then.

I must admit I didn't get a chance to test that new configuration properly before my system exploded, so I'll take the download down until I can recompile and test it again.

CE.

[CrazyEddie]

I've uploaded a fixed package for VC6 and STLport 4.6.2, as you've probably seen

Has anyone had a chance to test this yet? I did test it myself here, but things always seem to happen differently once the packages get out in the wild.

Thanks in advance for any feedback

CE.

[Nihilus]

I've uploaded a fixed package for VC6 and STLport 4.6.2, as you've probably seen


Has anyone had a chance to test this yet? I did test it myself here, but things always seem to happen differently once the packages get out in the wild.

Thanks in advance for any feedback

CE.

I'm working on getting Demo7 running with them. The main system compiled and the Demo compiled, but then Ogre wouldn't start up once I'd put the latest XML and imageset files in. With the original files, it had the expected result of an empty skybox.

I'm reverting to the old dependancies to see if they work then or if it's a problem with my environment.

By the way, the Windows Look .dsp has TaharezLook for it's include path instead of WindowsLook in the Release settings. I also had to bump the /Zm setting in the OgreRenderer up to 200.


Update:
I can run when I compile with the old dependancies. With the new dependancies, it hangs trying to create the Edit box, at line 221 of CEGUIEditbox.cpp

Here's the stack trace:

Code: Select all

NTDLL! 7c90eb94()
KERNEL32! 7c802451()
_STL::_STLP_mutex_spin<0>::_S_nsec_sleep(int 27) line 116
_STL::_STLP_mutex_spin<0>::_M_do_lock(volatile long * 0x0012a81c) line 157 + 9 bytes
_STL::_STLP_mutex_base::_M_acquire_lock() line 325 + 9 bytes
_STL::__stl_debug_engine<bool>::_Invalidate_all(_STL::__owned_list * 0x0012a814) line 342
_STL::__owned_list::_Invalidate_all() line 335 + 9 bytes
_STL::__owned_list::~__owned_list() line 307
_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >() + 46 bytes
boost::w32_regex_traits<char>::lookup_collatename(_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & {...}, const char * 0x00cb51a4, const char * 0x00cb51a8) line 578 + 41 bytes
boost::re_detail::w32_traits_base::do_init() line 322 + 23 bytes
boost::w32_regex_traits<char>::update() line 484
boost::w32_regex_traits<char>::sentry::sentry(const boost::w32_regex_traits<char> & {...}) line 586 + 12 bytes
boost::reg_expression<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> >::set_expression(boost::reg_expression<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> > * const 0x02ae0068, const char * 0x02aa2240, const char * 0x02aa2242, unsigned int 34055) line 1346 + 15 bytes
boost::reg_expression<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> >::set_expression(boost::reg_expression<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> > * const 0x02ae0068, const char * 0x02aa2240, unsigned int 34055) line 238 + 59 bytes
boost::reg_expression<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> >::assign(const char * 0x02aa2240, unsigned int 33031) line 89 + 20 bytes
boost::basic_regex<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> >::operator=(boost::basic_regex<char,boost::regex_traits<char>,boost::detail::allocator_adapter<char,boost::detail::simple_alloc> > * const 0x02ae0068, const char * 0x02aa2240) line 356
CEGUI::Editbox::setValidationString(const CEGUI::String & {...}) line 221 + 36 bytes
CEGUI::Editbox::Editbox(const CEGUI::String & {...}, const CEGUI::String & {...}) line 118 + 35 bytes
CEGUI::TLEditbox::TLEditbox(const CEGUI::String & {...}, const CEGUI::String & {...}) line 61 + 75 bytes
CEGUI::TLEditboxFactory::createWindow(const CEGUI::String & {...}) line 312 + 48 bytes
CEGUI::WindowManager::createWindow(const CEGUI::String & {...}, const CEGUI::String & {...}) line 78 + 16 bytes
CEGUIOgre_TestDriver1::createDemoWindows() line 208 + 88 bytes
CEGUIOgre_TestDriver1::createScene() line 112
ExampleApplication::setup() line 87 + 13 bytes
ExampleApplication::go() line 55 + 13 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141f17, HINSTANCE__ * 0x00000000) line 71
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 7c816d4f()


So boost regexp may still be odd?