Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
On Thursday, 21. June 2007, Thiago Macieira wrote: 1. phonon which uses Q_DECL_EXPORT as export macro Can't phonon be fixed to not use broken Qt defines (are they documented at all. Why use undocumented API) ? It's much easier and even probably better to define 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). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
Dirk Mueller said: On Thursday, 21. June 2007, Thiago Macieira wrote: 1. phonon which uses Q_DECL_EXPORT as export macro Can't phonon be fixed to not use broken Qt defines (are they documented at all. Why use undocumented API) ? It's much easier and even probably better to define 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 hidden from the start. Any application making use of them is shooting itself in the foot (and the developer should be shot in the head for using them). I fail to see the reason in intentionally compiling Qt without hidden visibility. If Qt headers don't have the proper visibility guards -- i.e., if in a distribution's provided Qt Q_DECL_EXPORT is defined to nothing -- KDE *cannot* compile with -fvisibility=hidden. The KDE_EXPORT macro has effect in the outcome of Qt classes. Like I said, ELF/x86 will compile fine without the macro, but linking in ELF/x86-64 (and other 64-bit platforms) will break. If the distribution compiled without -fvisibility=hidden but left Q_DECL_EXPORT alone, KDE will compile just fine. That's the point of the macro check that Matthias posted. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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. 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?
PS: please CC me on replys
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: FindKDE4Internal.cmake
===
--- FindKDE4Internal.cmake (revision 677006)
+++ FindKDE4Internal.cmake (working copy)
@@ -753,7 +753,22 @@
if (__KDE_HAVE_GCC_VISIBILITY AND GCC_IS_NEWER_THAN_4_1 AND NOT _GCC_COMPILED_WITH_BAD_ALLOCATOR)
set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility=hidden)
set (KDE4_C_FLAGS -fvisibility=hidden)
+ # check that Qt defines Q_DECL_EXPORT as __attribute__ ((visibility(default)))
+ # if it doesn't and KDE compiles with hidden default visibiltiy plugins will break
+ set(_source #include QtCore/QtGlobal\n int main()\n {\n #ifdef QT_VISIBILITY_AVAILABLE \n return 0;\n #else \n return 1; \n #endif \n }\n)
+ set(_source_file ${CMAKE_BINARY_DIR}/CMakeTmp/check_qt_visibility.cpp)
+ file(WRITE ${_source_file} ${_source})
+ set(_include_dirs -DINCLUDE_DIRECTORIES:STRING=${QT_INCLUDES})
+ try_run(_run_result _compile_result ${CMAKE_BINARY_DIR} ${_source_file} CMAKE_FLAGS ${_include_dirs})
+
+ if(NOT _compile_result)
+ message(FATAL_ERROR Could not compile simple test program ${_source})
+ endif(NOT _compile_result)
+ if(_run_result)
+ message(FATAL_ERROR Qt compiled without support for -fvisibility=hidden)
+ endif(_run_result)
+
if (GCC_IS_NEWER_THAN_4_2)
set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility-inlines-hidden)
endif (GCC_IS_NEWER_THAN_4_2)
pgp55E3bXBMZz.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 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 much easier and even probably better to define KDE_EXPORT as Q_DECL_EXPORT (similarly for KDE_IMPORT). The reason we don't do that is because qglobal.h cannot be included from C source files -- though IMHO it should. So I'd say the following (radical position): 1) change kdemacros.h.cmake to: #ifdef __cplusplus #define KDE_EXPORT Q_DECL_EXPORT #define KDE_IMPORT Q_DECL_IMPORT #else #define KDE_EXPORT #define KDE_IMPORT #endif The definition of KDE_NO_EXPORT can stay, especially because Qt has no equivalent. 2) No C source file can export symbols, period. We don't produce C libraries in KDE. However, unmangled symbols can easily be exported from C++ source files by using extern C. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 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 much easier and even probably better to define KDE_EXPORT as Q_DECL_EXPORT (similarly for KDE_IMPORT). The reason we don't do that is because qglobal.h cannot be included from C source files -- though IMHO it should. Unless I'm overlooking something that will break. I just recently fixed phonone which used if MAKE_PHONON_LIB define PHONON_EXPORT Q_DECL_EXPORT else define PHONON_EXPORT Q_DECL_IMPORT endif 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. 2) No C source file can export symbols, period. We don't produce C libraries in KDE. However, unmangled symbols can easily be exported from C++ source files by using extern C. Thats far better solution IMHO. Andreas -- Don't Worry, Be Happy. -- Meher Baba ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
Von: Andreas Pakulat [EMAIL PROTECTED] 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 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 much easier and even probably better to define KDE_EXPORT as Q_DECL_EXPORT (similarly for KDE_IMPORT). The reason we don't do that is because qglobal.h cannot be included from C source files -- though IMHO it should. Unless I'm overlooking something that will break. I just recently fixed phonone which used if MAKE_PHONON_LIB define PHONON_EXPORT Q_DECL_EXPORT else define PHONON_EXPORT Q_DECL_IMPORT endif 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 defined to nothing on linux. Christian -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 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. Symbols marked hidden tell the compiler it can generate shorter calls, instead of emitting a relocation to a full 64-bit jump. On x86-64, that would be a 32-bit RIP-relative call; on Itanium, it would probably be a one of the weird lengths, like 21- or 25-bit jump. (Itanium can encode short immediates in a single 41-bit instruction, but a full 64-bit displacement requires three instructions, 128 bits) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is defined to nothing on linux. Right, I confused the two. That's not a problem on ELF/x86, but I do wonder how it compiles at all under 64-bit. Oh, cool, then my process must have upgraded itself. Because AFAIK I have a standard x86 Pentium Centrino in my notebook and as soon as PHONON_EXPORT == Q_DECL_IMPORT phonon fails to build with undefined symbols. Andreas -- Hope that the day after you die is a nice day. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 least on a default-built qt-copy. It's not the fault of Q_DECL_EXPORT but Q_DECL_IMPORT which is defined to nothing on linux. Right, I confused the two. That's not a problem on ELF/x86, but I do wonder how it compiles at all under 64-bit. Oh, cool, then my process must have upgraded itself. Because AFAIK I I meant processor of course :) Andreas -- You will remember something that you should not have forgotten. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 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. Symbols marked hidden tell the compiler it can generate shorter calls, instead of emitting a relocation to a full 64-bit jump. On x86-64, that would be a 32-bit RIP-relative call; on Itanium, it would probably be a one of the weird lengths, like 21- or 25-bit jump. (Itanium can encode short immediates in a single 41-bit instruction, but a full 64-bit displacement requires three instructions, 128 bits) It's working because tt uses the export macro in a slightly different way then we do. Q_DECL_IMPORT is never used on linux. Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 whether to use -fvisibility=hidden. So the error message is still needed. I see. It's a matter of the command-line flag. True, true. Then the test is necessary. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
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 the export macro in a slightly different way then we do. Q_DECL_IMPORT is never used on linux. Oh, right. It's like the old-style header the script used to generate: it uses the EXPORT macro in all cases (building and using the library). Anyways, Andreas, undefined symbols are not the symptom of this error. The symptom is about relocations that the static linker cannot emit (i.e., using a near displacement for something that isn't near). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
