Re: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps
| From: | Christoph M. Becker | Date: | Thu, 26 Jan 2017 09:42:32 +0000 |
| Subject: | Re: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps | ||
| References: | 1 2 3 4 | Groups: | php.internals.win |
| Request: | Send a blank email to internals-win+get-1163@lists.php.net to get a copy of this message | ||
On 25.01.2017 at 12:25, Anatol Belski wrote:
>> -----Original Message-----
>> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
>> Sent: Wednesday, January 25, 2017 12:11 AM
>> To: Anatol Belski <anatol.php@belski.net>; internals-win@lists.php.net
>> Subject: Re: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps
>>
>> Thanks! I wasn't aware of the PECL deps, but after a quick check, the available
>> libtiff seems to be fine to build libgd with TIFF support for Windows. (Also there
>> is fontconfig, what is more than I had hoped for. :))
>>
> Nice :) Thanks for checking!
Further tests worked out well, so libgd can now easily built with Visual
Studio 2015: <https://github.com/libgd/libgd/tree/master/windows>.
Thanks!
>> BTW, is there some publicly available repo for the sources of pecl/deps?
>>
> Some are in the winlibs repo, but most are not. The reason is the concern on the space limits
> for free repos provided by Github, as we already put some huge sources for the core in the winlibs
> org. The sources for PECL libs are taken from the respective public sources and in most case
> it's built as is or with a minimal change for lib names, etc. Usually also they're built
> just once for the given compiler, except asked by someone to upgrade.
Thanks for the info. :)
> Yeah, that's fine. I was doing libjpeg-turbo for the gnome libs, as it's now
> recommended for gnome in favor of classic libjpeg. The libs would collide in PHP otherwise, as we
> use the classic libjpeg in the core. Doesn't matter functionally, but otherwise what I've
> seen, is that libjpeg-turbo has a lot of ASM optimization. As it only implements a subset of the
> classic libjpeg, would probably have to be thoroughly checked, but otherwise it could outperform the
> classic one on x86 architectures.
Would be interesting to do some performance comparisons, but I'm afraid
I won't find time for that in the near future.
Cheers,
Christoph