closures vs -Wl,--no-undefined

[Stephan Kulow]

Am Monday 10 February 2003 18:16 schrieb Lubos Lunak:
> 
>  Hello,
> 
>  in case you haven't noticed yet, many KDE libs are linked twice. To be 
> precise, all those having -no-undefined (or $(KDE_PLUGIN) ) in their LDFLAGS. 
> Which makes the not so pleasant linking times even less pleasant.
> 
>  This is caused by the closures used in build process. They were introduced in 
> order to help with templates (the -frepo days), but these days, as far as I 
> can say, they're used only for -no-undefined (since adding -frepo to CXXFLAGS 
> is commented out - maybe another compiler still needs it). But GNU ld has 
> option --no-undefined, which can check for undefined references too, and 
> which libtool's -no-undefined option doesn't use (what a surprise :/ ).
> 
>  I tried to recompile kdelibs with the attached patches from admin/, and it 
> built quite fine, detecting undefined symbols, with two exceptions, in 
> arts/kde, and one subdir in kabc/. This is because -Wl,--no-undefined (i.e. 
> the GNU ld one) needs all dependent libs to be listed in the link command, 
> and those two apparently don't have it, and link only because all needed libs 
> are pulled in as dependencies of libs used in the link command. But I don't 
> consider this a bit problem, as libtool lists all dependent libs in the link 
> command anyway.
> 
>  Can anyone comment on the closures, or the attached patches? Maybe it would 
> be simpler to make our libtool use -Wl,--no-undefined (for 
> $no_undefined_flag) instead of the replacing done by am_edit, but I'm too 
> scared to touch libtool.
> 
-frepo is commented out as it never really worked for gcc. But e.g. Sun CC creates
smaller code if it knows what template instances a shared library needs and it can't know
unless it knows what templates the needed libs deliver. But as I'm not sure if that
ever worked (I remember tons of problems with the STL usage of arts), I'm actually
fine with the proposed patch. 

Greetings, Stephan