[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] buiding ttfautohint with cmake?

From: Martin Gieseking
Subject: Re: [ft-devel] buiding ttfautohint with cmake?
Date: Sat, 9 Dec 2017 11:26:11 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

Hi Cosimo,

libtool doesn't seem to be able to link DLL dependencies statically. I haven't investigated this further, though. The easiest way to get a statically linked DLL is to use dllwrap:
- build all libraries statically, including libttfautohint
- create a ttfautohint.def file as attached
- call dllwrap, e.g. like so:

dllwrap --def ttfautohint.def -o ttfautohint.dll /path/to/libttfautohint.a /path/to/libharfbuzz.a /path/to/libfreetype.a

The /path/to/ directories must be adapted accordingly of course. The resulting DLL should only depend on system libraries.


Am 08.12.2017 um 22:44 schrieb Cosimo Lupo:
Hi Martin,

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 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 <> file.

Can anybody help?

Thank you in advance


On Fri, Dec 8, 2017 at 1:07 PM Cosimo Lupo <address@hidden <mailto:address@hidden>> wrote:

    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
        <address@hidden <mailto:address@hidden>>,
         > ha scritto:
         >> Hello Cosmimo,
         >> I'm also interested in a shared library of ttfautohint and
        played around
         >> with the build system. The attached patch modifies the
        autotool scripts
         >> 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
        separately to
         >> the target applications. However, it shouldn't be too
        complicated to
         >> build a DLL of ttfautohint that statically links all
        dependencies, e.g.
         >> using dlltool.
         >> Martin
         >> 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
        DLL with
         >>> 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
        be compiled
         >>> 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, as
         >>> 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!
         >>> Cosimo
         >>> 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
        that from
         >>>> Python using either ctypes or better CFFI.  [...]
         >>> OK.
         >>>> Now, freetype and harfbuzz both support cmake as an
        alternative to
         >>>> ./configure && make stuff. That's great.
         >>> Note, however, that FreeType's cmake stuff is contributed
        code.  Since
         >>> I dislike cmake I haven't enough experience to handle
        potential issues
         >>> by myself.
         >>>> From a cursory look at the ttfautohint source, I see that
        it depends
         >>>> 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
        modules that
         >>> ttfautohint requires:
         >>>   dirname
         >>>   fcntl-h
         >>>   getopt-gnu
         >>>   git-version-gen       (only necessary for the ttfautohint
         >>>   isatty                (ditto)
         >>>   memmem-simple
         >>>   progname              (ditto)
         >>>   stdarg
         >>>   stdbool
         >>>   stdint
         >>>   std-gnu11
         >>>   strerror_r-posix
         >>>   strndup
         >>>   strtok_r
         >>>   strtoull
         >>>   vasprintf
         >>> 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
        buggy.  These
         >>> 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.
         >>>     Werner
         >>> --
         >>> Cosimo Lupo
         >>> _______________________________________________
         >>> Freetype-devel mailing list
         >>> address@hidden <mailto:address@hidden>

-- Cosimo Lupo

Cosimo Lupo

Attachment: ttfautohint.def
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]