From owner-freebsd-ports@FreeBSD.ORG Tue Oct 8 14:03:41 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D967DD9F for ; Tue, 8 Oct 2013 14:03:41 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by mx1.freebsd.org (Postfix) with ESMTP id 712EF25B1 for ; Tue, 8 Oct 2013 14:03:41 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGALEPVFJR8YG//2dsb2JhbABZgwc4wXWBHBd0giUBAQVWIxALDgoJJQ8qEAENBogduk+PQgeEIwOQKIdYgTCQUYMmOg Received: from 191.129-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.129.191]) by relay.skynet.be with ESMTP; 08 Oct 2013 16:03:37 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r98E3aqJ035997; Tue, 8 Oct 2013 16:03:36 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Tue, 8 Oct 2013 16:03:29 +0200 From: Tijl Coosemans To: Shane Ambler 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/dx84WJBnzF_x9ZxJNci6yur"; protocol="application/pgp-signature" Cc: FreeBSD-ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:03:42 -0000 --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--