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: <013d01c0efad$02a48150$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: "Jason Tishler" <Jason DOT Tishler AT dothill DOT com>,
        "Cygwin Users" <cygwin AT cygwin DOT com>
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> <3B200DEF DOT 7A64D0C5 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] readline-4.2-1
Date: Fri, 8 Jun 2001 09:53:10 +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: 07 Jun 2001 23:44:08.0748 (UTC) FILETIME=[BEE4B6C0:01C0EFAB]

----- Original Message -----
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>

<snip older stuff?

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

Thats actually easy with newer Automakes. (implementing the style of
recipe you are used too, I think - not libtool style)
==Makefile.am==
bin_PROGRAMS = foo foo_static
foo_SOURCES = foo.c
foo_static_SOURCES = foo.c
foo_static_CFLAGS = -DFOO_STATIC

will cause automake to compile foo.c twice, once with -DFOO_STATIC, and
then link the two separate objects into the two separate programs. The
problem with doing this for libtool, is that with libtool you have one
automake target for both the static and shared archives, and libtool
builds both for you.


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

I was skeptical too :]. Without grokking the source, and I will be
looking into it this weekend, the outside appearance is that it
* searches for symbol foo in all the libraries it's found,
then searches for __imp_foo in the same libraries, if no match was
found.

So nothing should break with existing apps, and headers. Decorated
headers will still work.

Specifically, the .o file doesn't change, for both the .dll source and
the program source.
There are more symbols shown by nm than I would have expected:
__fu6__foo
__fu7__foo
__fu8__foo
__imp__foo
__imp__foo
__nm__foo
__nm_thnk__foo

for nm client.exe ->the extern variable foo found in the dll the exe is
linked against.
The .dll looks absolutely standard to me :].

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

If the new .dll's aren't drop-ins then I agree absolutely. I'm
investigating now to see whether this is "break so we can be happy" or
not. However Paul's pw32 like mingw runs with existing ms .dll's, so I
doubt he'll have coded something that breaks the ability to link to
existing .dlls :]

> --Chuck
>


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