Building Qt 4.7.1 on Solaris 10
-
Hi all,
I'm trying to build Qt on Solaris 10 and it's quite a painful operation. I'm using Sun C++ 5.8 (don't tell me to use something else, it's on a very controlled environment, and it's the official compiler).
Doing a configure:
@./configure -no-script
-no-scripttools
-no-qt3support
-no-multimedia
-no-phonon
-no-webkit
-no-svg
-no-javascript-jit
-no-declarative
-no-openvg
-no-gtkstyle
-xmlpatterns
-no-glib
-nomake examples
-nomake demos@
seems to work, qmake is built, but carrying on the config script when qmake tries to create project files for config.tests it ends with a segfault.
So I rebuilt qmake with -g flag and debug it. This is the call stack:
@
=>[1] QString::operator==(this = 0x5ca717, other = CLASS), line 2139 in "qstring.cpp"
[2] operator==(key1 = STRUCT, key2 = STRUCT), line 892 in "qregexp.cpp"
[3] QHash<QRegExpEngineKey,QCache<QRegExpEngineKey,QRegExpEngine>::Node>::remove(this = 0x59463c, akey = STRUCT), line 794 in "qhash.h"
[4] QCache<QRegExpEngineKey,QRegExpEngine>::unlink(this = 0x594634, n = STRUCT), line 74 in "qcache.h"
[5] QCache<QRegExpEngineKey,QRegExpEngine>::take(this = 0x594634, key = STRUCT), line 176 in "qcache.h"
[6] prepareEngine_helper(priv = 0x6101e0), line 3708 in "qregexp.cpp"
[7] prepareEngine(priv = 0x6101e0), line 3725 in "qregexp.cpp"
[8] prepareEngineForMatch(priv = 0x6101e0, str = CLASS), line 3730 in "qregexp.cpp"
[9] QRegExp::indexIn(this = 0xffbfc780, str = CLASS, offset = 0, caretMode = CaretAtZero), line 4114 in "qregexp.cpp"
[10] Option::fixString(string = CLASS, flags = '\007'), line 638 in "option.cpp"
[11] Option::fixPathToLocalOS(in = CLASS, fix_env = true, canonical = true), line 130 in "option.h"
[12] MakefileGenerator::fileFixify(this = 0x5fce50, file = CLASS, out_d = CLASS, in_d = CLASS, fix = FileFixifyDefault, canon = true), line 2854 in "makefile.cpp"
[13] MakefileGenerator::init(this = 0x5fce50), line 631 in "makefile.cpp"
[14] UnixMakefileGenerator::init(this = 0x5fce50), line 182 in "unixmake.cpp"
[15] MakefileGenerator::setProjectFile(this = 0x5fce50, p = 0xffbfe5cc), line 308 in "makefile.cpp"
[16] MetaMakefileGenerator::createMakefileGenerator(proj = 0xffbfe5cc, noIO = false), line 496 in "metamakefile.cpp"
[17] BuildsMetaMakefileGenerator::init(this = 0x5ccf80), line 140 in "metamakefile.cpp"
[18] MetaMakefileGenerator::createMetaGenerator(proj = 0xffbfe5cc, name = CLASS, op = false, success = 0xffbfe53e), line 512 in "metamakefile.cpp"
[19] runQMake(argc = 15, argv = 0xffbfe6e4), line 172 in "main.cpp"
[20] main(argc = 15, argv = 0xffbfe6e4), line 194 in "main.cpp"
@
so the line is @if (d->size != other.d->size)@The thing is that this->d points to an invalid memory location (0x80000000). Suspecting a QString build issue I logged the stderr after rebuilding qmake. The only warning I have is @5: Warning: d hides QString::d.@
I have no idea how to fix that any ideas?
Thank you for your help -
Well I'm still struggling to have a working Qt on Solaris 10. Doing a ldd on qmake give me:
@$ ldd qmake
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libm.so.2 => /usr/lib/libm.so.2
libc.so.1 => /usr/lib/libc.so.1
/usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
/platform/SUNW,Netra-T12/lib/libc_psr.so.1@Because I'm desperate I compiled qmake with a different config spec (-platform solaris-g++) using g++. I'ts working... Then I did a ldd too:
@$ ldd qmake
libstdc++.so.6 => /local/lib/libstdc++.so.6
libm.so.2 => /usr/lib/libm.so.2
libgcc_s.so.1 => /local/lib/libgcc_s.so.1
libc.so.1 => /usr/lib/libc.so.1
/platform/SUNW,Netra-T12/lib/libc_psr.so.1@
So the main difference is the c++/c libs, I don't see anything else... Maybe a compiler/linker option? Lib version?
If someone have a working qmake version on Solaris 10 (solaris-cc not solaris-g++) can she/he send me the ldd log to compare it with my version?
Thank you for your help. -
A total shot in the dark here, but this seems eerily like a problem I recently had building "ROOT":http://root.cern.ch on Solaris 10 Sparc. It died in a string hashing function because it tried to cast an improperly aligned memory location to an integer. (It was walking through the underlying char[] 4 bytes at a type to perform the hash.) Sparc doesn't like this, and the result is a SIGBUS. It might be worth looking at QHash for alignment assumptions.