On Tuesday 21 February 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday 21 February 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
It would be nice if we could get rid of this code, and use what is in
GenerateExportHeader.cmake instead.
I'm a bit confused about
Alexander Neundorf wrote:
On Tuesday 21 February 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
It would be nice if we could get rid of this code, and use what is in
GenerateExportHeader.cmake instead.
I'm a bit confused about why we can't use GenerateExportHeader as it is.
In
Stephen Kelly wrote:
This flag is not coming from CMake, but from KDE.
That sentence is not what I meant. What I meant is:
These flags are not coming from KDE, but from CMake.
Thanks,
Steve.
___
Kde-buildsystem mailing list
On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote:
Stephen Kelly steve...@gmail.com writes:
For KDE Frameworks 5, gcc 4.2 is too old. Qt5 requires a much more recent
version (I don't recall which exactly).
Unfortunately I'm a bit behind in the Qt5 discussions and
Thiago Macieira thi...@kde.org writes:
On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote:
AFAIU, Apple still ships gcc 4.2.1 (the last GPLv2 version of gcc) with
its OS; does it mean another compiler is going to be required for OS X
users too?
Qt supports gcc 4.2.1
On Monday 20 February 2012, Raphael Kubo da Costa wrote:
Thiago Macieira thi...@kde.org writes:
On domingo, 19 de fevereiro de 2012 23.50.49, Raphael Kubo da Costa wrote:
AFAIU, Apple still ships gcc 4.2.1 (the last GPLv2 version of gcc) with
its OS; does it mean another compiler is going
On Saturday 18 February 2012, David Faure wrote:
On Friday 17 February 2012 18:31:58 Alexander Neundorf wrote:
I'm not quite sure in the code above in which cases there is a bad
allocator, and whether -Werror=return-type -fvisibility-inlines-hidden
is something everybody should do or not.
On Sunday 19 February 2012 10:18:50 Alexander Neundorf wrote:
On Saturday 18 February 2012, David Faure wrote:
On Friday 17 February 2012 18:31:58 Alexander Neundorf wrote:
I'm not quite sure in the code above in which cases there is a bad
allocator, and whether -Werror=return-type
Alexander Neundorf wrote:
On Saturday 18 February 2012, David Faure wrote:
On Friday 17 February 2012 18:31:58 Alexander Neundorf wrote:
I'm not quite sure in the code above in which cases there is a bad
allocator, and whether -Werror=return-type
-fvisibility-inlines-hidden is something
Stephen Kelly steve...@gmail.com writes:
For what it's worth, I don't think we should have code in ecm which appears
to work with older compilers unless we actually test it. None of us (I
presume?) are still using GCC 4.1 or 4.2 and want to use 'the KDE compiler
settings' with it.
If in the
Raphael Kubo da Costa wrote:
Stephen Kelly steve...@gmail.com writes:
For what it's worth, I don't think we should have code in ecm which
appears to work with older compilers unless we actually test it. None of
us (I presume?) are still using GCC 4.1 or 4.2 and want to use 'the KDE
Stephen Kelly steve...@gmail.com writes:
For KDE Frameworks 5, gcc 4.2 is too old. Qt5 requires a much more recent
version (I don't recall which exactly).
Unfortunately I'm a bit behind in the Qt5 discussions and development. I
tried to look for something about this in wiki.qt-project.org and
Alexander Neundorf wrote:
Hi Stephen,
with your export header stuff you did for cmake 2.8.7, you must have done
a lot with the symbol visibility stuff.
Is there now a cmake module which I can use to check whether visibility is
supported by the current compiler ?
The current
On Friday 17 February 2012, Stephen Kelly wrote:
Alexander Neundorf wrote:
Hi Stephen,
with your export header stuff you did for cmake 2.8.7, you must have done
a lot with the symbol visibility stuff.
Is there now a cmake module which I can use to check whether visibility
is
On Friday 17 February 2012, Alexander Neundorf wrote:
...
I'm not quite sure in the code above in which cases there is a bad
allocator, and whether -Werror=return-type -fvisibility-inlines-hidden
is something everybody should do or not.
Alex
Two hints: in cmake master the compiler version
(similarly for KDE_IMPORT).
I disagree. coupling them with Qt deserves no purpose (there might be distros
out there that compile Qt without hidden visibility for compatibility but
still don't want a slow KDE).
Dirk
___
Kde-buildsystem mailing list
KDE_EXPORT as
Q_DECL_EXPORT (similarly for KDE_IMPORT).
I disagree. coupling them with Qt deserves no purpose (there might be
distros
out there that compile Qt without hidden visibility for compatibility but
still don't want a slow KDE).
Compatibility with what? This is Qt 4, those symbols have been
Hi,
as I just got my second report that phonon doesn't link I thought I'd better
implement a check that errors out if Qt has been compiled without visibility
support but KDE is compiled with default hidden visibility.
This is necessary for
1. phonon which uses Q_DECL_EXPORT as export macro
2
Matthias Kretz said:
Hi,
as I just got my second report that phonon doesn't link I thought I'd
better
implement a check that errors out if Qt has been compiled without
visibility
support but KDE is compiled with default hidden visibility.
This is necessary for
1. phonon which uses
On 21.06.07 14:18:03, Thiago Macieira wrote:
Matthias Kretz said:
Hi,
as I just got my second report that phonon doesn't link I thought I'd
better
implement a check that errors out if Qt has been compiled without
visibility
support but KDE is compiled with default hidden
but KDE is compiled with default hidden visibility.
This is necessary for
1. phonon which uses Q_DECL_EXPORT as export macro
2. all plugins that export their entry symbols using Q_DECL_EXPORT or
any
other macro that uses Q_DECL_EXPORT
Ok, to commit the attached patch?
It's
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At least on a default-built qt-copy.
It's not the fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is
On 21.06.07 15:41:21, Thiago Macieira wrote:
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At least on a default-built qt-copy.
It's not the
On 21.06.07 15:58:45, Andreas Pakulat wrote:
On 21.06.07 15:41:21, Thiago Macieira wrote:
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At
Thiago Macieira schrieb:
Christian Ehrlicher said:
and while this works on Win32, it breaks on linux because Q_DECL_EXPORT
doesn't evaluate to default-visibility (don't know the gcc command for
that) but to nothing. At least on a default-built qt-copy.
It's not the fault of Q_DECL_EXPORT but
Matthias Kretz said:
On Thursday 21 June 2007, Thiago Macieira wrote:
It's much easier and even probably better to define KDE_EXPORT as
Q_DECL_EXPORT (similarly for KDE_IMPORT).
That will only move the link error to the first KDE lib that gets linked
to a
program - if we use our own check
Christian Ehrlicher said:
Thiago Macieira schrieb:
Christian Ehrlicher said:
It's not the fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is defined
to
nothing on linux.
That's not a problem on ELF/x86, but I do wonder how it compiles at all
under 64-bit.
It's working because tt uses
27 matches
Mail list logo
