Smalltalk › Squeak › Squeak VM

Bad naming of libfreetype in latest Pharo vm windows 64bits

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Guillermo Polito
Reply | Threaded
Open this post in threaded view
♦
♦
|

Bad naming of libfreetype in latest Pharo vm windows 64bits

Guillermo Polito
 
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:


but maybe the default ones are used?


Does somebody know what else could be causing this?

Tx,
Guille
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Bad naming of libfreetype in latest Pharo vm windows 64bits

Nicolas Cellier
 
Hi Guile,

Le lun. 7 janv. 2019 à 17:16, Guillermo Polito <[hidden email]> 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:


but maybe the default ones are used?


Indeed, it seems to be hardcoded here:


For example, for libpng we explicitely load the windows specific versions

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
Guillermo Polito
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: 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 <[hidden email]> wrote:
 
Hi Guile,

Le lun. 7 janv. 2019 à 17:16, Guillermo Polito <[hidden email]> 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:


but maybe the default ones are used?


Indeed, it seems to be hardcoded here:


For example, for libpng we explicitely load the windows specific versions

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


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13
Free forum by Nabble Edit this page