On 07/23/2011 06:53 PM, Nicky Perian wrote: > https://bitbucket.org/lindenlab/viewer-development/changeset/a0b400b5ff0e/ > The comments in this changeset describe the windows build / link > issues for this CR.
Hmm ... interesting. Thanks for investigating this. Alone from the Boost API documentation, I wouldn't have been able to find the cause of the undefined symbols errors you're seeing, I guess. >From Nat's comment <https://bitbucket.org/lindenlab/viewer-development/changeset/a0b400b5ff0e/#chg_indra/llcommon/tests/llsdserialize_test.cpp_newline89>: > While there is a boost::filesystem::path::string() call [...], > invoking that [...] produces unresolved externals for > boost::filesystem::path conversion machinery even though we can > resolve other boost::filesystem symbols. Possibly those conversion > routines aren't being built for Linden's Boost package. Does that mean that LL's prebuilt windows binary for the Boost library doesn't conform to the API set by the headers it ships with? Both const std::string string() const <https://bitbucket.org/lindenlab/3p-boost/src/f1c8de42baf0/boost_1_45_0/boost/filesystem/v3/path.hpp#cl-282> and const std::string generic_string() const <https://bitbucket.org/lindenlab/3p-boost/src/f1c8de42baf0/boost_1_45_0/boost/filesystem/v3/path.hpp#cl-322> are declared in build-windows/packages/include/boost/filesystem/v3/path.hpp for windows. Is that somehow related to the compile flag mismatch mentioned in changeset 740d8b8e509f <https://bitbucket.org/lindenlab/viewer-development/changeset/740d8b8e509f>? If the lib binary indeed deviates from the API, shouldn't we try to fix the binary rather than hacking around these problems in the calling viewer code? Cheers, Boroondas
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
