<div class="gmail_quote">On Tue, Nov 10, 2009 at 10:52 AM, Cristian Oneþ <span dir="ltr"><<a href="mailto:onet.cristian@gmail.com">onet.cristian@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/11/10 Michaël Lhomme <<a href="mailto:papylhomme@gmail.com">papylhomme@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Forward of a mail replied directly to Cristian instead of the list...<br>
><br>
><br>
> On Mon, Nov 9, 2009 at 11:36 PM, Cristian Oneþ <<a href="mailto:onet.cristian@gmail.com">onet.cristian@gmail.com</a>><br>
> wrote:<br>
>><br>
>> În data de Luni 09 Noiembrie 2009 23:35:17 Michaël Lhomme a scris:<br>
>> > On Mon, Nov 9, 2009 at 3:33 PM, Michaël Lhomme <<a href="mailto:papylhomme@gmail.com">papylhomme@gmail.com</a>><br>
>> > wrote:<br>
>> > > On Mon, Nov 9, 2009 at 2:18 PM, Alvaro Soliverez<br>
>> <<a href="mailto:asoliverez@gmail.com">asoliverez@gmail.com</a>>wrote:<br>
>> > >> On Mon, Nov 9, 2009 at 10:10 AM, Michaël Lhomme<br>
>> <<a href="mailto:papylhomme@gmail.com">papylhomme@gmail.com</a>>wrote:<br>
>> > >>> Hello all,<br>
>> > >>><br>
>> > >>> just to follow the original mail from Cristian about KMyMoney on<br>
>> > >>> Windows, I would like to say I'm currently "using" it with Mac OSX<br>
>> > >>> 10.6<br>
>> > >>> (only screens "Home", "Ledgers" and "Schedules").<br>
>> > >>><br>
>> > >>> Regarding the AqBanking plugin, the version currently provided by<br>
>> > >>> MacPorts seems to be too old (CMake complains about that). Is there<br>
>> > >>> anyone owning an OSX and using AqBanking with KMM (I never used it<br>
>> > >>> and<br>
>> > >>> I'm not sure my bank is compatible, so it would be difficult for me<br>
>> > >>> to<br>
>> > >>> test it)<br>
>> > >>><br>
>> > >>> Right now a patch is used to compile successfully :<br>
>> > >>> - OSX linker does'nt support --no-undefined<br>
>> > >>> - there is a linkage problem with QtSQL (already fixed for the<br>
>> > >>> Windows<br>
>> > >>> port ?)<br>
>> > >><br>
>> > >> Hello Michaël,<br>
>> > >> can you create a patch for this?<br>
>> > >><br>
>> > >> If these issues are platform-specific, it should be something like:<br>
>> > >><br>
>> > >> #if MAC_OSX_compiler<br>
>> > >><br>
>> > >> #endif<br>
>> > >><br>
>> > >> I don't know the specific name, but it must be easy to check in<br>
>> > >> similar<br>
>> > >> KDE apps on Mac.<br>
>> > >><br>
>> > >> What about the other views? Are you getting crashes or they are just<br>
>> > >> unable to compile?<br>
>> > >><br>
>> > >> Regards,<br>
>> > >> Alvaro<br>
>> > ><br>
>> > > The patch is already done, with tests for the platform, but I can't<br>
>> > > get<br>
>> > > it at the moment (it is at home on my laptop). I'll upgrade my working<br>
>> > > copy with latest svn changes and send the patch tonight.<br>
>> > ><br>
>> > > About the other views, they seems to work, but I don't really use/test<br>
>> > > them, so I can't state they are working correctly.<br>
>> > ><br>
>> > > --<br>
>> > > Michaël Lhomme<br>
>> ><br>
>> > Here is the patch to fix the problem with --no-undefined. The linkage<br>
>> > issue<br>
>> > with QtSql library was already fixed in latest SVN.<br>
>> ><br>
>> > I tested quickly the other basic views without problems. I didn't use<br>
>> > Budgets and Investments so there are not tested. Reports are working<br>
>> > well,<br>
>> > including charts (from preset reports and old customized reports).<br>
>> > However,<br>
>> > updating the type of chart for an existing report lead to a crash.<br>
>> ><br>
>> > Finally I also encoutered a strange behavior on the Forecast view.<br>
>> > Scrolling control the scrollbars for tables (as usual) but also the<br>
>> > differents tabs, so when at the bottom of the table, if I keep<br>
>> > scrolling,<br>
>> > the panel is updated with the previous tab (and the opposite if I<br>
>> > scroll<br>
>> > up). I guess it's a (weird) feature of Qt on OSX. I will try to<br>
>> > investigate this ASAP as it's quite"disturbing" [literal translation<br>
>> > from<br>
>> > french... ;)]<br>
>> ><br>
>> ><br>
>> > Regards<br>
>> ><br>
>> Wouldn't the test 'IF (APPLE)' be more general instead of testing for<br>
>> Darwin?<br>
>><br>
>> --<br>
>> Regards,<br>
>><br>
>> Cristian Oneþ<br>
><br>
> Indeed the test would be more generic using 'IF(APPLE)'. Extract from the<br>
> CMake wiki :<br>
><br>
> - APPLE<br>
> is TRUE on Apple systems. Note this does not imply the system is Mac OS X,<br>
> only that __APPLE__ is #defined in C/C++ header files. Obtain more specific<br>
> system information via CMAKE_SYSTEM_VERSION, i.e. IF(${CMAKE_SYSTEM_NAME}<br>
> MATCHES "Darwin"), then it's Mac OS X.<br>
><br>
> I must admit I have no idea if one solution is better than the other. Find<br>
> another way to detect linker's specificity maybe a good alternative<br>
> (something like CMAKE_COMPILER_IS_GNUCC but for the linker)<br>
</div></div>If only 'the Mac OS X linker' (I don't know which is that) does not<br>
recognize --no-undefined than the patch should be applied as you've<br>
submitted it. I've just asked for a more general test thinking that<br>
the linkers on all Apple platforms behave that way but if that's not<br>
the case than we'll apply the patch as submitted. But on a second<br>
thought maybe we should use --no-undefined only when using the GNU<br>
linker or find a way to do this trough cmake (let cmake handle the<br>
platform specific issue).<br>
</blockquote></div><br>For KDE, various linker flags are set in the file FindKDE4Internal.cmake. --no-undefined is used only for Linux, tested with "IF(CMAKE_SYSTEM_NAME MATCHES Linux)". For Mac systems, the test is "IF(APPLE)"<br>
<br>The safest way may be to follow the KDE behavior ?<br><br>Regards,<br clear="all"><br>-- <br>Michaël Lhomme<br>