No subject


Wed Apr 28 21:25:55 PDT 2010 

> 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

--------------030804060309070406020806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 07/23/2011 06:53 PM, Nicky Perian wrote:
    <blockquote
cite="mid:20110723165308.2252.78631 at domU-12-31-38-00-90-68.compute-1.internal"
      type="cite">
      <div style="font-family: Verdana,Arial,Helvetica,Sans-Serif;"><a class="moz-txt-link-freetext" href="https://bitbucket.org/lindenlab/viewer-development/changeset/a0b400b5ff0e/">https://bitbucket.org/lindenlab/viewer-development/changeset/a0b400b5ff0e/</a>
        The comments in this changeset describe the windows build / link
        issues for this CR.<br>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    From <a
href="https://bitbucket.org/lindenlab/viewer-development/changeset/a0b400b5ff0e/#chg_indra/llcommon/tests/llsdserialize_test.cpp_newline89">Nat's
      comment</a>:<br>
    <blockquote type="cite">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.</blockquote>
    <br>
    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 <tt><a
href="https://bitbucket.org/lindenlab/3p-boost/src/f1c8de42baf0/boost_1_45_0/boost/filesystem/v3/path.hpp#cl-282">const
        std::string string() const</a></tt> and <a
href="https://bitbucket.org/lindenlab/3p-boost/src/f1c8de42baf0/boost_1_45_0/boost/filesystem/v3/path.hpp#cl-322"><tt>const
        std::string generic_string() const</tt></a> are declared in <tt>build-windows/</tt><tt>packages/include/boost/filesystem/v3/path.hpp</tt>
    for windows.<br>
    <br>
    Is that somehow related to the compile flag mismatch mentioned in <a
href="https://bitbucket.org/lindenlab/viewer-development/changeset/740d8b8e509f">changeset
      740d8b8e509f</a>?<br>
    <br>
    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?<br>
    <br>
    Cheers,<br>
    Boroondas<br>
  </body>
</html>

--------------030804060309070406020806--

More information about the opensource-dev mailing list