On 6/25/19 11:51 AM, Alexandru Croitor wrote:
> If the stash file was in higher in the directory tree than you expected, it
> might have been due to this bug report
> https://bugreports.qt.io/browse/QTBUG-76140
>
> which should be fixed by
>
On Wednesday, 3 July 2019 18:09:36 -03 Matthew Woehlke wrote:
> Can't you make that depend on *the compiler*?
>
> .qmake.stash: /usr/bin/g++
>
> (I guess this wouldn't behave well with ccache, but oh well...)
And icecc.
And the actual compiler is /usr/lib64/gcc/x86_64-suse-linux/9/cc1plus.
On 26/06/2019 21.17, Thiago Macieira wrote:
> The whole reason the file exists is to avoid
> having to call the compiler to find out its details every time that qmake is
> started. In order to do what you are asking for, we need to call out to the
> compiler, which defeats the purpose.
Can't
On Wednesday, 3 July 2019 06:28:04 -03 Christian Kandeler wrote:
> On Tue, 2 Jul 2019 21:08:49 -0300
>
> Thiago Macieira wrote:
> > On Tuesday, 2 July 2019 16:41:30 -03 Patrick Stinson wrote:
> > > `rm -rf` on your build does not solve this issue because the
> > > .qmake.stash
> > > file often
On Tue, 2 Jul 2019 21:08:49 -0300
Thiago Macieira wrote:
> On Tuesday, 2 July 2019 16:41:30 -03 Patrick Stinson wrote:
> > `rm -rf` on your build does not solve this issue because the .qmake.stash
> > file often exists in a path above the build/source dir.
>
> That means you ran qmake there,
Aha! Very interesting. That does seem to make it a user-issue, albeit a very
convoluted issue.
> On Jul 2, 2019, at 4:08 PM, Thiago Macieira wrote:
>
> On Tuesday, 2 July 2019 16:41:30 -03 Patrick Stinson wrote:
>> `rm -rf` on your build does not solve this issue because the .qmake.stash
>>
On Tuesday, 2 July 2019 16:41:30 -03 Patrick Stinson wrote:
> `rm -rf` on your build does not solve this issue because the .qmake.stash
> file often exists in a path above the build/source dir.
That means you ran qmake there, which makes it a build dir.
You should remove your build dirs.
--
`rm -rf` on your build does not solve this issue because the .qmake.stash
file often exists in a path above the build/source dir.
On Wed, Jun 26, 2019 at 5:23 PM Thiago Macieira
wrote:
> On Wednesday, 26 June 2019 16:22:48 PDT Hamish Moffatt wrote:
> > My point was that the file is entirely
On Wednesday, 26 June 2019 16:22:48 PDT Hamish Moffatt wrote:
> My point was that the file is entirely managed by qmake, so (IMHO) qmake
> should deal with it if the data is now stale.
It's very difficult to do that. The whole reason the file exists is to avoid
having to call the compiler to
On 25/6/19 7:28 pm, Christian Kandeler wrote:
On Mon, 24 Jun 2019 23:25:38 +
Hamish Moffatt wrote:
On 25/6/19 8:46 am, Thiago Macieira wrote:
On Monday, 24 June 2019 08:24:25 PDT Thiago Macieira wrote:
Anyway, let's stop speculating. Until we can reliably reproduce this problem
to
Yep, it was a .qmake.stash file two dirs up. I deleted it and everything builds
fine again.
> On Jun 25, 2019, at 8:03 AM, Thiago Macieira
> wrote:
>
> On Tuesday, 25 June 2019 02:51:58 PDT Alexandru Croitor wrote:
>> If the stash file was in higher in the directory tree than you expected, it
On Tuesday, 25 June 2019 02:51:58 PDT Alexandru Croitor wrote:
> If the stash file was in higher in the directory tree than you expected, it
> might have been due to this bug report
> https://bugreports.qt.io/browse/QTBUG-76140
>
> which should be fixed by
>
> On 25. Jun 2019, at 00:46, Thiago Macieira wrote:
>
> On Monday, 24 June 2019 08:24:25 PDT Thiago Macieira wrote:
>> Anyway, let's stop speculating. Until we can reliably reproduce this problem
>> to understand what's going on, we're shooting in the dark.
>
> I managed to reproduce this
On Mon, 24 Jun 2019 23:25:38 +
Hamish Moffatt wrote:
> On 25/6/19 8:46 am, Thiago Macieira wrote:
> > On Monday, 24 June 2019 08:24:25 PDT Thiago Macieira wrote:
> >> Anyway, let's stop speculating. Until we can reliably reproduce this
> >> problem
> >> to understand what's going on, we're
On Monday, 24 June 2019 16:25:38 PDT Hamish Moffatt wrote:
> I also had problems with a stale SDK version in .qmake.stash when I
> first upgraded to Qt 5.12. https://bugreports.qt.io/browse/QTBUG-71620
>
> Despite this being entirely qmake's problem it was closed as invalid.
When you upgrade the
On 25/6/19 8:46 am, Thiago Macieira wrote:
On Monday, 24 June 2019 08:24:25 PDT Thiago Macieira wrote:
Anyway, let's stop speculating. Until we can reliably reproduce this problem
to understand what's going on, we're shooting in the dark.
I managed to reproduce this once. It was a left-over
On Monday, 24 June 2019 08:24:25 PDT Thiago Macieira wrote:
> Anyway, let's stop speculating. Until we can reliably reproduce this problem
> to understand what's going on, we're shooting in the dark.
I managed to reproduce this once. It was a left-over .qmake.stash file up in
the directory tree
On Sunday, 23 June 2019 22:23:56 PDT Patrick Stinson wrote:
> The qt configure script is predictably unable to find it on the first
> configure run but able to find it on the second run. The ask handy changed.
> Or were you considering that as well?
The configure script runs the compiler. If the
The qt configure script is predictably unable to find it on the first configure
run but able to find it on the second run. The ask handy changed. Or were you
considering that as well?
> On Jun 23, 2019, at 9:07 PM, Thiago Macieira
> wrote:
>
>> On Sunday, 23 June 2019 13:23:04 PDT Patrick
On Sunday, 23 June 2019 13:23:04 PDT Patrick Stinson wrote:
> Hmm, what indicates to you that it is a compiler problem? It seems to me
> that the fact that it (predictably) works unpredictably depending on the
> state of the Qt conf/build system points more strongly to the problem being
> in Qt
Hmm, what indicates to you that it is a compiler problem? It seems to me that
the fact that it (predictably) works unpredictably depending on the state of
the Qt conf/build system points more strongly to the problem being in Qt the Qt
conf/build system.
> On Jun 23, 2019, at 7:59 AM, Thiago
Wow. Very strange. Maybe I should file a bug report, though I bet it will be
very low priority.
> On Jun 22, 2019, at 8:07 AM, Thiago Macieira
> wrote:
>
>> On Friday, 21 June 2019 21:50:39 PDT Patrick Stinson wrote:
>> So how do you account for that? Seems very odd to me. This was from a
>>
I am building qt from a couple of different scripts so it would be great to be
able to have them work on first run.
> On Jun 21, 2019, at 8:50 PM, Patrick Stinson wrote:
>
> My config.log did not contain the string “std-atomic64.” It did report that
> it could not find libatomic. Deleting
On Friday, 21 June 2019 10:35:36 PDT Patrick Stinson wrote:
> #define QT_FEATURE_std_atomic64 -1
Can you check the config.log in the top-level dir to see what how the std-
atomic64 test failed? If you don't see that in the config.log, remove
config.cache and rerun configure (./config.status)
--
Every time I had this error recently it's because I cleaned my build
directory via rm -rf * which did not remove the hidden .qmake.cache files
in there which then thoroughly destroys any attemptto rebuild qt in this
directory.
Maybe it can help ? (it was the exact same symptoms in any case)
Best,
#define QT_FEATURE_std_atomic64 -1
> On Jun 21, 2019, at 9:32 AM, Thiago Macieira
> wrote:
>
> src/corelib/qtcore-config.h
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
On Friday, 21 June 2019 10:00:45 PDT Patrick Stinson wrote:
> thread/qatomic.cpp:1624:4: error: "Q_ATOMIC_INT64_IS_SUPPORTED must be
> defined on a 64-bit platform"
The macro is defined by this block in qatomic_cxx11.h:
#if QT_CONFIG(std_atomic64)
template<> struct QAtomicOpsSupport<8> { enum {
(NOTE: I have started a new thread about this from an old one incorrectly
associating this problem with “make -jn”)
I am having a hard time pinning down the source of this error. I am getting it
sporadically on Qt-5.12.0 - Qt-5.13.0. using make -jn flags or not using make
-jn flags doesn’t
28 matches
Mail list logo
