Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <4377A7D0.5010207@cwilson.fastmail.fm>
Date: Sun, 13 Nov 2005 15:53:36 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Xemacs broken after postgresql upgrade
References: <82mzka9d8k DOT fsf AT vzell-de DOT de DOT oracle DOT com> <dl83l1$f9f$1 AT sea DOT gmane DOT org> <4377A47B DOT C388430D AT dessent DOT net>
In-Reply-To: <4377A47B.C388430D@dessent.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Brian Dessent wrote:
> René Berber wrote:
> 
> 
>>A better fix is to link cygpq.dll to pq.dll:
>>
>># ln /usr/bin/cygpq.dll /usr/bin/pq.dll

^^^^ that's a hardlink command, Brian -- which devolves to a copy on FAT32.

> That's not a great habit to get into.  It will only work if the program
> uses Cygwin methods (e.g. dlopen()) to dynamically load the dll at
> runtime.  It will absolutely not work for a .exe that was linked to a
> .dll in the normal way, or for a program that uses LoadLibrary() at
> runtime, because the windows dynamic loader has no idea what a symlink
> is and you will get the "Can't locate DLL" popup.

It's a temporary workaround and won't always work, especially if the API 
has changed between two different versions of the DLL.  But, given the 
hardlink not softlink, if XEmacs still fails it won't be because the 
dynamic loader can't find the target.

However, in a larger sense, THIS ruckus is exactly why public utility 
DLLs should not be packaged with the executables, and instead packaged 
in their own 'libfooN' package.  So that when you upgrade the main 
application, you get a new DLL but don't loose the old one.

Now, it is a question as to whether the postgresql DLL is actually a 
public utility DLL, regardless of XEmacs' use of it.  IF the on-disk 
format of the database changed between pq-7 and pq-8, you really 
wouldn't want to a mixture of apps on your system, some using pq-7 and 
some using pq-8, to access your database.  The implication is that the 
pq DLL is NOT a public utility, and the "interface" to the pq database 
that XEmacs and other clients should use is the postgres APP, not the 
postgres DLL.  If that's the case, then (a) it's okay for Jason to 
package postgres the way he does, and even to include the (private) DLL 
in the same package with the all, and (b) XEmacs was too ambitious to 
attempt to use the sharedlib interface, and should have instead used the 
app.

But I don't know enough about pq (or XEmacs) to definitively answer 
these questions.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/