why are std::streams/string disabled for OS X?

[Vadim Zeitlin]

Hello,

Does anybody know why do we have DEFAULT_STD_FLAG=no in "*-*-darwin*" case
in the beginning of configure.in? There doesn't seem to be any reason to
disable standard classes under OS X, at least compiling with them enabled
works fine and libstdc++.dylib seems to be part of the system so there are
no extra dependencies neither. So can I remove this line (once svn works
again)?

On a related note, I think we can remove "powerpc-apple-macos*" case from
the same switch now as we don't support Mac OS < X any more, any
objections?

Thanks,
VZ

[Stefan Csomor]

Hi

> Does anybody know why do we have DEFAULT_STD_FLAG=no in "*-*-darwin*" case
> in the beginning of configure.in? There doesn't seem to be any reason to
> disable standard classes under OS X, at least compiling with them enabled
> works fine and libstdc++.dylib seems to be part of the system so there are
> no extra dependencies neither. So can I remove this line (once svn works
> again)?

the only thing that I could think of is the possibility of compatibility
problems when building on a newer and letting it run under older systems, I
don't think this is done the same way as for frameworks when we are just
setting the minimal OSX version

> On a related note, I think we can remove "powerpc-apple-macos*" case from
> the same switch now as we don't support Mac OS < X any more, any
> objections?

not from me :-)

Thanks a lot,

Stefan

[Vadim Zeitlin]

On Tue, 9 Jun 2009 18:44:15 +0200 Stefan Csomor <cso...@advancedconcepts.ch> wrote:

SC> > Does anybody know why do we have DEFAULT_STD_FLAG=no in "*-*-darwin*" case
SC> > in the beginning of configure.in? There doesn't seem to be any reason to
SC> > disable standard classes under OS X, at least compiling with them enabled
SC> > works fine and libstdc++.dylib seems to be part of the system so there are
SC> > no extra dependencies neither. So can I remove this line (once svn works
SC> > again)?
SC>
SC> the only thing that I could think of is the possibility of compatibility
SC> problems when building on a newer and letting it run under older systems

otool -L reports the following for a binary compiled with wx version using
standard streams (using 10.4 SDK which is all I have):

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Do you know if either of these libraries versions requirements is a
problem? Or can I change the default to "yes"?

SC> > On a related note, I think we can remove "powerpc-apple-macos*" case from
SC> > the same switch now as we don't support Mac OS < X any more, any
SC> > objections?
SC>
SC> not from me :-)

Ok, I'll do this once svn is up.

Thanks,
VZ

[Vadim Zeitlin]

On Tue, 9 Jun 2009 18:44:15 +0200 Stefan Csomor <cso...@advancedconcepts.ch> wrote:

SC> the only thing that I could think of is the possibility of compatibility
SC> problems when building on a newer and letting it run under older systems, I
SC> don't think this is done the same way as for frameworks when we are just
SC> setting the minimal OSX version

I checked otool -L output for the minimal sample compiled with
wxUSE_STD_DEFAULT set to 0 and 1 and there is no difference so I enabled it
by default now. Please let me know if this creates any problems.

SC> > On a related note, I think we can remove "powerpc-apple-macos*" case from
SC> > the same switch now as we don't support Mac OS < X any more, any
SC> > objections?
SC>
SC> not from me :-)

Done too now, thanks,
VZ