cygwin-patches for kde 3.4.1
thiago at kde.org
Fri Jun 17 14:01:37 BST 2005
David Faure wrote:
>On Friday 17 June 2005 14:18, Thiago Macieira wrote:
>> The patch is correct. If you use libkdecore stuff in your program
>> (say, KURL), you should add explicitly -lkdecore to your link
>> libraries. (Whether it is -lkdecore or $(LIB_KDECORE) is irrelevant)
>Well if you use KIO, which obviously uses KURL too, you shouldn't have
> to mention kdecore explicitely. We have cleaned up Makefile.ams
> everywhere to only list the highest level dependency, no point in a
> 10-km-long lib list.
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. I suggested in the namespace
thread that we split the libraries into namespaces. An also interesting
idea is to split headers into separate subdirectories (like Qt4). This
will make it easier on the developer to understand what he needs to link
Another way out would be to add to our Binary Compatibility rules that
released libraries (public and private alike) may never drop
dependencies. I.e., if libkio links to libxml when KDE 4 is released,
then it will have to continue linking to libxml until KDE 5, even if
something faster, better and more efficient comes along.
>> libtool will add the dependency libraries if and only if the .la file
>> is present. IIUC, the Cygwin people aren't using them. And we're
>> talking about replacing libtool in the build-system thread, which
>> means .la would be gone.
>If we ever drop libtool, we can simply make $(LIB_KIO) include -lkio
> -lkdeui -lkdecore. Still no reason to bloat the Makefile.am.
That might be feasible for kdelibs, but might be really hard for other
modules and applications unless we create an equivalent .la file.
If we do that, we end up at the other end of the problem: every library
will be listed. I don't want every library to be linked against: I want
only those that my program uses.
The same rationale for libxml can be used: if I don't use libxml in my
KIO-using program, why should my program explicitly link to libxml? In
special, if KIO drops libxml (for whatever reason, directly or
indeirectly), my program should automatically stop loading libxml.
(The behaviour of the last paragraph is accomplished by ld's --as-needed)
>> That's not a problem with ELF because it is forgiving and will load
>> the libraries. But Win32's COFF PE file format (or, at least, Cygwin'
>> s implementation of it) is braindamaged and requires explicit listing
>> of ALL libraries, including kernel32, gdi32, commctrl, etc. that KDE
>> will never have it its Makefiles.
>That's still something the build system can do for you. The point is to
>make things easy for the developer, especially when it's as easy as
>patching acinclude.m4.in once and for all.
The linker should solve this here.
I remember the few months I used Cygwin (I was trying to compile with
wxWindows). It was impractical because every application I tried linking,
I had to run the (slow) compiler 10 times to work out the unresolved
symbols, plus nm & grep to find out which library had it.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel