Il 9 dic 2017, 10:26 +0000, Martin Gieseking <address@hidden>, ha scritto:
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.
Martin
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:
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