<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Copying a qt5 build to a different host machine]]></title><description><![CDATA[<p dir="auto">I have successfully cross-built qt5 for the Odroid C2 in a qt5-build directory on an Ubuntu x86-64 host machine. (Configured thus:</p>
<pre><code>-sysroot ~/Projects/Odroid/C2/sysroot 
-prefix /usr/local/qt5c2 
-hostprefix ~/Projects/Odroid/C2/Qt/qt5-build
</code></pre>
<p dir="auto">)<br />
This works fine, and I am able to build and deploy an application on the target device via Qt Creator. I want to enable another host machine (also Ubuntu x86-64) to facilitate development, and thought the process would be as simple as copying my qt5-build directory to the second host.</p>
<p dir="auto">To my surprise, this does not work at all, owing to hardcoded paths in various places. Per <a href="https://stackoverflow.com/a/7968705" target="_blank" rel="noopener noreferrer nofollow ugc">this</a> SO post I tried creating a qt.conf with</p>
<pre><code>[Paths]
Prefix = ./../
</code></pre>
<p dir="auto">With this, "qmake -query" does return the correct paths. However, QtCreator still barfs when I try to select this qmake as my desired Qt version.</p>
<p dir="auto">Then I tried "qmake -set" as suggested in another post in the same SO thread:</p>
<pre><code>$ ./qmake -set QT_HOST_PREFIX /opt/Qt/Odroid-C2/qt5-build
$ ./qmake -set QT_SYSROOT ~/Projects/Odroid/C2/sysroot
</code></pre>
<p dir="auto">(The paths here are correct for the new host machine I wish to enable).<br />
However, it still does not work in QtCreator.</p>
<p dir="auto">So: how does one copy/move a Qt build from one host machine to another? Surely it should not require rebuilding Qt from source on every host I'd like to enable. One workaround I can think of is to build on the original host with generic paths under /opt wherever path specification is required, and replicate that structure on all other hosts. But it just feels like there ought to be a real solution to this rather than workarounds.</p>
]]></description><link>https://forum.qt.io/topic/80244/copying-a-qt5-build-to-a-different-host-machine</link><generator>RSS for Node</generator><lastBuildDate>Wed, 23 Sep 2026 02:18:52 GMT</lastBuildDate><atom:link href="https://forum.qt.io/topic/80244.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 12 Jun 2017 13:45:42 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Copying a qt5 build to a different host machine on Wed, 14 Jun 2017 07:28:31 GMT]]></title><description><![CDATA[<p dir="auto">I have verified that preserving the same paths (in my case, /opt/Qt) on all hosts for the cross-compiled output, works fine.</p>
]]></description><link>https://forum.qt.io/post/399384</link><guid isPermaLink="true">https://forum.qt.io/post/399384</guid><dc:creator><![CDATA[vikramg]]></dc:creator><pubDate>Wed, 14 Jun 2017 07:28:31 GMT</pubDate></item><item><title><![CDATA[Reply to Copying a qt5 build to a different host machine on Tue, 13 Jun 2017 08:55:46 GMT]]></title><description><![CDATA[<p dir="auto">The official recommendation is not to copy the libs after building. The way Qt installers go around it is indeed by using qt.conf.</p>
<p dir="auto">I guess the easiest way is indeed to preserve the same paths in all machines. Not very convenient, but will work.</p>
]]></description><link>https://forum.qt.io/post/399162</link><guid isPermaLink="true">https://forum.qt.io/post/399162</guid><dc:creator><![CDATA[sierdzio]]></dc:creator><pubDate>Tue, 13 Jun 2017 08:55:46 GMT</pubDate></item></channel></rss>