cygwin-patches for kde 3.4.1

[Ralf Habacker]

Am Freitag, 17. Juni 2005 15:55 schrieb Thiago Macieira:
> David Faure wrote:
> >On Friday 17 June 2005 15:01, Thiago Macieira wrote:
> >> On the other hand, suppose you linked to KIO, but used something from
> >> a library libkio uses directly or indirectly (let's call it
> >> third-party libxml). If KIO ever stops using that library, for
> >> whatever reason, you program will fail to link. Not only that, it will
> >> also fail to run if you upgrade libkio, without touching the program.
> >>
> >> Hence the need to specify all dependencies.
> >
> >Sure, for third-party libs used by the app I totally agree.
> 
> I'm worried that the scenarios I described might apply to KDE libraries. 
> Example (hypothetical): KIO uses kdnssd today, for whatever internal 
> reason, but tomorrow we split kdnssd into two libraries. Applications 
> break because they used the part of kdnssd that KIO no longer links to.
> 
> >Yes I was only talking about kdelibs. We know that kio needs kdecore,
> >and we know that this isn't going to change tomorrow.
> 
> If that's for kdelibs only, then all non-kdelibs Makefile.am's must be 
> changed. I don't think I followed you correctly, though.
> 
> >> The linker should solve this here.
> >
> >It does on linux, but I thought the conclusion was that it can't do so
> > on cygwin?
> 
> Well, the problem is that Cygwin uses static wrapper libraries (.a) on 
> Cygwin to represent the DLLs. Static libraries don't carry dependency 
> information, hence the need to specify all dependencies on the 
> command-line. That's actually what libtool's .la were invented for.

unfortunally admin/acinclude.m4.in uses outside kdelibs -lxxx when refering to 
kde libs and not the related la file, so this will not work currently.

> But, no, GNU ld must be fixed on the COFF PE (Win32) arch so that it will 
> correctly find the dependencies. It should read the .dll themselves, not 
> a (possibly outdated) .a wrapper.
> 
cygwin's ld has support to load a dll directly, but I don't know if it handles 
this dependencies. 
Is loading this dependency the default behavior for ld on unix ? 

> That said, I don't care what happens to Win32.
> Ralf