Date: Tue, 8 Oct 2013 16:03:29 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Shane Ambler <FreeBSD@ShaneWare.Biz> Cc: FreeBSD-ports <freebsd-ports@freebsd.org> Subject: Re: Need some help debugging c++ code for 10.0 Message-ID: <20131008160329.729e5518@kalimero.tijl.coosemans.org> In-Reply-To: <5252BA55.5070806@ShaneWare.Biz> References: <5252BA55.5070806@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/dx84WJBnzF_x9ZxJNci6yur Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 08 Oct 2013 00:12:45 +1030 Shane Ambler wrote: > Hi there, I am the port maintainer for opencolorio, openimageio and=20 > openshadinglanguage. These build and run on 9.2 with clang 3.3 but I=20 > have an issue on 10.0. I don't have much programming experience and even= =20 > less with c++ which all 3 use. >=20 > After ocio and oiio are installed building osl generates oslc (the osl=20 > script compiler) and then runs it to pre-compile the included scripts.=20 > This step fails on 10.0 >=20 > I am fairly sure that the issue is within the ustring class - full code=20 > can be viewed at github.com/OpenImageIO/oiio with src/include/ustring.h=20 > having some info about the class. >=20 > The following is from src/libutil/ustring.cpp for ustrings constructor >=20 > #if defined(__GNUC__) > // We don't want the internal 'string str' to redundantly store the > // chars, along with our own allocation. So we use our knowledge of > // the internal structure of gcc strings to make it point to our chars! > // Note that we've carefully structured the TableRep fields so they > // mimic a GCC basic_string::_Rep. > // > // It turns out that the first field of a gcc std::string is a > // pointer to the characters within the basic_string::_Rep. We > // merely redirect that pointer, though for std::string to function > // properly, the chars must be preceeded immediately in memory by > // the rest of basic_string::_Rep, consisting of length, capacity > // and refcount fields. And we have designed our TableRep to do > // just that! So now we redirect the std::string's pointer to our > // own characters and its mocked-up _Rep. > // > // See /usr/include/c++/VERSION/bits/basic_string.h for the details > // of gcc's std::string implementation. >=20 > *(const char **)&str =3D c_str(); > DASSERT (str.c_str() =3D=3D c_str()); > #else > // Not gcc -- just assign the internal string. This will result in > // double allocation for the chars. If you care about that, do > // something special for your platform, much like we did for gcc > // above. (Windows users, I'm talking to you.) > str =3D s; > #endif >=20 > When the osl build starts to precompile the bundled osl scripts oslc=20 > triggers the DASSERT (which is line 137) shown above. If I adjust the=20 > #if (and the matching destructor) so the non-gcc fallback is used, osl=20 > still fails just without the assert message. There's a third __GNUC__ case in that header. Unlike the first two it's ifNdef though so you need to change it into something like: #if !defined(__GNUC__) || defined(_LIBCPP_VERSION) --Sig_/dx84WJBnzF_x9ZxJNci6yur Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iF4EAREKAAYFAlJUELcACgkQfoCS2CCgtisOZAD/YYn/Ua3pl7e0eXAnUeAeUmKr NrygJdaCjDi3T09ny1MA/3WbtJoJSoSfXcNfbUp5CcPRWDORFXDF0vEsW7Z7QeWu =gMhY -----END PGP SIGNATURE----- --Sig_/dx84WJBnzF_x9ZxJNci6yur--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131008160329.729e5518>