Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <011801c0f3f8$7f2034f0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Ralf Habacker" <Ralf DOT Habacker AT saght DOT tessag DOT com>,
        "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Cc: "Suhaib Siddiqi" <ssiddiqi AT inspirepharm DOT com>,
        "Alan Hourihane" <alanh AT fairlite DOT demon DOT co DOT uk>
References: <000901c0f3f4$413954e0$6e032bb7 AT BRAMSCHE>
Subject: Re: ask for delivering cygwin 1.1.8 with kde 1.1.2
Date: Wed, 13 Jun 2001 21:03:36 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 13 Jun 2001 10:53:22.0051 (UTC) FILETIME=[10314530:01C0F3F7]

----- Original Message -----
From: "Ralf Habacker" <Ralf DOT Habacker AT saght DOT tessag DOT com>
> > So, Ralf, as I understand it the question is, why do you need cygwin
> > 1.1.8, and an older ncurses?
> >
> 1. I have reported ealier in the cygwin list about unix socket
problems,
<snip>

> 2. applications or linbs linked with cygwin 1.3.2 like ncurses
reference a
> pointer "check_for_executable" used by the method
path_conv::exec_state().
> This isn't available under cygwin 1.1.8. So if one application or lib
is
> linked with cygwin 1.3.2 it will never runs under cygwin 1.1.8.
Especially
> in deep nested applications like kde this wilkl produced much support
> problems.
>
> It is not possible to put this var into the structure pointed by the
> impure_ptr (or somewhere else) to prevent such incompatibility ?

It's only incompatible if you are running a compiled-on-cygwin-1.3.2
binary on a cygwin-1.1.8 system. That's like running a glibc 2.2
compiled binary ona  glibc 2.1 system. There's no reason to expect that
to work. Personally I don't think that the cygwin list should have to
compile ncurses for 1.1.8, once 1.3.2 is released. Remember: backwards
compatability means running old binaries still works with newer
Cygwin's, not newer binaries work on old cygwin's. Still if the cause of
that symbols use can be hidden, I see no problem with you providing a
patch.

That issue will go away if you are able to solve your sockets issue
though - so I don't see it as a big issue.

> > Does using ld without the auto-image-base solve your issues with
cygwin
> > 1.3.2?
>
> You need to all -Wl,--export-all-symbols. Without that --whole-archive
> doesn't do anything.
> Additional I have recognized a problem in using static libs, but this
I have
> to analyse more.

What's the --whole-archive thing? --export-all-symbols will likely cause
symbol conflicts with every dll re-exporting every imported symbol.

<snip ncurses already covered>
>
> Dependency problems
> Some libs like jpeglib are named with the major revision number, but
without
> the minor /release or buildnumber for examples cygjpeg6b.dll or
> ncurses5.dll.
>
> Especially for the jepglib there is an additional runtime checking if
the
> caller has compiled in the same version lib (with build-number).
>
> So when I compile kde with cygjpeg6b-2 and some time later someone
updates
> his jpeglib to Release 6b-4, kde will not be able to run because of
this
> runtime checking.
>
> Because of this I decided for kde to use dlls with detailed name (for
> example kdecore-2-0-0.dll) so that multiple installed versions of one
> package/lib are possibly.

That unilateral decision will give you problems later on!. A number of
folk, including Charles Wilson spent a bunch of time ~6 months ago
sorting out .dll naming conventions for mingw & cygwin & hopefully for
other gnu on windows projects. IIRC the cyg[libname][majorversion].dll
naming format was chosen so that users would not need _every single_
compilation of a .dll on their system. Remember that windows doesn't
support links between .dll's so that multiple versions will have to
actually exist.

If libjpeg is breaking it's own ABI in a non-backward compatible fashion
without incrementing it's major version number, then I would be going
and talking to them with big sticks.
From what you are saying it sounds like a program llinked to libjpeg
6.1.0 won't run with libjpeg 6.1.1. That's pretty unusual for
libraries - can the version checking be made more sane? Or is that
because of the current beta state of libjpeg?

> The cygwin installer doesn't care about such dependencies, so
currently, it
> would be easier to supply depending libs with the kde (or other
toplevel
> packages) package with the resulting problem of equal named dlls with
> different versions.

I've sent a patch into cygwin-patches for dependency handling in
setup.exe, but I decided against trying to implement version based
dependencies. That's not trivial at the best of times...

> Regards
> Ralf