[Bf-committers] Libs on windows?

Bastien Montagne montagne29 at wanadoo.fr
Thu Jan 24 14:24:22 CET 2013

 From Boost::locale doc:

>       Dependencies
>   * ICU library 3.6 or above is strongly recommended
>   * If no ICU library is given, iconv support is required under POSIX
>     platforms.
We use boost without icu (far too much powerful for what we need), so we 
should need inconv under unix. For some reason, linking against it looks 
not mandatory under Linux? Should not be needed under windows anyway, 
but I can't test that myself…

On 24/01/2013 13:51, Chad Fraleigh wrote:
> On Thu, Jan 24, 2013 at 3:40 AM, Brecht Van Lommel
> <brechtvanlommel at pandora.be>  wrote:
>> On Thu, Jan 24, 2013 at 2:18 AM, Chad Fraleigh<chadf at triularity.org>  wrote:
>>> iconv doesn't seem to be used for windows [blender] builds. The only
>>> place I see it in the cmake config is for "if(APPLE)", and even then
>>> it is only a -liconv entry (so a system lib I assume). So is this
>>> something that isn't used anymore (and should be removed from
>>> trunk/lib/win*), a windows lib added but never included in the cmake
>>> config, or something that is needed by other lib (that I have yet to
>>> try compiling) and gets inlined into their dll?
>> It seems indeed this is not used anymore and was replaced by boost locale.
> In the case where it is included, it seems iconv is for boost_locale
> to use itself.
> The portion of CMakeLists.txt:
> 			list(APPEND BOOST_LIBRARIES boost_locale-mt)
> boost_locale needs it !
> 		endif()
> It is odd that boost_locale would need iconv for APPLE, but not other platforms.
>>> Is OSL currently working for windows? When I enabled WITH_CYCLES_OSL
>>> (in VS2008/32-bit) it crashes with some invalid pointer when I start
>>> blender.
>> It's working with the library in svn now, not sure why it crashes for
>> you. Make sure to match all the build options from build.bat for OSL
>> and OIIO.
> This is with just the standard svn windows libs. I first noticed it
> when I was attempting to test my lib builds (so I enabled a few of the
> WITH_* settings that are OFF by default) and it crashed. So I
> eventually put them all back to svn and did a fresh build (or at least
> I thought I did) and still had the problem. After some trial and error
> flipping WITH_* options it seemed to be the WITH_CYCLES_OSL one (via
> some llvm callback in the stack trace).
> The configure used was:
> cmake -G 'Visual Studio 9 2008' -DWITH_OPENCOLLADA:BOOL=ON
> -DCMAKE_BUILD_TYPE:STRING=Debug ../blender
> Just to be sure I'm running another fresh build using only the svn'd
> libs (at least this time I can go sleep while it runs, rather than
> wait around for it like the rest [talk about tedious testing]).
>>> Also, just wondering.. what determines if something goes in
>>> blender/extern/ vs lib/xxxxx/?
>> I think usually things go into extern if there is no maintained
>> library can be expected to become a linux package, or if it's a small
>> library. But there is no clear rule that is always applied.
> I did notice that openjpeg is used in the build but no
> lib/windows/openjpeg/ install. My first thought was "why doesn't
> windows use it".. then I realized it was auto built in the extern
> directory (I only ever saw libmv building there it since that one
> takes so long). But I have noticed that openimageio can use openjpeg,
> if available. So would including it in openimageio (and the things
> that use it, like OSL) be worth moving it to lib/ (or openimageio to
> extern/ [which also would pull in OSL], at the price of making it a
> very heavy build)? This was the idea I had with making a script to
> build all the libs, only just once up front (or when something
> changed) for each developer's specific "build environment". So it
> wouldn't not compile them _every_ time, like extern/, and not static
> (except "when someone updates svn for a given build environment")
> either, but half way between.
> -Chad
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list