On 02/23/2011 01:38 PM, David C. Rankin wrote:
> On 02/22/2011 06:41 PM, Allan McRae wrote:
>> That prelink patch is very, very unlikely to cause the issue. It was also the
>> only change between 2.13-3 and 2.13-4... As I pointed out, there are other
>> distros using that patch without reported issue and it is now in glibc mainline
>> so nothing is obviously wrong with it. Also, I have had no other crash reports
>> since this update...
>>
>>
>> I just looked back through this thread and your backtraces are all over the
>> place. First it was an issue with libxcb, and then on a different VM it is
>> somewhere completely different. What is difference across your VMs that you
>> get consistent crashes in one but not the other?
>>
>> Allan
>
> The basic x86_64 Arch VMs are the SAME VM, just moved from one box to the other
> (one on my laptop copied from my backup server where it was originally
> installed). The packages are identical on the VMs except on the first I had
> rebuilt libxcb and glibc with options(!strip) and CFLAGS="$CFLAGS -g".
>
> I will rebuild Trinity and update both VMs and then give updated .kcrashes for
> each. If 2.13-3 works fine and 2.13-4 causes the crash, it just points to some
> unintended consequence in the update. I'll rebuild, update both and report back.
> But if Baho is also seeing something -- the plot thickens.
>
I have rebuilt libxcb with !strip and CFLAGS="$CFLAGS -g". I have rebuild glibc
with !strip and CFLAGS="$CFLAGS -g" ...and... removed all the 'manual strip'
calls from the bottom of the package() function. The kdesktop crash happens just
as before, but now all the ? marks are gone from the backtrace. The new
backtrace with full information is:
http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop…
before removing the 'manual strip' info from package() it was:
http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop…
This is with Virtualbox 3.2.10. So I upgraded to 4.0.4 to see if there was any
change... There wasn't anything I noticed. Same kdesktop crash:
http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64-archangel/kdesktop…
I have no idea what the error means, but it looks like malloc is complaining
about corruption?
#8 0x00007f3550d27b96 in malloc_printerr (action=3, str=0x7f3550dd6a2e
"malloc(): memory corruption", ptr=<value optimized out>) at malloc.c:6283
#9 0x00007f3550d2a4ad in _int_malloc (av=0x7f3551012ea0, bytes=16) at malloc.c:4396
#10 0x00007f3550d2c460 in __libc_malloc (bytes=16) at malloc.c:3660
I'll also follow up with the Trinity folks because I have just tried downgrading
to glibc 2.13-3 and I'm still getting the error on x86_64. No issues with i686
though??
Any help pointing me in the right direction would be greatly appreciated :)
--
David C. Rankin, J.D.,P.E.
Tim, all,
I am experiencing a kdesktop crash on x86_64 that I don't experience on i686.
I have rebuilt kdelibs and kdebase with -DCMAKE_CXX_FLAGS=-g to hopefully get
meaningful debug information.
What happens is Trinity starts and you have the little splash where the icons
light up showing what part of the desktop is loaded, it gets 1/2 way (just
before the folder) and the desktop crash occurs.
Trinity finishes loading and there are no icons on the desktop and no rt-click
context menu or desktop background. Otherwise all the apps work (konqueror,
kwrite, etc...)
I have attached the kdesktop.kcrash file. Let me know if you need anything else.
The svn revs for the packages installed are:
trinity-arts 1221325-1.1
trinity-kdebase 1221325-1.0
trinity-kdelibs 1221343-1.1
trinity-kdevelop 1221336-1.0
trinity-kdewebdev 1221338-1.0
trinity-pyqt3 3.18.1-9
trinity-qt3 3.3.8-20
trinity-tqtinterface 1221325-1.0
--
David C. Rankin, J.D.,P.E.
Calvin wrote:
On an Intel Atom it takes much longer than 5 minutes :P It broke again D:
Do you think it is related to the environmental variables?
Hmmm..
(1.) The very first thing I want to do is confirm that you have the following
built and installed in this order, so show us 'pacman -Q | grep trinity':
15:34 supersff:~> pacman -Q | grep trinity # then I manually sorted
trinity-qt3 3.3.8-20
trinity-pyqt3 3.18.1-9
trinity-tqtinterface 1221148-1
trinity-arts 1214641-1
trinity-kdelibs 1222098-1
Your stuck at 37% on
trinity-kdebase 1221588-1
(2.) Please post the error you received after rebuilding with 'make VERBOSE=1'
in the build() function. (it will provide a little more info that will help)
Your environment for the build is set within the PKGBUILD file so it shouldn't
matter what your existing shell environment is:
export CMAKE_PREFIX_PATH=/opt/qt:/opt/trinity
CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/usr/include/dbus-1.0:/opt/trinity/include:/opt/trinity/include/libkrandr
export LD_LIBRARY_PATH=/opt/trinity/lib:/opt/trinity/lib/kde3:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=:/opt/trinity/lib/pkgconfig:/opt/qt/lib/pkgconfig
The build environment will be influenced by
/etc/ld.so.conf.d/trinity-kdelibs.conf. So if you have trinity-kdelibs installed:
(3.) confirm you have
cat /etc/ld.so.conf.d/trinity-kdelibs.conf
/opt/trinity/lib
(4.) As root, run ldconfig if the trinity-kdelibs.conf so the linker cache
magic is updated.
What I want to confirm is that you are NOT trying to build on a system with
KDE4/Qt4 or kdemod3 installed. That will screw up your build because of the
conflicting libraries that cmake has trouble ignoring. So:
(5.) look at:
pacman -Q | grep "qt\|kde"
If you have:
qt 4.7.1-3
kdemod3-<anything> 3.5.10-1
kde<xyz>-<anything> 4.6.0-2
The build will fail.
I don't know how a build between a normal i686, x86_64 and an Intel Atom will
differ, but I haven't heard anything that says building on an Intel Atom won't
work -- or that it *will* work for that matter. So let's take it step by step.
Change into
trinity-qt3
do 'makepkg -sf --noextract' to do a quick rebuild of the existing package and
install it with 'sudo pacman -U trinity-qt3-<version>.xz.
do the same thing for trinity-pyqt3
Change into
trinity-tqtinterface - a simple makepkg -sf and install with 'sudo pacman -U
trinity-tqtinterface-<version>.xz.
Do the same thing for 'trinity-arts' and 'trinity-kdelibs'. After
'trinity-kdelibs' is installed - and run (as root) ldconfig.
(6.) Change into
trinity-kdebase - and restart the build with 'make VERBOSE=1' and post the
output if it fails again.
I'm scratching my head on this one. I've literally built Trinity 5-6 times in
the past 2 days using the build script and gotten no errors during the make. So
the PKGBUILDs work. If there is something special we need to do for the Intel
Atom, then that's something we will have to look into. But, to get started, we
need the information requesting in (1.) - (6.) above :)
--
David C. Rankin, J.D.,P.E.
It seems that i was barking up the wrong tree;
While trying to build trinity-kdebase with the PKBUILD provided i ran into this:
[ 37%] Generating mount_xdr.c
cd /home/calvin/builds/trinity/trinity-kdebase/src/kdebase/kioslave/nfs
&& rpcgen -c -o mount_xdr.c
/home/calvin/builds/trinity/trinity-kdebase/src/kdebase/kioslave/nfs/mount.x
file `mount_xdr.c' already exists and may be overwritten
make[2]: *** [kioslave/nfs/mount_xdr.c] Error 1
make[2]: Leaving directory
`/home/calvin/builds/trinity/trinity-kdebase/src/kdebase'
make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
It appears that mount_xdr already exists (obviously) rpcgen is
attempting to over write it, and so Make gives an error?
If anyone could reproduce this that would be helpful, i am at a complete loss.
Calvin Morrison.
Guys,
Here is another quick todo to add to the svn code. Trinity has done a great
job updating the syntax highlighting files for kate/kwrite from where they were
at 3.5.10, but there are about 40 (37 to be exact) new ones that get downloaded
when you configure kate.
I think all that needs to be done is to take the current:
~/.kde3/share/apps/katepart/syntax
and copy them to
trinity/kdelibs/kate/data
in the svn tree.
Not a biggie, but it is simple to do and really makes it look like Trinity is
up to date. There will always be syntax file updates, but as a goal, if we can
keep an eye on them and keep the required updates to <= 10 or so for Trinity, I
think that looks good.
The current syntax files that get updated are:
> ls -1 ~/.kde3/share/apps/katepart/syntax
alert_indent.xml
ample.xml
asm-dsp56k.xml
asm-m68k.xml
bibtex.xml
bmethod.xml
cmake.xml
commonlisp.xml
cpp.xml
css.xml
cs.xml
c.xml
debianchangelog.xml
doxygen.xml
fortran.xml
gdb.xml
go.xml
grammar.xml
haskell.xml
ini.xml
javascript.xml
json.xml
latex.xml
literate-haskell.xml
objectivecpp.xml
pango.xml
perl.xml
php.xml
python.xml
qml.xml
rpmspec.xml
sql-mysql.xml
sql-postgresql.xml
sql.xml
txt2tags.xml
vhdl.xml
xml.xml
--
David C. Rankin, J.D.,P.E.
Guys,
I'm taking a stab at moving application/knemo to CMake. I'm new to cmake, but
given a reasonable outline of what to do, I'll bet I can slog through it. knemo
seems small enough to serve as a good package to learn with.
What I need to know is "What is the basic outline for moving an existing kde
module to cmake?
I can figure out I need a knemo/cmake directory with modules/TDEMacros.cmake
and a CMakeLists.txt, but after that I'm a bit lost.
I have taken Serghei's kdewebdev CMakeLists.txt and I'm trying to cannibalize
it. I think most everything will work. There are additional line I don't think
I'll need in knemo since there are not any sub-packages like quanta. Can I just
delete the following?:
option( BUILD_QUANTA "Build quanta" ${BUILD_ALL} )
option( BUILD_KFILEREPLACE "Build kfilereplace" ${BUILD_ALL} )
if( BUILD_QUANTA )
add_subdirectory( lib )
endif( )
tde_conditional_add_subdirectory( BUILD_QUANTA quanta )
If I don't have subdirectories like quanta and I can just remove those lines,
that gets me started... But then the question becomes "what else to I need to
change in the knemo/cmake... directory?
Here is my first run and the errors I got. I'll put my comments/questions in
the errors:
CMake Error at CMakeLists.txt:60 (include):
include could not find load file:
ConfigureChecks.cmake
## I get it, I need a ConfigureChecks.cmake. Can I just copy one? What kind of
## changes can I expect to need to make?
CMake Error: File /home/david/tbld/applications/knemo/config.h.cmake does not exist.
CMake Error at CMakeLists.txt:87 (configure_file):
configure_file Problem configuring file
## Same issue, I know I'll need a config.h.cmake, what would be a good one to copy?
That's about where I am on my cmake/knemo journey. If somebody has an outline
to get me going on the cmake conversions, I don't mind helping move the smaller
apps to cmake.
--
David C. Rankin, J.D.,P.E.
Guys,
After rebuilding with the current svn tree, I am getting startkde and kinit
library errors:
X.Org X Server 1.9.4
Release Date: 2011-02-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.37-ARCH i686
Current Operating System: Linux supersff 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 11
16:55:18 UTC 2011 i686
Kernel command line: root=/dev/sda6 ro
Build Date: 04 February 2011 09:39:45PM
Current version of pixman: 0.20.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 18 10:38:49 2011
(==) Using config directory: "/etc/X11/xorg.conf.d"
[startkde] Starting startkde.
[startkde] KDEHOME is not set.
[startkde] Set KDEHOME to /home/david/.kde3.
[startkde] kdehome: /home/david/.kde3
kstartupconfig: error while loading shared libraries: libkdefakes.so.4: cannot
open shared object file: No such file or directory
kde-config: error while loading shared libraries: libkdecore.so.4: cannot open
shared object file: No such file or directory
[startkde] KDEDIR: /opt/trinity/
[startkde] KDEDIRS: /opt/trinity/:/usr/
[startkde] kdedirs_first: /opt/trinity/
[startkde] Starting Trinity...
ksplash: error while loading shared libraries: libksplashthemes.so.0: cannot
open shared object file: No such file or directory
[startkde] KDE_FULL_SESSION: true
[startkde] KDE_SESSION_UID: 1000
/opt/trinity/bin/kdeinit: error while loading shared libraries: libkparts.so.2:
cannot open shared object file: No such file or directory
[startkde] Could not start kdeinit. Check your installation.
[startkde] kdeinit started successfully.
[trinity kinit] Warning: connect() failed: : No such file or directory
ksmserver: error while loading shared libraries: libkdeinit_ksmserver.so: cannot
open shared object file: No such file or directory
dcop: error while loading shared libraries: libDCOP.so.4: cannot open shared
object file: No such file or directory
[startkde] Shutting down Trinity...
[trinity kinit] Warning: connect() failed: : No such file or directory
[trinity kinit] Error: Can't contact kdeinit!
artsshell: error while loading shared libraries: libsoundserver_idl.so.1: cannot
open shared object file: No such file or directory
[startkde] Running Trinity shutdown scripts...
[startkde] Trinity shutdown complete.
xinit: connection to X server lost
waiting for X server to shut down
This is occurring with at least the following range of svn revisions:
10:48 supersff:~/arch/tpkg> ls -1 i686-new
trinity-arts-1214641-1-i686.pkg.tar.xz
trinity-kdebase-1221326-1-i686.pkg.tar.xz
trinity-kdelibs-1220926-1-i686.pkg.tar.xz
trinity-kdevelop-1216516-1-i686.pkg.tar.xz
trinity-kdewebdev-1216789-1-i686.pkg.tar.xz
trinity-tqtinterface-1221148-1-i686.pkg.tar.xz
and
10:49 supersff:~/arch/tpkg> ls -1 i686-pam/
trinity-kdebase-1221507-1-i686.pkg.tar.xz
trinity-kdelibs-1220926-1.1-i686.pkg.tar.xz
Let me know what else I can send to help debug. It's not just a result of
-DWITH_PAM, because the packages above (i686-new directory) were built without
pam enabled. So this is from at least kdelibs 1220926 or kdebase 1221326 (I
don't know which package is to blame)
--
David C. Rankin, J.D.,P.E.