Re: [avail for test] readline-4.2-1

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Charles S. Wilson" <cwilson@ece.gatech.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