Fwd: [PATCH] MacOSX fixes for admin/

Benjamin Reed ranger at befunk.com
Wed Mar 5 14:30:25 GMT 2003

Christopher Molnar wrote:
>> - change -pedantic-errors to -pedantic in the get* checks (see earlier
>>   thread "problem with -pedantic-errors in KDE_CHECK_FUNC_EXT")
> This is not OK (although I haven't read the thread).  Some warning are not
> detected as such, if the return value of the compiler is zero.  This can
> be fixed only with the compiler having a non-zero exit value, which means,
> it has to convert the warnings to errors.  If you had issues with some
> functions the test should be fixed somehow, instead of turning off the
> errors.

OK.  The change was really a workaround, the *real* problem is that the 
line numbers configure is injecting into the headers (with #line n) are 
too large and cpp on darwin barfs even though the test should actually 
pass.  It ends up causing problems later with conflicting definitions 
between kdefakes and apple headers.

>> - fix a non-macosx-related "kdelibstuff" misspelling in the SSL checks;
> Wrong.  This isn't misspelled.  suff stands for suffix in this case and is
> either "64" or "".  The test for when to set this suffix to "64" doesn't
> work on all systems.  I have repeatedly talked about the fix, but neither
> me not anybody else came around implementing it.

OK, I could have sworn I saw it changed to "stuff" somewhere else too, 
but I just looked through acinclude.m4.in and have concluded it must be 
the crack talking.  Feel free to ignore that.  =D

>> The other thing this does not include that is necessary to make KDE
>> apps (in general) build on MacOSX is that libtool needs updates.
>> Previously I'd been sitting on my admin patches because you guys
>> (understandably) need things to be submitted upstream to libtool CVS
>> before they're accepted into the KDE admin directory.
> Hrm.  I was supposed to update our libtool ...

Well assuming that the last of our patches make it back into libtool 
proper, libtool 1.5 (when it's ready) will work just fine on darwin.

Unfortunately, there's a big war a-brewing on the libtool list about 
pass_all being abused and it's not clear how that's going to turn out; 
pass_all was meant to allow linking libraries for which some symbols are 
defined in the binary loading it, but is instead being used to allow, on 
some platforms, linking shared libraries against .a files, which is not 
portable.  In the case of KDE, one of the biggies is libkdecore links 
(well, can link) against Xinerama (which is only available as a .a 
file).  On darwin this works if we change libtool to use pass_all for 
the deplibs stuff, since all objects are PIC anyways, but the libtool 
folks aren't allowing it.

I don't know what the outcome will be, but regardless, at least for 
darwin, it's certainly better than libtool 1.4's support, even if it 
requires a one-liner patch to libtool to fix.

On another note, I've just been brought into contact with Sam Magnuson, 
it looks like before we do anything else we should work on consolidating 
our patches.  I'm going to try merging his admin changes, at least, into 
mine and then send them back here (along with your 
suggestions/objections) if that's OK with everyone involved.

More information about the kde-core-devel mailing list