>I am running multiple builds of tqt3 so you will be able to see
>how
>each build run results in a different 'undefined symbol' message.
When building from git and no additional patching, I saw a slew of
the following "undefined symbol" errors:
============================================
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor11eventFilterEP8TQObjectP7TQEvent
============================================
This is what started the mess.
With your proposed patch from earlier today, I then saw a slew of
the following "undefined symbol" errors:
============================================
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor13keyPressEventEP10TQKeyEvent
============================================
After seeing what you did in your patch --- while having no idea
how any of this works, I looked at the previous build log and added
another Q_EXPORT. The modified snippet added to your patch:
============================================
-void Editor::keyPressEvent( TQKeyEvent *e )
+Q_EXPORT void Editor::keyPressEvent( TQKeyEvent *e )
============================================
With that updated patch, I see another new slew of "undefined
symbol" errors:
============================================
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor16doKeyboardActionEN10TQTextEdit14KeyboardActionE
============================================
So I continue this game and I add this snippet to the patch:
============================================
-void Editor::doKeyboardAction( KeyboardAction action )
+Q_EXPORT void Editor::doKeyboardAction( KeyboardAction action )
============================================
With that updated patch, I see yet another slew of the following
"undefined symbol" errors:
============================================
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor16doChangeIntervalEv
============================================
According to how this game seems to play I should next do this:
============================================
-void Editor::doChangeInterval()
+Q_EXPORT void Editor::doChangeInterval()
============================================
At this point I give up.
Darrell
>I'm going back to the beginning.
>
>I'm trying to find where is linked tqt3 plugin cppeditor -
>elsewhere than
>in tqt3, but I cannot find any place. Please, can you see where it
>is linked in your builds?
What do I look for?
Darrell
>You can be sure that I patch tested several times.
>
>Initial patch from François caused FTBFS (as you can find earlier
>in the
>mailing-list http://trinity-devel.pearsoncomputing.net/?0::11678
>). So I
>worked on the patch longer time and tested on various versions of
>Debian / Ubuntu distributions. Patch to solve the problem of
>hidden-visibility was published on 20 January (see
>http://bugs.pearsoncomputing.net/show_bug.cgi?id=1560#c111 ). In
>testing I
>tested building tdelibs, tdebase and tdevelop (which is the only
>one who
>used tqassistant). After all the testing I pushed patches on 2
>Feb.
I'm sure you tested. You almost always do. All I'm saying is none
of us were invited to test. If I had run the patches a week ago I
would have discovered the messages immediately. The messages snuck
past me for the past few days because I'm knee deep in working on
the help handbooks and I'm not building fresh package sets as often.
In the bug report you mention hidden visibility and shared versus
static.
In my tqt3 build script configuration I am using "-shared" and I
have used that option from the beginning. I don't have any
configuration option about visibility like other build script
configurations. When I run configure --help I don't see any options
related to visibility. Should I? My build log is filled with "-
fvisibility=hidden -fvisibility-inlines-hidden."
I am running multiple builds of tqt3 so you will be able to see how
each build run results in a different 'undefined symbol' message.
Darrell
>I know I get caught with the real-world taking a day or two of
>time away from
>getting RC1 ready to freeze, but we really should be allowing at
>least that long
>for testing before pushing at this point.
>
>Like the .la -> .so push, great move forward, but we should get a
>sign-off from
>each of the active builders before pushing, or at least send a "I
>am about to
>push X that might break Y, please test.."
I won't be surprised if others have the 'undefined symbol' errors
too because the packages all build for me. None fail to build. If
build without failure is the only barometer then nobody pays
attention to the build logs. Yet my build logs are filled with the
errors.
My master build script options looks for a whole slew of build
related errors and warnings and that is how I see these things all
the time. Building without failure is only half the battle.
Darrell
>heh,heh,heh, sip4-tqt FTBFS, python-tqt FTBFS, tdeutils FTBFS,
>etc... I feel your pain... and share the bags under your eyes :-)
The point being that FTBFS patches are being pushed lately without
everybody having an opportunity to test. "Works for me" is not a
good motto. I understand that somebody needs a patch to avoid
FTBFS. I get that. We all do. Yet FTBFS patches should be tested by
everybody involved.
Darrell
I don't know what happened in the past week, but all of my build
logs are filled with this kind of spew:
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor11eventFilterEP8TQObjectP7TQEvent
Including tqt3.
My build set from a week ago does not have this and I never have
seen this before in every single module.
What happened?
Darrell
> Can you confirm the size of the python-trinity package you are
>building. I
>built python-trinity last night for the first time and I was
>bewildered by the
>fact it took 20 minutes to build and resulted in a package that
>was over 20M.
According to my build log, python-trinity takes almost 10 minutes
to build on my dual core and is about 4.8 MB (txz).
Darrell
>Could Darrell's issue be that he still has some components of TDE
built
>that are looking for the static libs when now only the shared libs
exist?
No. This is a clean build from scratch in a clean chrooted build
environment. The errors appear in tqt3.
I always build Trinity in a clean chrooted build environment.
>I bet that is it...
Well, pay up because that is not the cause.
Yes, I'm irritated. Please reverse the patches and post to a bug
report where they can be tested.
Darrell