search

PonyDeluxe / alembic

Automatically exported from code.google.com/p/alembic
Other
0 stars 0 forks source link

clang build problem, OSX 10.8.4 #315

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Just synced to head, building with Xcode 4.6.3. Has anyone seen this before? At 
first glance it looks like a forward declaration issue (ie, something has been 
forward declared, but a concrete type is needed for the template argument)

In file included from 
/Users/dp/Projects/alembic/build/OSX/alembic/../../../lib/Alembic/AbcCoreOgawa/A
rImpl.cpp:37:
In file included from ../../../lib/Alembic/AbcCoreOgawa/ArImpl.h:40:
In file included from ../../../lib/Alembic/AbcCoreOgawa/Foundation.h:40:
In file included from ../../../lib/Alembic/AbcCoreAbstract/All.h:40:
In file included from ../../../lib/Alembic/AbcCoreAbstract/ArchiveReader.h:40:
In file included from ../../../lib/Alembic/AbcCoreAbstract/Foundation.h:40:
In file included from ../../../lib/Alembic/Util/All.h:39:
In file included from ../../../lib/Alembic/Util/Foundation.h:43:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/unordered_map:318:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/__hash_table:16:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4014:35: error: no viable overloaded '='
                __e->__weak_this_ = *this;
                ~~~~~~~~~~~~~~~~~ ^ ~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4051:5: note: in instantiation of function template 
specialization 
'std::__1::shared_ptr<Alembic::AbcCoreAbstract::v6::ObjectReader>::__enable_weak
_this<Alembic::AbcCoreOgawa::v6::OrImpl>' requested here
    __enable_weak_this(__p);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4591:5: note: in instantiation of function template 
specialization 
'std::__1::shared_ptr<Alembic::AbcCoreAbstract::v6::ObjectReader>::shared_ptr<Al
embic::AbcCoreOgawa::v6::OrImpl, void>' requested here
    shared_ptr(__p).swap(*this);
    ^
/Users/dp/Projects/alembic/build/OSX/alembic/../../../lib/Alembic/AbcCoreOgawa/A
rImpl.cpp:162:13: note: in instantiation of function template specialization 
'std::__1::shared_ptr<Alembic::AbcCoreAbstract::v6::ObjectReader>::reset<Alembic
::AbcCoreOgawa::v6::OrImpl>' requested here
        ret.reset( new OrImpl( shared_from_this(), m_data, m_header ) );
            ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4943:15: note: candidate function not viable: no 
known conversion from 
'std::__1::shared_ptr<Alembic::AbcCoreAbstract::v6::ObjectReader>' to 'const 
std::__1::weak_ptr<Alembic::AbcCoreOgawa::v6::OrImpl>' for 1st argument
    weak_ptr& operator=(weak_ptr const& __r) _NOEXCEPT;
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4954:15: note: candidate function not viable: no 
known conversion from 
'std::__1::shared_ptr<Alembic::AbcCoreAbstract::v6::ObjectReader>' to 
'std::__1::weak_ptr<Alembic::AbcCoreOgawa::v6::OrImpl>' for 1st argument
    weak_ptr& operator=(weak_ptr&& __r) _NOEXCEPT;
              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4950:9: note: candidate template ignored: failed 
template argument deduction
        operator=(weak_ptr<_Yp> const& __r) _NOEXCEPT;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4961:9: note: candidate template ignored: failed 
template argument deduction
        operator=(weak_ptr<_Yp>&& __r) _NOEXCEPT;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u
sr/bin/../lib/c++/v1/memory:4968:13: note: candidate template ignored: disabled 
by 'enable_if' [with _Yp = Alembic::AbcCoreAbstract::v6::ObjectReader]
            is_convertible<_Yp*, element_type*>::value,
            ^
1 warning and 1 error generated.

Original issue reported on code.google.com by Nick.Por...@gmail.com on 14 Sep 2013 at 5:23

GoogleCodeExporter commented 8 years ago 
What gcc are you using?

Original comment by miller.lucas on 16 Sep 2013 at 5:51

GoogleCodeExporter commented 8 years ago 
Good point. I am building in Xcode, which defaults to clang.

]clang -v
Apple LLVM version 5.0 (clang-500.0.60) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

From your question I imagine that if I switch the compiler to gcc that I should 
be able to compile without issue. Survey says --- yes, it compiles and runs 
properly.

]gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.0.60) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

For what it is worth, Apple has deprecated support for gcc, although it will 
for sure be included with the system for a while still. The problem seems to be 
the using declaration on shared_ptr within the Alembic::Util::v6 name space, 
perhaps the using on the v6 namespace itself. That would seem to be a clang 
issue. I'll see if I can work up a test case that demonstrates that, and if I 
can, I'll file it with the clang people.

Original comment by Nick.Por...@gmail.com on 16 Sep 2013 at 6:42

GoogleCodeExporter commented 8 years ago 
Ok, please let me know if it's a clang issue.

Original comment by miller.lucas on 18 Sep 2013 at 12:45

GoogleCodeExporter commented 8 years ago 
Hi Miller,

Now that LLVM 5.0 is out, I retested. The issue is not resolved. A new issue is 
that Xcode now reports that gcc is an unsupported compiler.

I had a little time to pursue the issue, and although I have not yet managed to 
isolate a stand alone test case that demonstrates the issue for the clang 
developers, I did find a workaround. I do still think it is a clang issue but 
cannot prove it yet.

Here is a sample that fixes the problem for Ogawa's ArImpl. Similar patches fix 
AwImpl, CprData, where the problem also crops up in a small number of cases. 
What do you think the best way to proceed is? My recommendation is that I 
continue to try to isolate the flaw so it can forwarded to the clang 
developers, but in the mean time, we guard the few uncompilable lines of code, 
to save Xcode 5 developers in general from being dead in the water while the 
issue is addressed. When the compiler is fixed, the #ifdef can be redacted.

//-*****************************************************************************
//-*****************************************************************************
AbcA::ObjectReaderPtr ArImpl::getTop()
{
    AbcA::ObjectReaderPtr ret = m_top.lock();
    if ( ! ret )
    {
        // time to make a new one
#ifdef __llvm__
        AbcA::ObjectReader* foo = new OrImpl( shared_from_this(), m_data, m_header );
        ret.reset(foo);
#else
        ret.reset( new OrImpl( shared_from_this(), m_data, m_header ) );
#endif
        m_top = ret;
    }

    return ret;
}

Original comment by Nick.Por...@gmail.com on 24 Sep 2013 at 3:39

GoogleCodeExporter commented 8 years ago 
Sadly, I spoke too soon. Although the trick works here to satisfy the compiler, 
it does not work in all cases. Rather than continuing to try to come up with a 
workaround, I'll focus on the stand alone compiler bug demonstrator.

Original comment by Nick.Por...@gmail.com on 24 Sep 2013 at 4:51

GoogleCodeExporter commented 8 years ago 
Could you specify the cases it does NOT work for?

Original comment by miller.lucas on 24 Sep 2013 at 6:25

GoogleCodeExporter commented 8 years ago 
The solution above worked for me in all cases. While it's a clang issue, if 
anyone on needs a quick and dirty fix, here's a patch.

Original comment by matysiew...@gmail.com on 18 Oct 2013 at 12:07

Attachments:

GoogleCodeExporter commented 8 years ago 
Howdy!

Here are all the changes I had to make in order to get this compiling on OSX 
Mavericks with -stc=c++11.  It compiles, and I can run SImpleAbcViewer on my 
old HDF5 files, and it works.  However, a lot of the regression tests fail. 
I've attached the tests log.

Original comment by blackencino on 25 Oct 2013 at 11:59

Attachments:

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I should add that this patch (comment #8) includes the patch above from comment 
#7 (thank you!!!)

Original comment by blackencino on 26 Oct 2013 at 12:04

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I believe this should fix the issues originally mentioned:

http://code.google.com/r/millerlucas-dev/source/detail?r=a422798ab84938a81b43aae
1c3e39faee4db6409

Original comment by miller.lucas on 29 Oct 2013 at 4:49

GoogleCodeExporter commented 8 years ago 
Miller, your patch works. Here's one more bit that needs fixing.

 in alembic/examples/bin/AbcTree/AbcTree.cpp, int i = 0 should be renamed int iseg = 0, or similar.

        int iseg = 0;
        while ( std::getline( ss, segment, '/' ) ) {
            if ( !isFile ( fp.str() ) ) {
                if ( iseg != 0 )
                    fp << "/";
                fp << segment;
            } else {
                seglist.push_back( segment );
            }
            ++iseg;
        }

Original comment by Nick.Por...@gmail.com on 3 Nov 2013 at 6:00

GoogleCodeExporter commented 8 years ago 
I just finished reviewing my diffs. It looks like I made a mod to your patch.  
valid() didn't exist for me, so I did this -

 bool valid() const
        { return !!m_vals; }

instead in IGeomParam.h. I think that has the same meaning?

Original comment by Nick.Por...@gmail.com on 3 Nov 2013 at 6:15

GoogleCodeExporter commented 8 years ago 
What is the warning for the original?

bool valid() const { return m_vals; }

If the explicit bool conversion is having issues, this would be a little 
clearer:

bool valid() const { return m_vals.get() != NULL; }

Original comment by miller.lucas on 2 Dec 2013 at 10:00

GoogleCodeExporter commented 8 years ago 
I just tried Alembic 1.5.3 and after fixing the C++11 problem on Mavericks (OS 
X 10.9), the only fix I had to do was to apply this replacement, i.e
bool valid() const { return m_vals; } 
in IGeomParam.h needs to become 
bool valid() const { return m_vals != NULL; }
for a successful OS X build.

Original comment by marcel.r...@googlemail.com on 19 Dec 2013 at 11:55

GoogleCodeExporter commented 8 years ago 
I think all of the issues were successfully addressed in Alembic 1.5.4

Original comment by miller.lucas on 25 Jun 2014 at 9:50