Message-ID: <4AF0CAB8.5020508@tlinx.org>
Date: Tue, 03 Nov 2009 16:28:40 -0800
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 ThunderBrowse/3.2.6.5 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
References: <20091102164807 DOT GA2897 AT calimero DOT vinschen DOT de>
In-Reply-To: <20091102164807.GA2897@calimero.vinschen.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
> be more Windows-like, or to be more Linux-like by dropping the check for
> the .dll suffix so that dlopen() fails if the filename isn't specified
> fully.
---
> Does anybody know such a tool?  If so, is there a chance to fix this
> easily in that tool or do we have to keep up this behaviour?  Finally,
> is there another *good* reason to stick to the Windows-like behaviour
> here?
----

   I don't have any such tools, but what I'd "rather" see as an
"alternative", from 'source-level' compatibility point of view, is to

1) go ahead make dlopen('file') (no extension), fail as it does on linux.

BUT also, 

2) if application tries to open ('file.so'), then it would try to match:
'file.so', then 'file.dll' -- in that order, to provide optimal
compatibility. 

At least, that's what I _think_ would provide optimal compatibility.  
If I compile a linux source, and if the library calls are the same 
(by intent or by accident), then it would "do the right thing" -- so 
working linux app might be able to be ported to cygwin with no source 
file changes -- just a recompile...

Just trying to think of "logical defaults" that would enable increased 
source-level compatibility.

Certainly, requiring that existing sources that dlopen("foo.so"), to be be
special cased to read "dlopen("foo.dll") on windows doesn't seem desirable.

In regards to "2", Under 64-bit linux, there is a separate lib64 that is 
added between the name and ".so" extension, but I *doubt* the apps
explicitly specify the 'alternate' architecture unless they really 
MEAN only 'lib64'.  I'd *guess*, that a 64-bit app opening the QT3
jpeg library "qjpeg"
   ( (looking on a 64-bit linux mach): 
    linux-64bit: /usr/lib64/qt3/plugins/imageformates:  
	libqjpeg.lib64.so, libqmng.lib64.so
   ), would simply try to open the "jpeg" name, and that lower level
libs' would add "libq" + ".so" and . that some even lower binary compat
layer adds the .lib64 before the .so for 64-bit binaries.  Supporting
the 'name.so' format as possibly being ' name.dll' (after checking with
.so, would allow that level of source to work unchanged.

On winxp+cygwin1.5, I see those same libs under
/lib/qt3/plugins/imageformats:
	libqjpeg.dll  and   libqmng.dll

It would be a 'nicety' if ported linux apps didn't have to worry that
windows calls something a 'dll' vs. '.so'... 

At least that's what I'd do unless someone told me it was really dumb
because "XXYZ"  ... then I might change my mind...:-)

linda


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