On 22/02/2011, calvin morrison <mutantturkey@...> wrote:
> On 22/02/2011, calvin morrison <mutantturkey@...> wrote:
>> On 22/02/2011, David C. Rankin <drankinatty@...> wrote:
>>> On 02/22/2011 05:49 PM, calvin morrison wrote:
>>>> I do have qt4 installed (hmm you seem to have mentioned that before)
>>>> BUT that shouldn't interfere with it afaik.
>>>>
>>>
>>> Oh yes it will :(
>>>
>>>   There are several problems, see thread:
>>>
>>> [trinity-users] kdebase make failure if Qt4 installed, QtCore/qfile.h
>>> QT_BEGIN_HEADER doesn't name type
>>>
>>> There are 2 big ones, cmake will not ignore Qt4 uic and end up trying to
>>> use
>>> it
>>> instead of uic from trinity. (you can try and trick it by putting
>>> /opt/qt/bin:/opt/trinity/bin/ before /usr in your path, but that is a
>>> risky
>>> hack.
>>>
>>> Then there is:
>>>
>>> <quote>
>>> If kde4/Qt4 is installed, cmake fails when it uses
>>> /usr/include/QtCore/qfile.h instead of /opt/qt/include/qfile.h.
>>>
>>> I cannot figure out how to tell cmake to ignore the /usr/include. I have
>>> tried
>>> the cmake arguments:
>>>
>>>   cmake ../ \
>>>     -DCMAKE_INSTALL_PREFIX=${trinity_prefix} \
>>>     -DWITH_QT3=ON \
>>>     -DQTDIR=/opt/qt \
>>>     -DBUILD_ALL=ON
>>> </quote>
>>>
>>> <reply>
>>> They are right, some KDE3 applications where no amount of
>>> configuration helps only build properly in a clean chroot, without the
>>> KDE4 stuff around.
>>>
>>> https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
>>>
>>> </reply>
>>>
>>> So even though you can *INSTALL* Trinity next to kde4, that doesn't mean
>>> you
>>> can
>>> *BUILD* Trinity next to kde4 :) Same goes for Qt4. If you are building
>>> trinity
>>> based on Qt3, just because you can *INSTALL* a Qt3 based Trinity on a
>>> system
>>> with Qt4 present, it doesn't mean you can *BUILD* a Qt3 based Trinity
>>> with
>>> Qt4
>>> present :)
>>>
>>> The PKGBUILD files are correct, but they don't work magic :p
>>>
>>> Set up a clean build environment in VirtualBox. Alocate  ~15G to the
>>> install,
>>> (you could probably get away with 8G total). For a 15G VM allocate 5G
>>> '/',
>>> 120M
>>> '/boot', the rest '/home'. The basic Arch install takes ~ 10 minutes to
>>> install
>>> base and base-devel packages and all you have to do is hit 'return' and
>>> the
>>> Arch
>>> defaults for partitioning, etc. are fine.
>>>
>>> Then what I did was just to setup my existing /home/david dir as a
>>> shared
>>> folder
>>> in VirtualBox to provide access to all my files and provide a place to
>>> save
>>> finished packages so they exist outside the VM. Then in the VirtualBox
>>> guest
>>> install of Arch, just create your /home/calvin/builds, set the paths for
>>> the
>>> bldtrinsvn-all.sh to use that as your builds dir and point the srcdir
>>> and
>>> pkgdir
>>> path to the shared folder on your original /home/calvin that you shared
>>> with
>>> your guest as something like 'hhome' (short for host home) and start
>>> building.
>>>
>>> No whacky kde4/kde3 lib conflicts and no Qt4/Qt3 header file conflicts.
>>>
>>> Some software just needs a clean build environment to build properly. It
>>> has
>>> nothing to do with running it, it just has to build without the presents
>>> of
>>> conflicting files.
>>>
>>> --
>>> David C. Rankin, J.D.,P.E.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> trinity-devel-unsubscribe@...
>>> For additional commands, e-mail:
>>> trinity-devel-help@...
>>> Read list messsages on the Web archive:
>>> http://trinity-devel.pearsoncomputing.net/
>>> Please remember not to top-post:
>>> http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
>>>
>>>
>>
>> It seems this is a case where we would need a make-conflict. but that
>> doesn't exist in PKGBUILDs arrays. Fogobogo suggest that we add it to
>> our make depends and require that (qt < 4).
>>
>> Can we resolve this issue another way?
>> Calvin
>>
>
> It seems also that we can ignore libs with cmake!
>
> http://www.mail-archive.com/cmake@.../msg09583.html
>
> /NODEFAULTLIB maybe the answer to the problem.
>
> I have yet to find how to use this (unfimiliar with cmake)
>
> Calvin
>

So I've worked out (sorry for triple posting) what the tentative solution is,

cmake documentation says:
CMAKE_EXE_LINKER_FLAGS: Linker flags used to create executables.
Flags used by the linker when creating an executable.

So all we have to do is set the flags right for ld to ignore the Qt4 libs.

ld has a option " -z nodefaultlib " once i figure out how this works,
all we have to do is add another export line for the
CMAKE_EXE_LINKER_FLAGS and that should fix the problem AFAIK.

Calvin