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: <3B200DEF.7A64D0C5@ece.gatech.edu>
Date: Thu, 07 Jun 2001 19:27:43 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Jason Tishler <Jason DOT Tishler AT dothill DOT com>,
        Cygwin Users <cygwin AT cygwin DOT com>
Subject: Re: [avail for test] readline-4.2-1
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F043 AT itdomain002 DOT itdomain DOT net DOT au> <3B1E3D55 DOT AAF8E728 AT ece DOT gatech DOT edu> <00f001c0eeda$1da0e9e0$0200a8c0 AT lifelesswks> <3B1EC0A5 DOT 61046D2 AT ece DOT gatech DOT edu> <086701c0eee6$b61d34b0$0200a8c0 AT lifelesswks> <3B1FB693 DOT C9F505A2 AT ece DOT gatech DOT edu> <000701c0efa0$f09dc090$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Robert Collins wrote:
> > The ONLY reason I'm concerned about bash as an exception to that rule,
> > is because Chet maintains BOTH bash AND readline.  Because he cares, I
> > care.
> 
> I'm on the fence on this one. The breakage is caused not because they
> have the package in a subdir (they do provide --with-included-readline)
> but because their header is picked up by default and then linked against
> the system readline. Thats a build bug yes.
> 
> > <snip comparison of default behaviors>
> >
> <SNIP static vs dynamic first-in logic>
> 
> I see your point about libtool aligning with the system. Do remember
> that pw32 and mingw are also affected by our changes with respect to
> libtool.

True, and something to keep in mind.  But the ld behavior I described is
true for all pei386 builds -- thus, cygwin, mingw, and pw32 all look for
.dll.a in preference to .a.
 
> > > I don't think that is an issue:
> > > a) Present day: all the libtool created libraries are
> > > cyglibfoo-version.dll. And they don't provide an ordinal .def file,
> so
> > > all linked apps will be by name.
> > > b) The libraries you are shipping are linked to by name if you use
> the
> > > default headers, no? So again, that shouldn't be an issue.
> >
> > I *think* so.  There was a problem around libpng-1.0.9/1.0.11 where
> > missing functions changed the autoassigned ordinals...and stuff broke.
> > I created a .def file to maintain the <old> ordinal numbers -- but the
> > .def does not specify NONAME, so the names should be exported.
> 
> Hmm.
> 
> <snip quoting> >
> > > Basically, ordinals are a optimisation, and the dll _creator_
> controls
> > > whether linking to ordinals is allowed. No .def file, and/or no
> ordinals
> > > (they are optional) and it cannot happen.
> >
> > What happens when you strip a dll?  (All dlls are shipped stripped by
> > default).  nm -a on a stripped dll shows "no symbols" -- but
> objdump -p
> > indicates that the symbol export table is still there.  However,
> you're
> > actually linking with the import lib, which is (of course) not
> stripped,
> > and so contains all of the symbol names.
> 
> So there's no issue :}. The dll's export table is used by the win32
> runtime linker, and the import lib by ld.
> 
> > > 'Course, testing is probably needed, or a quick mail to the binutils
> > > list/search the binutils archives.
> >
> > testing.  The problem is, I really don't know how to look at a given
> > executable, say foo.exe, which depends on bar.dll and baz.dll, and
> say:
> >   Ah, yes, foo is linked by name to bar.dll, but its linked by ordinal
> > to baz.dll.
> > So, how can you test anything if you don't know how to 'evaluate' the
> > results?
> 
> make a dll foo, with 3 exports -
> alpha @5
> beta  @3
> gamma @1
> 
> make a client program and link to foo.
> 
> now rebuild the dll with
> alpha @2
> beta @4
> gamma @6
> 
> the client program, without relinking should still work. If it doesn't,
> it was linked by ordinal.

Ah, yes, the brute force method... :->

> 
> There is a much harder issue to solve I ran into last night, so I'm now
> putting time into evaluating Paul Solovosky's ld that auto-imports, and
> no longer needs any decoration. (The problem to solve is building static
> libs from the same source via libtool when the static|shared compile
> needs extra user defines. Urgh)

Also building static-linked versions of executables and
dynamically-linked versions of executables, where the exe source code is
part of the same package as the library.  E.g. my headache in gettext
(libintl) -- see the cygwin-apps/cygwin-announce archives.  I ended up
punting -- and only autobuilt static utility programs.  (I had to build
the dll-linked versions of msgfmt & friends by hand, just to make sure
my port of cygintl.dll worked.  But it was NOT automatic).

It is truly a royal pain.
 
> If that looks good, I'll see what I can do to get a libtool that
> supports its tested and running. (Hopefully with a little guidance :] )

Well, yeah -- *assuming* Paul has managed to work out all of the bugs; I
recall that DJ was quite skeptical, once upon a time, that such a thing
could be done at all, let alone done well.  Also, this is a *major*
architectural change for all three platforms -- any new dll's will not
be compatible, correct? (since they won't have __imp__symbol nor
__imp_datasymbol, but instead will have __symbol and __datasymbol.  Or
does Paul's patch automagically create __imp__* on-the-fly even without
the appropriate __declspec() directives?).

Thus, new dll's won't be drop-in replacements; dependant apps will have
to be relinked to use the new dll's.  A *big* project, and a change of
that magnitude requires community comment; you and I can't make that
switch unilaterally.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple