(oops, looks like I forgot to "reply all", sorry)
Yay! I've got my statically linked ttfautohint.dll :D
Dependency Walker says it only depends on KERNEL32.DLL, MSVCRT.DLL and
USER32.DLL which are system libs present on all windows machines.
I'm very happy!!
This is the full command line I used (for simplicity I only use basename
paths)
dllwrap -v --def ttfautohint.def -o ttfautohint.dll libttfautohint.a
libsds.a libnumberset.a libgnu.a libharfbuzz.a libfreetype.a
The trick was to also include the sds, numberset and gnu static
libraries in between ttfautohint and harfbuzz and freetype.
Thank you very much Martin and Werner for the assistance.
Cheers
---------- Forwarded message ----------
From: *Cosimo Lupo* <address@hidden <mailto:address@hidden>>
Date: Sat, Dec 9, 2017 at 2:38 PM
Subject: Re: [ft-devel] buiding ttfautohint with cmake?
To: Martin Gieseking <address@hidden
<mailto:address@hidden>>
Thanks Martin.
I tried to run dllwrap command in a MINGW64 shell, just after having
compiled the three static library with my Makefile.
I did exactly as you wrote, giving it the --def file and passing the
full path to the built static libraries (.a), in the order you wrote,
(i.e. libttfautohint.a libharfbuzz.a libfreetype.a).
However, the ld linker failed with loads of "undefined references to to
'rpl_malloc'"...
If I google around, I see this issue seems to arise in the context of
cross-compilation (but I don't think I am in this situation).
I attached the full verbose log of dllwrap if you wish to have a quick look.
Yesterday I was about to give up and simply include a pre-built
ttfautohint executable in my python module and call it as a subprocess.
Now, I think I'm getting closer to making a DLL, thanks to your help :)
On Sat, Dec 9, 2017 at 1:22 PM Martin Gieseking <address@hidden
<mailto:address@hidden>> wrote:
Am 09.12.2017 um 13:34 schrieb Cosimo Lup> Is it dllwrap or dlltool?
I’ll try both :)
It's dllwrap that creates DLLs from static libs. ;-)
And yes, the documentation about these utilities and their usage isn't
very detailed, unfortunately.
Martin
>
> Il 9 dic 2017, 10:26 +0000, Martin Gieseking
<address@hidden <mailto: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
<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> <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> <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>
>>> <mailto: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>
<mailto: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>
<mailto: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>
>>>>>> <mailto: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>
<mailto:address@hidden <mailto:address@hidden>
>>>>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
<https://lists.nongnu.org/mailman/listinfo/freetype-devel>
>>>>>>
>>>>>
>>>
>>> --
>>> Cosimo Lupo
>>>
>>> --
>>> Cosimo Lupo
_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel