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
From: "Ralf Habacker" <Ralf DOT Habacker AT saght DOT tessag DOT com>
To: "Cygwin-Xfree" <cygwin-xfree AT sources DOT redhat DOT com>,
        "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>,
        "Cygwin" <cygwin AT sources DOT redhat DOT com>
Cc: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Subject: !!AW: ask for delivering cygwin 1.1.8 with kde 1.1.2
Date: Wed, 13 Jun 2001 13:47:39 +0200
Message-ID: <001601c0f3fe$a6139d80$6e032bb7@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <011801c0f3f8$7f2034f0$0200a8c0@lifelesswks>

> > >
> > 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.
You're right. I hope I can find it :/
>
> > > 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.
>
As I started using the ld with the auto-import patch I have figured out,
that I have to use --whole-archive ... objs ... --no-whole-archive
.....deps.... to import all objectfiles. Otherwise ld removes all unused
objectfiles.

With your patched binutils I have to add --export-all-symbols too,
otherwise only(!) the last listed objectfile was included in the import
library file. I think the dll have all symbols. Perhaps this may be a bug
??? (I will analyse this)

> <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.

Okay, this could be changed easily for the kde 1.1.2 libtool. For kde2 your
libtool support this already.

>
> 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?

I don't know. What i have seen in jpeglib6a is this.
---------------------------------------------------------
jpeglib.h:#define JPEG_LIB_VERSION  61  /* Version 6a */

jcapimin.c: GLOBAL(void) jpeg_CreateCompress (j_compress_ptr cinfo, int
version, size_t structsize)
{
...
jcapimin.c:  if (version != JPEG_LIB_VERSION)jcapimin.c:    ERREXIT2(cinfo,
JERR_BAD_LIB_VERSION, JPEG_LIB_VERSION, version);

#define jpeg_create_compress(cinfo) \
    jpeg_CreateCompress((cinfo), JPEG_LIB_VERSION, \
                        (size_t) sizeof(struct jpeg_compress_struct))
----------------------------------------------------------------------------
---
jpeglib6b has another version number

>
> > 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...
>
I know. Perhaps one can add a minimal pre/postinstall package script
functionality to setup.exe to enable some checking functionality owned to a
specific package.

I think about two optional scripts in the package archive, which will be
extracted
before installing and called by setup.exe with some mode options like
preinstal/postinstall/preuninstall/reinstall and so on.
This would be although good for additional postinstall actions like adding
accounts
or patch files. Or is this already implemented, I only don't know ?

Regards
Ralf