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:
https://github.com/fonttools/ttfautohint-python/blob/master/Makefile
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
.../libharfbuzz.la <http://libharfbuzz.la>.
*** 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>
file.
Can anybody help?
Thank you in advance
Cosimo
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.
Thanks
Cosimo
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.
Martin
>
> 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
installed.
>> When using MSYS2/MinGW64 on Windows, I get a working DLL. It
doesn't
>> 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
complicated..
>>> 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
MSVC-compiled
>>> 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
library
>>> 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
three
>>> operating systems.
>>>
>>> I just need to figure out how to create a shared
libttfautohint.so, 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 <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
autotools...
>>>> 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
build
>>>> 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
binary)
>>> 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
into
>>> 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>
>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>>
>>
--
Cosimo Lupo
--
Cosimo Lupo