Mail Archives: cygwin-apps/2001/06/13/07:50:13
----- 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
- Raw text -