volatile bools work, but just know that every time you check it you are
doing a non-cached memory read (relatively slow). It can't read from the
cache/registers (much faster) because other threads/processes are allowed
to modify it at any time (and when they do, they don't/can't modify the
cached/i
On segunda-feira, 22 de outubro de 2012 13.57.36, Lincoln Ramsay wrote:
> Though, I'm not sure we need QT_SELECT. If you can change an environment
> variable, you can modify PATH.
Changing one variable to a specific value is considerably easier than changing
PATH.
> > Additionally, this tool may
Serves me right for not reading _all_ the mail in this folder before
replying to an old thread...
On 20/10/12 09:16, Thiago Macieira wrote:
> a) under most circumstances, it will simply find another qmake and pass
> through all arguments. That is:
> qmake -project
> basically
On Oct 21, 2012 8:24 PM, "Joseph Crowell"
wrote:
> You propose that since zero day happens no matter what, we conveniently
make a zero day site ourselves so that the script kiddies don't have to do
it themselves.
>>
did you mean to respond only to me?
Which do you fear more?
-A script kiddie wit
On 20/10/12 07:35, Thiago Macieira wrote:
> Really, I don't care what qmake5 is and where it points to, so long as:
> a) it exists
> b) it works
> c) it's the official and documented way of creating Qt applications in Qt 5
>
> Any other names are under the customer's taste.
Surely then the v
On Fri, 19 Oct 2012, Thomas Senyk wrote:
On Fri, October 19, 2012 09:14:39 AM Chris Adams wrote:
On Fri, Oct 19, 2012 at 2:06 AM, Jon Trulson wrote:
On Tue, 16 Oct 2012, Thiago Macieira wrote:
On terça-feira, 16 de outubro de 2012 15.25.40, Jon Trulson wrote:
However, compiling qtwayland fa
>
> http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf
>
Interesting article, but it tells us nothing. They merely talk about
Full vs. Responsible Disclosure, and they admit that it's an ongoing
debate. The overall conclusion after 12 pages in the article: "the
disclosure of
On domingo, 21 de outubro de 2012 18.32.44, Geoffrey Gowey wrote:
> dialogs/qfiledialog.cpp", line 897: Error: Too few arguments in call to
> "getpwnam_r(const char*, passwd*, char*, int, passwd**)".
> "
#if defined(Q_OS_SOLARIS) && (_POSIX_C_SOURCE - 0 < 199506L)
tmpPw = getpwnam_r(userNa
/home/gjgowey/qt/bin/moc -DQT_SHARED -DQT_BUILD_GUI_LIB
-DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
-DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_NO_OPENTYPE
-DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP
-DQT_NO_STYLE_WINDOWSCE -DQT_NO_
On domingo, 21 de outubro de 2012 16.18.18, Geoffrey Gowey wrote:
> I'm still running in to trouble compiling Qt. Here's the latest error that
> I'm getting:
The error is in qatomic_x86_64.h.
This error has been fixed several times for other architectures. It's a matter
of missing "const" in a
On domingo, 21 de outubro de 2012 15.30.29, Geoffrey Gowey wrote:
> Ok. I see what happened. I reverted the changes that I made previously so
> that I could pull down the latest version unaware that the changes weren't
> incorporated in to the latest source.
Did you submit them to Gerrit?
--
Th
Hello All,
I'm still running in to trouble compiling Qt. Here's the latest error that
I'm getting:
/opt/solarisstudio12.3/bin/CC -c -m64 -native -xjobs=8 -xopenmp
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -O -mt -KPIC
-DQT_SHARED -DQT_BUILD_DBUS_LIB -DDBUS_API_SUBJECT_TO_CHANGE
-DQT_N
On Sunday, October 21, 2012 10:51:12 Thiago Macieira wrote:
> > All correct? Did I miss anything?
>
> More or less. I was thinking it might work if it's inside the qtbase
> sources.
> If distros are going to provide Qt 5, they need to compile qtbase
> anyway. The only thing we need is to provide
If anyone is looking for a guinea pig/helper with Solaris development I'm
game.
On Sun, Oct 21, 2012 at 12:35 PM, Thiago Macieira wrote:
> On domingo, 21 de outubro de 2012 12.10.35, Geoffrey Gowey wrote:
> >
> "../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h",
> > line
Ok. I see what happened. I reverted the changes that I made previously so
that I could pull down the latest version unaware that the changes weren't
incorporated in to the latest source.
On Sun, Oct 21, 2012 at 2:58 PM, Thiago Macieira
wrote:
> On domingo, 21 de outubro de 2012 14.38.31, Geoffr
On domingo, 21 de outubro de 2012 14.38.31, Geoffrey Gowey wrote:
> Yes and no. The error is being generated from a declaration in
> "../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h"
>
> In this regard you are correct,
>
> However, the .c files differ. kernel/qnetworki
Yes and no. The error is being generated from a declaration in
"../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h"
In this regard you are correct,
However, the .c files differ. kernel/qnetworkinterface_unix.cpp vs.
socket/qhttpsocketengine.cpp
On Sun, Oct 21, 2012 at 1:
On domingo, 21 de outubro de 2012 12.53.39, Geoffrey Gowey wrote:
> No. The error from a month ago was:
> "../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h",
> line 126: Error: Formal argument 3 of type unsigned* in call to accept(int,
> sockaddr*, unsigned*) is being pas
On domingo, 21 de outubro de 2012 19.06.32, Stephen Kelly wrote:
> I see.
>
> If such a wrapper exists, then:
>
> * It will need to be in a separate package from the Qt 4 and Qt 5 repos
> * It needs to be maintained and released on its own cycle as needed
> ** Supported features of conf files
On Sunday, October 21, 2012 09:32:33 Thiago Macieira wrote:
> On domingo, 21 de outubro de 2012 18.06.46, Stephen Kelly wrote:
> > > The packagers have to change the only Qt4 qmake's name/path and
> >
> > The whole point of this proposal used to be to make it not necessary for
> > distros to patch
On 10/20/2012 2:04 AM, d3fault wrote:
> Are you willing to put the security of your operations in the hands of
> all the wives and children who might have access to their dad's
> computer (he being a member of that trusted network of analysts)?
> Humans can be bought/persuaded/compromised/etc with
No. The error from a month ago was:
/opt/solarisstudio12.3/bin/CC -c -O2 -mt -KPIC -DQT_SHARED
-DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE
-D_L
On domingo, 21 de outubro de 2012 12.10.35, Geoffrey Gowey wrote:
> "../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h",
> line 126: Error: Formal argument 3 of type unsigned* in call to accept(int,
> sockaddr*, unsigned*) is being passed int*.
I think this was reported bef
Hi Joerg,
On Oct 21, 2012, at 5:48 PM, Bornemann Joerg wrote:
> Hi Thiago,
>
>>> This *is* the problem of Linux distributions. FHS doesn't cover this
>>> problem properly and this is the point where it should be fixed.
>>> You're making life harder for every platform - not only Linux - by
>
On domingo, 21 de outubro de 2012 18.06.46, Stephen Kelly wrote:
> > The packagers have to change the only Qt4 qmake's name/path and
>
> The whole point of this proposal used to be to make it not necessary for
> distros to patch Qt.
>
> This proposal as you state is requires everyone to patch Q
On 21 October 2012 17:10, Geoffrey Gowey wrote:
> Hello All,
>
> I tried compiling last night and ran in to the following error:
>
> /opt/solarisstudio12.3/bin/CC -c -g -O2 -mt -KPIC -DQT_SHARED
> -DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNINGS -DQT3
On Sunday, October 21, 2012 09:45:57 you wrote:
> On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió:
> [snip]
>
> > I get the impression that most people developing against Qt, even on
> > Linux,
> > are using the SDK.
>
> Well, my impression is exactly the contrary: most people developing against
Hello All,
I tried compiling last night and ran in to the following error:
/opt/solarisstudio12.3/bin/CC -c -g -O2 -mt -KPIC -DQT_SHARED
-DQT_BUILD_NETWORK_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_NO_DEBU
On Sunday, October 21, 2012 12:56:05 Konstantin Ritt wrote:
> >> > Why not use a tool of a new name? Why overload the meaning and
> >> > responsiblity of qmake?
> >
> >
> > If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is
> > today at /usr/bin/qmake, packagers have to ch
Hi Thiago,
> >This *is* the problem of Linux distributions. FHS doesn't cover this
> > problem properly and this is the point where it should be fixed.
> >You're making life harder for every platform - not only Linux - by
> > fixing their problem.
>
> You may argue that case, but they'll
On Sun, Oct 21, 2012 at 2:45 PM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:
> Well, my impression is exactly the contrary: most people developing
> against Qt
> just install the development packages.
>
> In fact, I have never met someone who installed the SDK when [s]he ca
On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió:
[snip]
> I get the impression that most people developing against Qt, even on Linux,
> are using the SDK.
Well, my impression is exactly the contrary: most people developing against Qt
just install the development packages.
In fact, I have nev
>> > Why not use a tool of a new name? Why overload the meaning and
>> > responsiblity of qmake?
>
> If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is
> today at /usr/bin/qmake, packagers have to change everything in their Qt 4
> packages or they will conflict and not be c
On Saturday, October 20, 2012 09:10:05 Thiago Macieira wrote:
> On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote:
> > On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> > > On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> > > [...]
> > >
> > > > 3) In addition, we'll cre
On Fri, Oct 19, 2012 at 11:19:40AM -0700, d3fault wrote:
> Mathematical Truth:
>
> It is better:
> To be vulnerable and know it (so you can shut down your machine or
> unplug dat ethernet cable).
most secure == always off. But that is probably not practical. But then
again security is not a state
35 matches
Mail list logo
