early on you wrote
> it shouldn't be too complicated to build a DLL of ttfautohint that
statically links all dependencies, e.g. using dlltool.
could you please elaborate a bit?
Here is my attempt at building a shared library or DLL for
libttfautohint that has freetype and harfbuzz dependencies statically
linked and has no other requirements than system libraries:
I basically reworked a shell script originally written by Werner that
builds a self-contained statically linked ttfautohint executable, turned
it into a Makefile, and I applied Martin's patch that enables
libttfautohint.so shared library on top of ttfautohint master.
I have the three repositories of ttfautohint, freetype2 and harfbuzz
checked in as git submodules.
This seems to work well for Linux and Mac (i.e. ldd, or the mac
equivalent otool -L, does not list harfbuzz or freetype as dependencies,
which is what I want).
However on Windows under MINGW64 environment the final linking step
fails with an error and I get this warning from libtool
*** Warning: This system cannot link to static lib archive
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
Exactly the same message for the libfreetype.la <http://libfreetype.la>
Can anybody help?
Thank you in advance
On Fri, Dec 8, 2017 at 1:07 PM Cosimo Lupo <address@hidden
Thanks Martin! It works well :)
Werner, would it be possible to merge this patch upstream, so that I
can use it without having to apply this downstream?
I think it would be useful for others as well to be able to build a
shared library for ttfautohint.
On Fri, Dec 8, 2017 at 7:55 AM Martin Gieseking
<address@hidden <mailto:address@hidden>> wrote:
Am 08.12.2017 um 02:27 schrieb Cosimo Lupo:
> P.S. It’s Cosimo btw ;)
Oops, just noticed the typo. Sorry for that. It wasn't intentional.
Let me know if you have any issues with the the build modifications.
> Il 7 dic 2017, 22:18 +0000, Martin Gieseking
> ha scritto:
>> Hello Cosmimo,
>> I'm also interested in a shared library of ttfautohint and
>> with the build system. The attached patch modifies the
>> so that public static and shared libraries are built and
>> When using MSYS2/MinGW64 on Windows, I get a working DLL. It
>> contain harfbuzz and freetype, though. They must be linked
>> the target applications. However, it shouldn't be too
>> build a DLL of ttfautohint that statically links all
>> using dlltool.
>> Am 07.12.2017 um 16:51 schrieb Cosimo Lupo:
>>> Thanks Werner,
>>> I looked at the gnulib docs but honestly it looks a bit
>>> I think that, for the beginning, I will compile the Windows
>>> the mingw-w64 toolchain in an msys2 environment.
>>> I think that should work fine, even from the official
>>> cpython distribution, because I'm not planning to make a python
>>> extension module (i.e. shared object that calls into the
Python C API
>>> and requires to link with the python library, thus needs to
>>> with the same compiler as python itself), but just a shared
>>> independent from python that is dynamically loaded at
runtime via dlopen
>>> or LoadLibrary by ctypes or cffi.
>>> This way I can use the normal autotools build system on all
>>> operating systems.
>>> I just need to figure out how to create a shared
>>> the current setup normally only creates a static library
embedded in the
>>> ttfautohint executable.
>>> If you have any tips, please let me know, thank you!
>>> On Thu, Dec 7, 2017 at 2:05 PM Werner LEMBERG <address@hidden
>>> <mailto:address@hidden <mailto:address@hidden>>> wrote:
>>> Hello Cosmimo,
>>>> I would like to make a Python wrapper for ttfautohint,
[...] I want
>>>> to build a shared library (.so, .dll, .dylib) and call
>>>> Python using either ctypes or better CFFI. [...]
>>>> Now, freetype and harfbuzz both support cmake as an
>>>> ./configure && make stuff. That's great.
>>> Note, however, that FreeType's cmake stuff is contributed
>>> I dislike cmake I haven't enough experience to handle
>>> by myself.
>>>> From a cursory look at the ttfautohint source, I see that
>>>> on gnulib, which looks like it's closely tied with the
>>>> I couldn't find any cmake projects using gnulib on the net.
>>> This is probably correct. Maybe a cmake e-mail list or
forum can give
>>> you more advice.
>>>> For those of you who are more knowledgeable about this, how
>>>> difficult would it be to adapt the current autotools-based
>>>> system of ttfautohint to use cmake, for example?
>>> In file `bootstrap.conf' you can find the list of gnulib
>>> ttfautohint requires:
>>> git-version-gen (only necessary for the ttfautohint
>>> isatty (ditto)
>>> progname (ditto)
>>> Please consult the gnulib git repository for more
information on the
>>> used modules.
>>> The idea of gnulib is that it only provides replacement
code if the
>>> host's functionality is either missing, incomplete, or
>>> tests are implemented as M4, to be automatically integrated
>>> automake and/or autoconf.
>>> It's probably easiest if you find, say, BSD replacement
code for the
>>> above functionality; cmake then could simply compile and
link to it if
>>> it is missing.
>>> Cosimo Lupo
>>> Freetype-devel mailing list
>>> address@hidden <mailto:address@hidden>