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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.