Wietse,
I'm only using clang and its libc++ library. If you are using
gcc/libstdc++, that may well explain the difference. But gcc/libstdc++
is the standard on linux, and ref_ptr compiles fine there.
Do you *have to* use gcc? Otherwise, it may be easier to go with
clang; which, I think, is the native toolchain on Mac OS. By the way, a
simple unzip, cmake, should select a clang build. Did you force gcc? One
thing that I noticed is that when I create new Xcode projects/targets,
xcode insists on overriding the default clang/libc++ by gcc/libstdc++ in
the new project or target, so I have to remove the override by hand. Did
you use cmake's xcode generator? This may explain why you had a gcc build.
On 13/06/16 12:50, Wietse Jacobs wrote:
Hello François,
On Mon, Jun 13, 2016 at 11:31 AM François Bérard
<[email protected] <mailto:[email protected]>> wrote:
I just built the same OSG (same git rev-parse HEAD).
OS X 10.11.5
CMake 3.5.2
Xcode 7.3 (i.e. the only apparent difference with your setup).
I get the same cmake warning about MACOSX_RPATH, which is expected, cf
bottom of the following post.
http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/89981
The build displays a few warnings, but no error. See attached build log
(the line ordering is a bit messed up due to the parallel build).
I think that the normal unix way to point to shared libraries that are
not in "system" locations is using "DYLD_LIBRARY_PATH", I was not aware
of the "DYLD_FALLBACK_LIBRARY_PATH" variable.
I mainly work on windows, so I had to look that up when I was trying to
solve the "image not loaded" error when running osgviewer. I came across
a post *somewhere* that for development purposes it's wiser to us
"DYLD_FALLBACK_LIBRARY_PATH" and not interfere with "DYLD_LIBRARY_PATH".
It's supposed to do what the name implies: "use this if all else
fails...". But I know it's a hack.
...so, I don't understand your "implicit instantiation" errors. Is this
related to the Xcode 7.3.1 update? Did you play with your c++ library
somehow?
:) I did not play with my c++ library!
Seriously, no. But searching around for this problem gave many results
that point to a transition from using gcc to clang in Xcode and the
difference between using libstdc++ and libc++ as the standard library
(for example: https://github.com/qpdf/qpdf/issues/19). Does that mean
anything to you? On the other hand, that transition was made a few
releases ago so I would expect you to get the same error if that were
the reason.
But anyway, since "ref_ptr" doesn't #include <string> it was apparently
relying on an implicit #include *somewhere else*, so it must be that
with my setup that no longer happens. Sadly I haven't got the time right
now to track it down further...
Wietse
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
