Bug 186567 - graphics/openshadinglanguage: Assertion failed: (sizeof(token_data<StringTypeT, PositionT>) == size), function operator delete,
Summary: graphics/openshadinglanguage: Assertion failed: (sizeof(token_data<StringType...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-08 21:10 UTC by O. Hartmann
Modified: 2015-02-07 08:40 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2014-02-08 21:10:00 UTC
port graphics/openshadinglanguage fails on 11-CURRENT with following error message:

[...]
===> No user-specified options configured for openshadinglanguage-1.4.0_1
root@thor: [openshadinglanguage] make
===>  Building for openshadinglanguage-1.4.0_1
[  7%] Built target oslquery
[ 18%] Built target oslcomp
[ 19%] Built target oslc
[ 20%] Generating emitter.oso
Assertion failed: (sizeof(token_data<StringTypeT, PositionT>) == size), function operator delete, file /usr/local/include/boost/wave/cpplexer/cpp_lex_token.hpp, line 166.
Abort trap (core dumped)
--- src/shaders/emitter.oso ---
*** [src/shaders/emitter.oso] Error code 134

make[3]: stopped in /usr/ports/graphics/openshadinglanguage/work/.build
1 error
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2014-02-08 21:10:07 UTC
Maintainer of graphics/openshadinglanguage,

Please note that PR ports/186567 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186567

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 2 Edwin Groothuis freebsd_committer freebsd_triage 2014-02-08 21:10:08 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 3 Shane 2014-02-12 06:06:58 UTC
I can't think of a way to re-create this.

As the error actually comes from boost/wave my guess is that boost-libs
needs to be re-linked after a change to HEAD or dependencies.

Another possibility is that openimageio linked into oslc may also need
to be linked against the new boost-libs.
Comment 4 O. Hartmann 2014-03-02 11:35:27 UTC
When I try to rebuild devel/boost-libs via "portmaster -f boost-libs" I receive on CURRENT
FreeBSD 11.0-CURRENT #0 r262684: Sun Mar  2 10:24:51 CET 2014 amd64 the following error
(on all CURRENT boxes except of a server):

[...]
In file included from ./boost/atomic/detail/platform.hpp:22:
./boost/atomic/detail/gcc-atomic.hpp:961:64: error: no matching constructor for
initialization of 'storage_type' (aka 'boost::atomics::detail::storage128_type') explicit
base_atomic(value_type const& v) BOOST_NOEXCEPT : v_(0)
[...]
./boost/atomic/detail/gcc-atomic.hpp:968:22: error: no viable conversion from 'int' to
'storage_type' (aka 'boost::atomics::detail::storage128_type') storage_type tmp = 0;
[...]


The curious thing is that the error happens on systems which have several
workstation-stuff installed, like KDE4 applications (i.e. kdevelop, LibreOffice, blender,
which requires graphics/openshadinglanguage). The server, which has CURRENT at the very
same revision, has not and on that box the build of boost-libs performs well.

Even removing blender, openshadinglanguage doesn't solve the problem with boost-libs
which you expect to be the source of the problem.
Comment 5 Shane 2014-03-03 02:46:52 UTC
Any chance that one of the "workstation apps" pulls in gcc as a
dependency giving a libc++ conflict?
Comment 6 John Marino freebsd_committer freebsd_triage 2014-07-22 18:51:40 UTC
Reassigning maintainer (lost in conversion to bugzilla)

ohartman: what's the status of this PR in your opinion?
Comment 7 Shane 2015-01-26 23:08:37 UTC
ohartman: Any chance this is resolved? It sounds more like an issue linking to boost and not really an OSL issue. Maybe needs to be passed to boost maintainer.

I have OSL compiled and installed on an 11-CURRENT machine without issue. I still haven't seen this show up on any other builds either.

FreeBSD hippie.local 11.0-CURRENT FreeBSD 11.0-CURRENT #24 r276775: Fri Jan  9 02:56:59 ACDT 2015     root@hippie.local:/usr/obj/usr/src/sys/GENERIC  amd64
Comment 8 O. Hartmann 2015-01-27 05:28:25 UTC
The issue is no more with most recent 11-CURRENT and 10.1-p4.

Regards,
oh