[Bf-cycles] Building OSL for Blender

Sergey Sharybin sergey.vfx at gmail.com
Mon Feb 2 08:25:28 CET 2015 

On the other hand, on OSX clang is default now for us i think, so OSX
should just work.

But there's some trickery happening for blender there. Mainly for the
deployment target, plus some fixes which are not ported to the upstream
yet. And think mismatch in deployment target might cause the issue you're
having.

You might check on
https://developer.blender.org/diffusion/BL/browse/trunk/lib/darwin-9.x.universal/osl/osx_osl_compile.patch
to see if your configuration matches ours.

On Mon, Feb 2, 2015 at 3:12 AM, Kevin Atkinson <kevin.atkinson at gmail.com>
wrote:

> Hi Sergey, many thanks for that.  I'll try building the upstream branch as
> you suggested, and the bisection process.  One quick thing -- I was trying
> to build by running cmake, and pointing it to all the pre-built mac
> libraries that I downloaded from blender.org.  Presumably this is what
> you do?  The problems I'm having seem to be related to static linking, and
> I notice most of the prebuilt libs are static libraries.
>
> On Sun, Feb 1, 2015 at 4:59 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
>> Linux build environment uses gcc-4.7 (which could make affect on the
>> linking issue you're having). I also just tested with clang-3.5 here and it
>> worked just fine. So afraid not much help can provide you, however:
>>
>> - Try building upstream version 1.5.11 and see if it works fine (1.5.11
>> is what the branch is based on, plus some commits on top of it). If it
>> works then you'll narrow possible build regressions form our side to 3
>> commits. It if fails. If it doesn't compile:
>> - Try building latest OSL upstream version
>>
>> If latest upstream compiles fine then you can start bisecting for the
>> commit which solves compilation for you. If it fails then we're unable to
>> help you and you need to contact OSL guys in their ML.
>>
>> On Sat, Jan 31, 2015 at 5:05 PM, Kevin Atkinson <kevin.atkinson at gmail.com
>> > wrote:
>>
>>> Hi Sergey,
>>>
>>> Thanks for the reply.
>>>
>>> >Is it OSL which has issues with compilation or it's blender which
>>> fails to link against OSL library you built?
>>>
>>> It's compilation of the patched version of OSL that is used in Blender.
>>> The libraries actually compile without errors, but anything that links
>>> against them (e.g., the test executables in OSL or Blender) will have
>>> missing symbols.  All the missing symbols are from the C++ standard
>>> library.  So it's lots of this:
>>>
>>> *Linking CXX executable accum_test*
>>>
>>> *Undefined symbols for architecture x86_64:*
>>>
>>> *  "std::string::find_first_of(char const*, unsigned long, unsigned
>>> long) const", referenced from:*
>>>
>>> *      OpenImageIO::v1_4::Strutil::get_rest_arguments(std::string
>>> const&, std::string&, std::map<std::string, std::string,
>>> std::less<std::string>, std::allocator<std::pair<std::string const,
>>> std::string> > >&) in libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *  "std::string::find(char, unsigned long) const", referenced from:*
>>>
>>> *      bool boost::char_separator<char, std::char_traits<char>
>>> >::operator()<__gnu_cxx::__normal_iterator<char const*, std::string>,
>>> std::string>(__gnu_cxx::__normal_iterator<char const*, std::string>&,
>>> __gnu_cxx::__normal_iterator<char const*, std::string>, std::string&) in
>>> libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *  "std::basic_stringbuf<char, std::char_traits<char>,
>>> std::allocator<char> >::str() const", referenced from:*
>>>
>>> *      OpenImageIO::v1_4::ustring::getstats(bool) in
>>> libOpenImageIO.a(ustring.cpp.o)*
>>>
>>> *
>>> OpenImageIO::v1_4::Strutil::wordwrap(OpenImageIO::v1_4::string_view, int,
>>> int) in libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *      std::string OpenImageIO::v1_4::Strutil::format<long long>(char
>>> const*, long long const&) in libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *      std::string OpenImageIO::v1_4::Strutil::format<int, double, char
>>> const*>(char const*, int const&, double const&, char const* const&) in
>>> libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *      std::string OpenImageIO::v1_4::Strutil::format<int, int>(char
>>> const*, int const&, int const&) in libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *      std::string OpenImageIO::v1_4::Strutil::format<int>(char const*,
>>> int const&) in libOpenImageIO.a(strutil.cpp.o)*
>>>
>>> *      std::string OpenImageIO::v1_4::Strutil::format<int, int,
>>> double>(char const*, int const&, int const&, double const&) in
>>> libOpenImageIO.a(strutil.cpp.o)*
>>>
>>>       ...
>>>
>>> All the libraries that I link OSL to are the prebuilt ones for mac in
>>> darwin-9.x.universal.  I'm using clang 6.0 on Mavericks.
>>>
>>>
>>>
>>> On Sat, Jan 31, 2015 at 5:23 AM, Sergey Sharybin <sergey.vfx at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> That's a bit vague information. Is it OSL which has issues with
>>>> compilation or it's blender which fails to link against OSL library you
>>>> built?
>>>>
>>>> In any case, having an exact error messages would help.
>>>>
>>>> On Sat, Jan 31, 2015 at 7:41 AM, Kevin Atkinson <
>>>> kevin.atkinson at gmail.com> wrote:
>>>>
>>>>> I'm using OSL gabor noise for displacements in Blender, and I've been
>>>>> noticing nasty circle artifacts, coming from the rather coarse thresholding
>>>>> of the gaussian kernel.  I've been doing experiments with the gabor noise
>>>>> code outside of blender, and got very good results by simply changing the
>>>>> line
>>>>>
>>>>> static const float Gabor_Truncate = 0.02f;
>>>>>
>>>>>
>>>>> to
>>>>>
>>>>>
>>>>> static const float Gabor_Truncate = 0.0002f;
>>>>>
>>>>>
>>>>> This causes the search radius for impulses to be about half again as large, at some performance cost.  But not bad for reducing the artifact magnitude by a factor of a hundred.
>>>>>
>>>>>
>>>>> I'd like to get this working in Blender just for my own use and further testing, but I'm having trouble building OSL for blender.  I've checked out the "blender-fixes" branch, but I get linking errors because for some reason it doesn't link to the C++ standard library.
>>>>>
>>>>>
>>>>> I don't know much about CMake, and I am under the gun a bit, so I'm trying to to get in touch with whoever built the mac OSL library for blender to see if they have any suggestions.  Would that be Lukas Tönne?
>>>>>
>>>>>
>>>>> Many thanks, and any help much appreciated,
>>>>>
>>>>>
>>>>> Kevin Atkinson
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-cycles mailing list
>>>>> Bf-cycles at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> With best regards, Sergey Sharybin
>>>>
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>>
>>
>>
>> --
>> With best regards, Sergey Sharybin
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>


-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20150202/0d4f96bc/attachment.htm

More information about the Bf-cycles mailing list