Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-ID:	<001b01c0166d$d8f49d90$f7c723cb@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	<cygwin AT sources DOT redhat DOT com>
References:	<17B78BDF120BD411B70100500422FC6309E0C3 AT IIS000>
Subject:	Re: DLL naming conventions
Date:	Mon, 4 Sep 2000 23:44:18 +1100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE:	Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime:	04 Sep 2000 12:43:37.0109 (UTC) FILETIME=[BE958450:01C0166D]

...

> > However, no modeless users (except for Paul) have complained.  Perhaps
> > Paul should become modal. :-)
>
> The problem iw that when you say "modal" you are really saying that we
> should have several sandboxes and that a programm from sandbox "cygwin"
> could not play with (i.e. call) a program with sandbox "pw32" or
"mingw32";
> that was exactly what render the Win32 Posix subsystem so inattractive: it
> can't mix with win32.
>
> Here the situation would only be slightly better: it may work by chance
and
> suddenly fall apart in the wrong place (i.e. I added something to mingw32
> sandbox, and then a program from the cygwin sandbox no more works,
assuming
> I need to call some mingw32 program from cygwin bash...)
>
> I *know* that having cygpng.dll instead of libpng.dll is a bit of a burden
> for cygwin maintainers, but defining the convention and using it to all
new
> ports should prevent the problem to suddenly arise when there will be more
> conflict than the apparently isolated zlib problem.

but this also means that mingw32 program won't use the cygwin compiled
libpng if it is there? is that acceptable?
-> if we are looking to keep the sandbox's separate then yes.. but why care
about running a (say) mingw32 program from cygwin bash...
-> if we are looking to let things cross the sandbox we should decide _what_
things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
support and then make it as flexable as possible.

I think we need to make that decide first, and then the rest falls into
place....

if we want full cross over from the sandboxes then the answer should permit
only porting layer/method to use another libraries. So a port layer/method
specific library naming convention is not acceptable. likewise if we want
sandboxes then porting layer/method specific library file names becomes
mandatory.

Personally I think that a mingw32 libpng should be useable by cygwin gcc AND
cygwin distributed binaries, given that they are the same version... (and
that should be part of the naming convention).


Rob


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -