>Crap! It seems I finally found the exactly line that triggers the
>cmake bug! =)
Great!
>Try this...
>
>PS: I'm not sure if it will break something in other nm-related
>modules...
>But it should repair the build of the tdelibs with the 2.8.12.
>PPS: Also there could be some other similar issues in other
>modules...
You and Slavek seem to be on similar paths. He just attached a
patch to bug report 1759. I'm in the middle of testing his patch
now. I only just started but with Slavek's patch tdelibs finally
finished the configuration without the infamous LINK_ONLY error and
is compiling with 2.8.12. I still need to test with 2.8.12.1 and
then backwards compatibility with 2.8.8.
Darrell
>Try this patch... expected results are:
><cmake-2.8.12: works fine as always were
>=cmake-2.8.12: no warnings; but the same LINK_ONLY-bla-bla error
>/* I still
>can't reproduce it, but I suspect it's because of some link flags
>e.g. I
>don't use hidden-visibility*/
>cmake-2.8.12.1: no warnings; clean build.
Your patch works nicely with cmake <= 2.8.12.0 or 2.8.12.1. Builds
are clean. As you noted, the patch does not help with 2.8.12.0.
I receive the same exact LINK_ONLY failure.
As noted, the problem is described in the gentoo bugzilla:
https://bugs.gentoo.org/show_bug.cgi?id=490194
The bug report mentions a specific patch and the patch became part
of cmake 2.8.12.1.
To my understanding, there is no downstream fix for this breakage
with 2.8.12.0. The best we will be able to do for Trinity packagers
is to let them know that Trinity will not build with 2.8.12.0.
I asked the Slackware maintainer to update Slackware 14.1 to cmake
2.8.12.1 and I referenced the gentoo bugzilla. All I can do now is
wait and see.
I believe the Slackware maintainer avoided problems with cmake
2.8.12.0 in that the 2.8.12.0 was not updated in the Slackware 14.1
release cycle until just before RC1, well after all of the KDE
packages had been built. Very likely he never saw the same build
failures because he used cmake 2.8.10.2 to build the KDE4 packages
for Slackware 14.1.
Darrell
All,
In the upcoming R14.0.0 press release I would like to include one
user and one developer opinion why they enjoy Trinity R14.0.0.
These types of quotations are common in product related press
releases.
If you volunteer an opinion, please be aware that some kind of
identity connection to you is necessary. That connection can be a
well-known online alias, but birth names are preferred to enhance
credibility. The reason is in case a reviewer or reporter decides
to perform fact checking. The press release will not include email
addresses or anything like that. Just a name that a reviewer or
reporter can identify and through the contacts listed at the end of
the press release, be able to contact you to validate or expand
upon your opinion.
Although many people prefer privacy, providing an opinion and a
name in the press release could serve as a free publicity of your
coding and project participation skills.
Please limit opinions to a maximum of three sentences. If English
is not your native language, please still feel welcome to offer an
opinion. I'll help you massage the text.
As primary developers, Tim and Slavek should be the main press
release contact points, but that is a decision for both of you to
make.
A draft of the press release is available in the etherpads:
http://trinity.etherpad.trinitydesktop.org/37
Please feel welcome to improve the draft.
Please post any such opinions here to the dev mail list. I'll
select two, although I might roll dice to perform the selection. :-)
Thank you!
Darrell
tdebase FTBFS on kdesktop than it is built with clang. It's because clang
can't handle "-z now" correctly. Build log: http://bpaste.net/show/160888/
Here is a patch.
I'm going to provide yet another patch for LINKER_IMMEDIATE_BINDING_FLAGS
wondering
>>>I see this on my workstation with a flaky USB mouse. Do you see
>>>frequent USB device disconnect/reconnect events in dmesg?
>>
>> I'm not seeing anything in the logs. Would you please show me a
>> snippet of what you have seen?
>>
>> Darrell
>
>I'm not at that machine right now, but it is very obvious in the
>syslog.
>
>I'll have to see if I can replicate on my R14 test box.
I see nothing obvious in my system logs.
Could the recent patches to use udisks rather than pmount play a
role in this?
Darrell
All,
I ran some more testing against the cmake 2.8.12 CMP-0022 problem.
The TL;DR version:
The proposed patch partially works but needs attention. If we
refine the patch to eliminate certain errors we probably will be
able to place this entire cmake episode behind us. :-)
The longer story:
On Slackware 14.0 I have no problems compiling Trinity packages.
The stock Slackware 14.0 came with cmake 2.8.8, but a while ago I
updated my 14.0 build environment to cmake 2.8.10.2. I updated
cmake because I was trying to anticipate what eventually would
become Slackware 14.1. Along the way of developing the 14.1 branch
after Slackware 14.0, cmake was updated to 2.8.10.2. Regardless, I
have had no problems with 2.8.8 or 2.8.10.2.
Slackware 14.0 comes with gcc 4.7.1 and glibc 2.15.
In all of the following tests I attempted to build only the
dependencies and core packages through tdebase. In each test I
rebuilt all packages except TQt3 because that package has no cmake
requirements.
On Slackware 14.0, I built and installed cmake 2.8.12.0. I did not
apply the proposed patch. I saw a slew of CMP0022 warnings for arts
and tdelibs. While arts did compile, I was unable to build tdelibs.
Next on Slackware 14.0, I built and installed cmake 2.8.12.1. I did
not apply the proposed patch. I again saw a slew of CMP0022
warnings for arts, tdelibs, and tdebase. This time I was able to
build tdelibs and tdebase. Thus 2.8.12.1 does provide a work-around
to 2.8.12.0.
Next on Slackware 14.0, I returned to cmake 2.8.8 (the version
provided in the original 14.0). I applied the proposed patch. This
was to test backwards compatibility of the patch in distros using
cmake < 2.8.12. I got as far as tdelibs with no errors or warnings.
tdebase failed to build, with a slew of errors such as the
following:
/dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference
to `TQString::TQString(char const*)'
/dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference
to `TDEGlobal::locale()'
/dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference
to `TDELocale::removeCatalogue(TQString const&)'
CMakeFiles/kgreet_winbind-
module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI7TQGList[_ZTI7TQGL
ist]+0x8): undefined reference to `typeinfo for TQPtrCollection'
CMakeFiles/kgreet_winbind-
module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI15KWinbindGreeter[
_ZTI15KWinbindGreeter]+0x10): undefined reference to `typeinfo for
TQObject'
CMakeFiles/kgreet_winbind-
module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTV7TQGList[_ZTV7TQGL
ist]+0xc): undefined reference to `TQGList::clear()'
Next on Slackware 14.0, I returned to cmake 2.8.10.2. I applied the
proposed patch. Again no build failures through tdelibs while
tdebase failed to build with the same errors.
Next on Slackware 14.0, I returned to cmake 2.8.12.0. I applied the
proposed patch. tdelibs failed to build, but I saw the same
failures in Slackware 14.1. Apparently at least part of the patch
is required to build tdelibs with cmake 2.8.12.0.
Next on Slackware 14.0, I returned to cmake 2.8.12.1. I applied the
proposed patch. Again no build failures through tdelibs while
tdebase failed to build with the same errors.
The original cmake 2.8.12 problems I reported occurred with
Slackware 14.1 and not 14.0. I used 14.0 as a test environment to
establish some kind of baseline.
The primary differences between Slackware 14.1 and 14.0: cmake
2.8.12.0 vs. 2.8.8, gcc 4.8.2 vs. 4.7.1, and glibc 2.17 vs. 2.15.
Yet by using Slackware 14.0 I believe I affirmed the failures I am
experiencing are not related to gcc, glibc, etc.
Some Trinity members report they can build Trinity with cmake
2.8.12.0 although they witness the slew of CMP0022 warnings. With
2.8.12.X I always have been able to build arts but always either
fail to build tdelibs or tdebase. The proposed patch allows me to
build tdelibs but not tdebase.
I don't believe the problem is Slackware 14.1. Just cmake 2.8.12.X.
Darrell
>IMO it's a good idea to update at least to 2.6. Lower versions
>definitely won't work...
>I'm not sure about 2.8. It may be only a «soft» limit. On the
>other hand I
>don't suppose it will cause any problems... And nobody will test
>for
>compatibility with versions lower than 2.8... And nobody of users
>would be
>able to because tdelibs requres 2.8... so, go ahead =)
>
>NOTE: I'm just successfully built tdebase and tdelibs with cmake
>versions 2.8.0 and 2.8.3.
The oldest release of Slackware that I can build Trinity is 13.1.
In bug report 1741 I shared my attempts at building Trinity in
Slackware 12.2 and 13.0. Ignoring cmake, newer versions of several
upstream packages need to be backported to build Trinity in
Slackware 12.2 or 13.0. Trinity builds in Slackware 13.1 just fine.
Slackware 13.1 was released with cmake 2.8.1.
If we establish cmake 2.8 as a minimum requirement, we then ---
indirectly --- include other problematic upstream packages against
which Trinity would not build. That is, any distro that came with
cmake 2.8 likely did not include the older upstream packages that
would be problematic for building Trinity.
Darrell
>CMakeLists.txt in tdelibs and tdebase defines 2.8. But I'm not
>sure in it... may be it should be updated...
Thanks, that helped!
With that information, here is what I found:
tdeutils/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdegraphics/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdepim/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdeartwork/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdenetwork/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdebase/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdeaddons/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdemultimedia/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdesdk/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdelibs/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
tdetoys/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 )
applications/tdesvn/CMakeLists.txt: cmake_minimum_required( VERSION
2.8 )
applications/kgtk-qt3/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/wlassistant/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/amarok/CMakeLists.txt: cmake_minimum_required( VERSION
2.8 )
applications/konversation/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/tde-style-qtcurve/CMakeLists.txt:
cmake_minimum_required( VERSION 2.8 )
applications/abakus/CMakeLists.txt: cmake_minimum_required( VERSION
2.8 )
applications/gtk-qt-engine/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/rosegarden/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/tdeio-locate/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
applications/kbfx/CMakeLists.txt: cmake_minimum_required( VERSION
2.8 )
dependencies/dbus-tqt/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
dependencies/tqtinterface/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
dependencies/dbus-1-tqt/CMakeLists.txt: cmake_minimum_required(
VERSION 2.8 )
tdevelop/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 )
tdewebdev/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 )
applications/tdepowersave/CMakeLists.txt: cmake_minimum_required(
VERSION 2.6 )
applications/knetworkmanager8/CMakeLists.txt:
cmake_minimum_required( VERSION 2.6 )
applications/tdenetworkmanager/CMakeLists.txt:
cmake_minimum_required( VERSION 2.6 )
applications/dolphin/CMakeLists.txt: cmake_minimum_required(
VERSION 2.6 )
applications/kpowersave/CMakeLists.txt: cmake_minimum_required(
VERSION 2.6 )
dependencies/arts/CMakeLists.txt: cmake_minimum_required( VERSION
2.6 )
applications/kpilot/CMakeLists.txt: cmake_minimum_required(VERSION
2.4.4)
applications/kile/src/CMakeLists.txt: CMAKE_MINIMUM_REQUIRED(
VERSION 2.4.4 FATAL_ERROR )
For consistency, should the modules requiring 2.6 or 2.4.4 be
updated to 2.8?
Darrell
All,
At one time I was told the minimum version of cmake required to
compile Trinity is 2.8.4. Where is that explicitly declared,
identified, or tested in the Trinity sources?
Thank you. :-)
Darrell
All,
In preparation for the R14.0.0 release, we would like to establish
minimum system requirements for installing and running Trinity.
Please refrain from "by gosh, by gum" guessing. :-) Please only
share real-world experiences using Trinity with older hardware and
distros as well as limited environments, such as the Raspberry Pi
or ARM.
We don't want to create absurd minimum requirements as has popular.
We want to establish realistic minimum requirements.
Thank you!
Darrell