Several days ago we discussed updating the mlt sources.
I looked at that today. I need help knowing how to do this.
1. Many file differences and stupid git requires "git add" for new additions (but needs no help with deletions --- go figure).
2. mlt++ is now part of the mlt sources and would not need to be a separate libary in the source tree.
3. How to add the tqt layer to anything needing that if needed? I think only the qimage module is affected. qimage will know about Qt3 but not TQt3.
4. I'm still confused why we want to keep these sources in the tree when we do not provide anything needing them (unless kdenlive is ported). But I'll still try updating if provided sufficient information.
Darrell
All,
I have opened a bug for handling gcc 4.7 build failure issues:
http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=958
I have also uploaded a complete set of build logs for the packages listed as
not building due to gcc 4.7 changes. I have set the priority to 'major'. Tim
will need to determine if this is what it should be or whether it should be
elevated for R14. Thankfully the packages that are affected is relatively small.
Thus far:
basket
gwenview
k3b
kima
kipi-plugins
krusader
python-tqt
rosegarden
tdebase ( now requires -fpermissive )
tdegames
tdegraphics
tdepim
tdesdk
The big issue is that distros that ship or update to 4.7 will not be able to
build TDE until these issues are resolved. That eliminates Archlinux as the
build environment updates to build on the current stable release of all packages
(including gcc).
Some build failures may be able to be handled by compiler/linker flags, where
code changes will be required for the rest. The primary culprit seems to be gcc
4.7 implementation of additional features and extensions from C11 and C++11. The
changes are summarized at: http://gcc.gnu.org/gcc-4.7/changes.html
My guess for the lead suspect is:
G++ now correctly implements the two-phase lookup rules such that an unqualified
name used in a template must have an appropriate declaration found either in
scope at the point of definition of the template or by argument-dependent lookup
at the point of instantiation. As a result, code that relies on a second
unqualified lookup at the point of instantiation to find functions declared
after the template or in dependent bases will be rejected. The compiler will
suggest ways to fix affected code, and using the -fpermissive compiler flag will
allow the code to compile with a warning.
template <class T>
void f() { g(T()); } // error, g(int) not found by argument-dependent lookup
void g(int) { } // fix by moving this declaration before the declaration of f
template <class T>
struct A: T {
// error, B::g(B) not found by argument-dependent lookup
void f() { g(T()); } // fix by using this->g or A::g
};
struct B { void g(B); };
int main()
{
f<int>();
A<B>().f();
}
That would explain my need to use -fpermissive to build tdebase last night
where I never needed it before.
Oh, well, the challenges of progress... Let's rip this apart and 'get her
fixed' :)
--
David C. Rankin, J.D.,P.E.
All,
I was successful in developing a patch for the tdeedu package. It largely was
another stl library vector with missing 'this->' prefixes in the class calls.
tdeedu builds fine now! That's it for tonight.
Now if I can just get a bit of help with tdepim, k3b, & digikam, we will be
one to new packages...
--
David C. Rankin, J.D.,P.E.
All,
Chasing down the gcc47 issues in k3b I have it one over my pay grade. It is
another one of the strange 'redeclaration' issues that I can't quite figure out.
C++ gurus, I need a hand :) Last bit of error below:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I./../../libk3b/core
-I./../../libk3bdevice -I./../../libk3b/projects
-I./../../libk3b/projects/audiocd -I./../../libk3b/projects/datacd
-I./../../libk3b/projects/mixedcd -I./../../libk3b/projects/movixcd
-I./../../libk3b/projects/datadvd -I./../../libk3b/projects/videocd
-I./../../libk3b/projects/videodvd -I./../../libk3b/projects/movixdvd
-I./../../libk3b/cddb -I./../../libk3b/tools -I./../../libk3b/plugin -I./../rip
-I./.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h
-I/usr/include/tqt -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security
-Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -I/usr/include/tqt -MT k3baudiotrackdialog.lo -MD -MP -MF
.deps/k3baudiotrackdialog.Tpo -c k3baudiotrackdialog.cpp -fPIC -DPIC -o
.libs/k3baudiotrackdialog.o
k3baudioeditorwidget.cpp: In member function 'virtual void
K3bAudioEditorWidget::mousePressEvent(TQMouseEvent*)':
k3baudioeditorwidget.cpp:674:12: error: redeclaration of
'K3bAudioEditorWidget::Range* r'
k3baudioeditorwidget.cpp:668:14: error: 'K3bAudioEditorWidget::Range* r'
previously declared here
make[4]: *** [k3baudioeditorwidget.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
mv -f .deps/k3baudiocdtextwidget.Tpo .deps/k3baudiocdtextwidget.Plo
mv -f .deps/k3baudioburndialog.Tpo .deps/k3baudioburndialog.Plo
mv -f .deps/k3baudiotrackdialog.Tpo .deps/k3baudiotrackdialog.Plo
The full error is here;
http://www.3111skyline.com/dl/dt/tde/err/gcc47/k3b/tde-k3b-3.5.14_dev-3-x86…
--
David C. Rankin, J.D.,P.E.
Many of the initial errors are gone as a result of this patch:
However, then in the code called from the files where the patch was applied,
give class segment undefined errors:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_algo.h:5683:2:
required from 'void std::stable_sort(_RAIter, _RAIter, _Compare) [with _RAIter
=
__gnu_cxx::__normal_iterator<std::_Rb_tree_const_iterator<Rosegarden::Event*>*,
std::vector<std::_Rb_tree_const_iterator<Rosegarden::Event*> > >; _Compare =
Rosegarden::GenericChord<Rosegarden::Event, Rosegarden::Segment,
true>::PitchGreater]'
/build/src/rosegarden/src/base/Sets.h:386:9: required from
'Rosegarden::GenericChord<Element, Container,
singleStaff>::GenericChord(Container&, Rosegarden::GenericChord<Element,
Container, singleStaff>::Iterator, const Rosegarden::Quantizer*,
Rosegarden::PropertyName) [with Element = Rosegarden::Event; Container =
Rosegarden::Segment; bool singleStaff = true; Rosegarden::GenericChord<Element,
Container, singleStaff>::Iterator =
std::_Rb_tree_const_iterator<Rosegarden::Event*>]'
/build/src/rosegarden/src/commands/notation/AddFingeringMarkCommand.cpp:76:69:
required from here
/build/src/rosegarden/src/base/Sets.h:680:70: error: 'class
Rosegarden::GenericChord<Rosegarden::Event, Rosegarden::Segment,
true>::PitchGreater' has no member named 'getAsEvent'
/build/src/rosegarden/src/base/Sets.h:681:70: error: 'class
Rosegarden::GenericChord<Rosegarden::Event, Rosegarden::Segment,
true>::PitchGreater' has no member named 'getAsEvent'
make[2]: ***
[src/CMakeFiles/RosegardenCommands-static.dir/commands/notation/AddFingeringMarkCommand.cpp.o]
Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/build/src/build'
make[1]: *** [src/CMakeFiles/RosegardenCommands-static.dir/all] Error 2
make[1]: Leaving directory `/build/src/build'
make: *** [all] Error 2
Not a simple one here. What to try next??
Patch attempted:
--
David C. Rankin, J.D.,P.E.
I started the process of updating all final HTML install paths so all modules are consistent. The changes are in support of bug report 660.
I pushed a patch to the common admin directory in GIT hash ee037c6f.
I pushed a patch to the common cmake directory in GIT hash d2f658ca.
These patches should replicate down to all other module admin and cmake directories on the main GIT server.
Thereafter everyone building from GIT will need to resync their local repositories to see these changes.
Included is a patch with similar changes to tdelibs kstandarddirs.cpp and kstandarddirs.h. GIT hash 979b0c9a.
There are additional changes that need to be made, mostly in various docbook files, README files, etc., but none of those changes should affect building packages or the final HTML installation location.
The final result of this effort is each package will install the help files in the same location.
To my understanding there is nothing for everybody to do. Just wait several hours to resync.
You should see the patches tomorrow in the Commit Patches web page. At that point I presume the admin/cmake changes will have replicated throughout the entire source tree as well.
Please! Let me know if you experience any build failures. I haven't tried patches like this before.
Darrell
All, Darrell,
tdegraphics, kima and basket now build on gcc 4.7.
tdegraphis: requires -DCMAKE_CXX_FLAGS="-fpermissive"
kima: requires patch to cpufreqdconnection.h (attached)
basket: requires patch to likeback.cpp (attached)
**all patches are attached to bug 958
After getting signoff - please push. The patches are simple header inclusions: eg:
+#include <unistd.h>
+#include <sys/types.h>
--
David C. Rankin, J.D.,P.E.