!!AW: ask for delivering cygwin 1.1.8 with kde 1.1.2

Ralf Habacker Ralf.Habacker@saght.tessag.com
Wed Jun 13 04:45:00 GMT 2001

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

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,

#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
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
or patch files. Or is this already implemented, I only don't know ?


More information about the Cygwin-apps mailing list