[KDE/Mac] kdesrc-build

[Jeremy Whiting]

Thanks again for the ideas. I removed p5.12 packages and installed p5.16
packages and now kdesrc-build doesn't complain about anything. Attica wont
build and says this in the cmake output:

Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.
but that KF5Attica target doesn't have MACOSX_RPATH specified. Should I be
specifying one ? attica mostly builds here, but fails towards the end
because of

ld: symbol(s) not found for architecture x86_64 <-- mostly qt symbols from
what I can tell. I'm using qt 5.3 from qt-project download currently, but
Marko suggested I use self-built instead, I think that was mostly to patch
around the standardpaths issue. Is it better to use Qt from macports than
to use the qtcompany's installer? If so why?

thanks,
Jeremy


On Sat, Nov 29, 2014 at 3:47 AM, René J.V. <rjvbertin at gmail.com> wrote:

> On Saturday November 29 2014 14:28:05 Ian Wadham wrote:
>
> Hi,
>
> > In general, Shell environment variables are a threatened species in
> Apple OS X,
>
> Why would you say that, Ian? As long as OS X is Unix-based they won't go
> anywhere ... Of course that doesn't mean that OS X software will use them
> abundantly, but it is perfectly possible to set them in a way that every
> piece of software has access to them if needed. Either through a lowlevel
> shell rc file, or user-specific via ~/.MacOSX/environment.plist .
>
> BTW, I noticed that good old "Property List Editor" from the 3.2 Xcode
> still functions under 10.9 .
>
> > > dyld: lazy symbol binding failed: Symbol not found: _Perl_Gthr_key_ptr
> > >   Referenced from:
> /opt/local/lib/perl5/vendor_perl/5.12.5//darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
> > >   Expected in: dynamic lookup
>
> Jeremy, I think I asked but never saw a reply: is there a reason you're
> using an older perl version? If not, I'd really advice you upgrade to 5.16
> rather than debugging your issues now and then maybe have to do it all
> again once you really have to upgrade.
> NB: the system perl on 10.9 appears to be 5.16.2 .
>
> > Expat.bundle exists for me, in the vendor_perl area.  It is an
> unreadable file (for vi) but
>
> Same here:
>
> /System/Library/Perl/Extras/5.16/darwin-thread-multi-2level//auto/XML/Parser/Expat/Expat.bundle
> /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
> /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
>
> These are dynamically loadable modules, they'd probably be .so objects on
> Linux. Why Apple chose to use the .bundle extension to something that's not
> what they otherwise call bundles (i.e. a directory tree with a Contents
> subdir) is beyond me (and off topic) :)
>
> Curiously:
> # nm
> /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
> | fgrep Perl_Gthr_key_ptr
>                  U _Perl_Gthr_key_ptr
> # nm
> /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
> | fgrep Perl_Gthr_key_ptr
> Exit 1
>
> Anyway, _Perl_Gthr_key_ptr is referenced from Expat.bundle, and needs to
> be resolved from elsewhere ... as the error message indicates. As such,
> moving to 5.16 ought to make the issue go away ;)
>
> > If you have any further troubles with Perl, the Macports Users mailing
> list has much
> > more expertise on Perl than the virtual zero I possess… :-)  To
> subscribe, see:
>
> Second that!
>
> R.
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20141129/5d8f6085/attachment-0001.html>