Compilation issue with qt

[Nicolas Pavillon]

Hello, 

Thank you for the patch information, it indeed seems to be exactly the same issue. However, it still seems a lot to patch qt for only one port, as also there may other unforeseen consequences, as also mentioned before. It other cases rise, then it would probably be worth. 

I was not aware that no-stl was a project option, thanks for the information. I will try to look if I can go around the problem by setting this project-wise. It would be a far simpler solution at this point. 

Cheers, 

Nicolas

On Jun 6, 2013, at 8:43 PM, Michael Dickens <michaelld at macports.org> wrote:

> The below looks correct from my reading of the Qt installed files. - MLD
> 
> On Jun 5, 2013, at 11:50 PM, Ian Wadham <iandw.au at gmail.com> wrote:
>> From what I can gather, QT_NO_STL is intended for platforms where the standard C++ library (STL/std) is not available.
> 
> Not quite, though it can mean that too.  Even if the STL is available on
> the host system, by setting "CONFIG -= stl; CONFIG += no_stl", at least
> in theory you can avoid using the STL at least from within Qt's code. 
> This macro is not defined for most of the primary qconfig settings
> ("CONFIG += large"), but it is defined for the minimal or small ones
> ("CONFIG += small").  So, from within your project you can choose to use
> QT_NO_STL or not.  I've never used this feature of Qt, so I have no idea
> if it works nor how well it works.
> 
> At least for MacPorts' Qt4 install, STL is enabled by default:
> ${prefix}/share/qt4/mkspecs/qconfig.pri (installed with +debug)
> {{{
> CONFIG += def_files_disabled exceptions no_mocdepend debug stl
> qt_framework
> }}}
> 
> Note that these are not "QT_CONFIG". "CONFIG" is used for each specific
> project, while "QT_CONFIG" is how QMake and Qt were built.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev