[gs-devel] Re: Integrating libtiff into the Ghostscript source tree

Ralph Giles giles at ghostscript.com
Tue Sep 22 10:54:21 PDT 2009


On Tue, Sep 22, 2009 at 10:13 AM, Lars Uebernickel
<larsuebernickel at gmx.de> wrote:

> I am currently working on integrating libtiff into the ghostscript
> source tree (for http://bugs.ghostscript.com/show_bug.cgi?id=614298 ).
> Henry told me you are the one to ask about the build system and I have a
> few questions:
>
> I assume both static and dynamic (with an existing libtiff) linking
> should be provided, with static being the default and dynamic the
> fallback. Should there also be a configure switch to force dynamic
> linking (I haven't found one for libpng or jpeg)?

Yes, we'd like it to mirror the other third-party libraries. We want
to support a monolithic build so it's easy to get ghostscript going
without any dependency hell, but packagers for Linux and similar
systems will of course want to link to the already available and
separately updatable shared libraries on the system.

> I have added a call to libtiff's configure to Ghostscript's configure
> run (similar to the way it's done for libjasper). I was wondering if I
> can also call the existing Makefile from libtiff's source tree (as
> opposed to adding all source files to base/libtiff.mak, as is done in
> libpng.mak). This would be possible, as that Makefile allows building a
> static library. How would the resulting libtiff.a be added to the .dev
> file? The same way as object files?

The reason we have duplicate makefiles is so all this still works with
the nmake build on Windows. Sorry. There's a toolbin/gen_ldf_jb2.py
script you could generalize if you want a less tedious approach to
writing a base/libtiff.mak.

I'd like to come up with a better way of building and including
libraries (and then apply that to internal modules as well!) so I'm
happy to talk about ideas. That's a bigger project than just adding
another library though.

HTH,
 -r


More information about the gs-devel mailing list