Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-q.one.com (mx-q.one.com [91.198.169.248])
	by mail6.b-one.net (Postfix) with ESMTP id 6B8D180150C9C
	for <filtered@awaresystems.be>; Tue, 31 Jul 2012 02:11:28 +0200 (CEST)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-q: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.212.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
	by mx-q.one.com (Postfix) with ESMTP id 14EC92FC17C
	for <filtered@awaresystems.be>; Tue, 31 Jul 2012 00:11:27 +0000 (UTC)
Received: by vbjk17 with SMTP id k17so6675917vbj.21
        for <filtered@awaresystems.be>; Mon, 30 Jul 2012 17:11:27 -0700 (PDT)
Received: by 10.52.94.36 with SMTP id cz4mr11357285vdb.10.1343693486999;
        Mon, 30 Jul 2012 17:11:26 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.58.208.231 with SMTP id mh7csp61731vec;
        Mon, 30 Jul 2012 17:11:26 -0700 (PDT)
Received: by 10.220.240.5 with SMTP id ky5mr12559261vcb.57.1343693485761;
        Mon, 30 Jul 2012 17:11:25 -0700 (PDT)
Received-SPF: neutral (google.com: 91.198.169.57 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.57;
Received: by 10.220.204.74 with POP3 id fl10mf5882225vcb.19;
        Mon, 30 Jul 2012 17:11:25 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.one.com (mx-j.one.com [91.198.169.57])
	by mail6.b-one.net (Postfix) with ESMTP id 58E9080150C9C
	for <info@awaresystems.be>; Tue, 31 Jul 2012 02:04:48 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-j.one.com (Postfix) with ESMTP id F3F4A4F5DE8
	for <info@awaresystems.be>; Tue, 31 Jul 2012 00:04:47 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id E0C1B3AD9DC;
	Mon, 30 Jul 2012 19:02:54 -0500 (EST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by lists.maptools.org (Postfix) with ESMTP id 8BA273AD9A9
	for <tiff@lists.maptools.org>; Mon, 30 Jul 2012 18:45:24 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6UNjNOc009039;
	Mon, 30 Jul 2012 19:45:23 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jay Berkenbilt <ejb@ql.org>
In-reply-to: <501680BE.9060608@ql.org>
References: <26455.1343591491@sss.pgh.pa.us> <501680BE.9060608@ql.org>
Comments: In-reply-to Jay Berkenbilt <ejb@ql.org>
	message dated "Mon, 30 Jul 2012 08:40:30 -0400"
Date: Mon, 30 Jul 2012 19:45:23 -0400
Message-ID: <9037.1343691923@sss.pgh.pa.us>
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] What about hiding not-officially-exported functions?
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Jay Berkenbilt <ejb@ql.org> writes:
> On 07/29/2012 03:51 PM, Tom Lane wrote:
>> Is it intentional that we're still letting clients call things like,
>> say, _TIFFsetDoubleArray()?  If not, at what point could we consider
>> changing it?  It's probably too late for 4.0, at least on distros
>> that have already shipped that.  I still have a bit of a window to
>> apply a filter for Red Hat's distribution of 4.0, though.

> Debian hasn't fully transitioned either, though tiff 4 is available.  If
> previously exported symbols disappear from the interface, that requires
> an soname bump, so we would have to go to libtiff.so.6.  The transition
> in debian to make tiff 4 the default won't occur until after Wheezy is
> released.

I experimented with applying a symbol filter in libtiff.map, using the
current contents of libtiff.def as the list of allowed symbols.

The first thing I found out was that the tools/ build fails unless
_TIFFCheckMalloc is added to the list.  Not sure if we wish to do that,
or adjust the tools files that have grown dependencies on it.

The second thing I found out was that the regression tests fail unless
TIFFCreateEXIFDirectory, TIFFCreateCustomDirectory,
TIFFWriteCustomDirectory, and _TIFFRewriteField are added to the list.
The first three of these of these I guess are supposed to be exported,
which means we've been sloppy about maintaining libtiff.def, and
somebody ought to go through tiffio.h line-by-line to make sure all
public symbols are really listed (I haven't done this).  I'm not sure if
it's a good idea for the regression tests to depend on _TIFFRewriteField
or not --- thoughts?

After making those additions, I had a working build of libtiff, and I
tried rebuilding all 109 packages that depend on it in current Fedora.
The good news is they all rebuilt.  The bad news is that that includes
freeimage, which has a call on _TIFFDataSize.  After some investigation
I found out that that was because the call occurs in code that is built
into a shared library, and the default switches for the GNU linker are
such that it doesn't complain about unresolved symbols at link time if
the references are going to be in a shared library :-(.  So that makes
the other 108 successes somewhat questionable; there might well be calls
in there that would only fail at runtime.  I don't have the time to try
to figure out how to inject -Wl,-z,defs into all those builds to catch
such problems.  The best I can say is that the open-source world seems
to *mostly* not have tried to call any non-exported functions.

Given this, I'm not going to risk sneaking a symbol filter into Red
Hat's 4.0 release.  I think we should consider adding one at the next
major library release, though.

			regards, tom lane
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
