[Vm-dev] Bad naming of libfreetype in latest Pharo vm windows 64bits

[Guillermo Polito]

Thanks for taking a look into this Nicolas :)

I've taken a deeper look at this, it's not enough to use that spec since we
are not building the library ourselves byt downloading it from a file
server.
The freetype library in the pharo builds seems downloaded from the pharo
file server (i.e., https://files.pharo.org/vm/pharo-spur64/win/third-party/
for win 64) and changing the name of the library on the makefiles just
makes the library download fail, thus the build fails.
I'll see who around here can make a copy of the file with the correct name
and put it in the file server before issuing a PR with the fix.

I'll keep you posted,
Guille

On Mon, Jan 7, 2019 at 6:34 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Hi Guile,
>
> Le lun. 7 janv. 2019 à 17:16, Guillermo Polito <guillermopolito at gmail.com>
> a écrit :
>
>>
>> Hi all,
>>
>> I'm trying the latest windows pharo VM 64bits
>> (pharo-win-x86_64-201901051900-7a3c6b6.zip from
>> http://files.pharo.org/vm/pharo-spur64/win/) to see how reproducible are
>> the problems with freetype, athens and the bitblt. While in that I've found
>> that libcairo does not load due to a bad naming of libfreetype. I had
>> libfreetype.dll, and renaming it to libfreetype-6.dll made it loadable
>> again.
>>
>> The 32bit windows VM that corresponds to the same commit, the freetype
>> library file is also named libfreetype.dll but there it works.
>>
>> I've found that the specs for freetype for win64 in that commit are right:
>>
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/7a3c6b642312bc2778fd86fdb86fc104bbb9278e/third-party/freetype2.spec.win64
>>
>> but maybe the default ones are used?
>>
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/7a3c6b642312bc2778fd86fdb86fc104bbb9278e/third-party/freetype2.spec
>>
>> Indeed, it seems to be hardcoded here:
>
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win64x64/third-party/Makefile.freetype2
>
> For example, for libpng we explicitely load the windows specific versions
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win64x64/third-party/Makefile.libpng
>
> For freetype2, we would need to load both, since the spec.win64 is partial.
>
>
> Does somebody know what else could be causing this?
>>
>> Tx,
>> Guille
>>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*


*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190108/1bf07393/attachment.html>