On 5/28/19 2:26 PM, Roberto Ragusa wrote:
On 5/28/19 1:57 AM, John Reiser wrote:
if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }
Such code is an abomination for lack of clarity.
Also, the preceding line
for (int x=
On 5/28/19 1:57 AM, John Reiser wrote:
if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }
Such code is an abomination for lack of clarity.
Also, the preceding line
for (int x=0,t=0; x
Isn't t forced into 0..6 by the t&
Hi John,
On Mon, May 27, 2019 16:57:18 -0700, John Reiser wrote:
> > https://github.com/vxl/vxl/issues/638
>
> Independent of that particular issue, it is hard to believe the claim
> "vxl: A multi-platform collection of C++ software libraries ...".
> They're not making a good-faith effort to be p
Dear Jerry,
On Mon, May 27, 2019 15:33:42 -0600, Jerry James wrote:
> On Mon, May 27, 2019 at 2:54 PM Jerry James wrote:
> > It looks like the first few errors, at least, were fixed the day after
> > the last release, in this commit:
> >
> > https://github.com/vxl/vxl/commit/c3fd27959f51e0469a7a
https://github.com/vxl/vxl/issues/638
Independent of that particular issue, it is hard to believe the claim
"vxl: A multi-platform collection of C++ software libraries ...".
They're not making a good-faith effort to be portable.
The first hint is that "-Werror" (turn all warnings into errors)
ha
On Mon, May 27, 2019 at 2:54 PM Jerry James wrote:
> It looks like the first few errors, at least, were fixed the day after
> the last release, in this commit:
>
> https://github.com/vxl/vxl/commit/c3fd27959f51e0469a7a6075e975f245ac306f3d
>
> You might try adding that as a patch and see if that is
On Mon, May 27, 2019 at 10:14 AM Ankur Sinha wrote:
> After spending quite a bit of time fixing VXL to build, I've now run
> into errors with it building on 32 bit arches.
>
> Unfortunately, I don't foresee myself having enough cycles in the near
> future to debug the C++ bits to see what's happen
Hi everyone,
After spending quite a bit of time fixing VXL to build, I've now run
into errors with it building on 32 bit arches.
Unfortunately, I don't foresee myself having enough cycles in the near
future to debug the C++ bits to see what's happening here, and while I
have filed a ticket upstre
On 13/03/2019 17:03, mcatanz...@gnome.org wrote:
On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek wrote:
calling methods on NULL pointers to objects etc.
Chromium probably does this (or, at least, did in the past). Removing
-fno-delete-null-pointer-checks could introduce Fedora-specific crash
On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek
wrote:
calling methods on NULL pointers to objects etc.
Chromium probably does this (or, at least, did in the past). Removing
-fno-delete-null-pointer-checks could introduce Fedora-specific crashes.
Michael
On Wed, Mar 13, 2019 at 12:49:35PM -0400, Tom Callaway wrote:
> The odd thing is that this compiler flag is hardcoded into the build by the
> upstream. I'm wondering why Fedora hits this when no one else seems to.
>
> I mean, I'm fine to disable it, because the Chromium codebase is a tomb of
> hor
The odd thing is that this compiler flag is hardcoded into the build by the
upstream. I'm wondering why Fedora hits this when no one else seems to.
I mean, I'm fine to disable it, because the Chromium codebase is a tomb of
horrors anyway, and if I have to sacrifice that flag to make it happy, so
b
On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote:
> I tried removing some of the compiler flags to see if I could identify what
> might be triggering this, and removing "-fno-delete-null-pointer-checks"
> seems to make this error vanish.
-fno-delete-null-pointer-checks is certainly an
I tried removing some of the compiler flags to see if I could identify what
might be triggering this, and removing "-fno-delete-null-pointer-checks"
seems to make this error vanish.
Not sure if that helps or not, but hopefully, I can get this beast building
without it.
Thanks,
Tom
On Mon, Mar 11
On Tue, Mar 12, 2019 at 7:57 AM Christophe de Dinechin
wrote:
>
> I tried to compile your preprocessed fragment with both clang or gcc.
> Interestingly:
>
> 1) Without your command-line options, I don’t see the same error.
>
> 2) With your command-line options, I see the error with gcc, but not w
> On 11 Mar 2019, at 18:16, Tom Callaway wrote:
>
> Hi folks,
>
> I spent some time this weekend trying to get Chromium 72 building on Fedora,
> but I kept running into a C++ issue that I was not able to resolve. This
> happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
>
FWIW, I did. There is no fix there.
~tom
On Mon, Mar 11, 2019 at 1:20 PM Vascom wrote:
> Look at chromium-vaapi build in rpmfusion.
>
> пн, 11 мар. 2019 г., 20:17 Tom Callaway :
>
>> Hi folks,
>>
>> I spent some time this weekend trying to get Chromium 72 building on
>> Fedora, but I kept runni
On Mon, Mar 11, 2019 at 01:16:07PM -0400, Tom Callaway wrote:
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Can you ple
Look at chromium-vaapi build in rpmfusion.
пн, 11 мар. 2019 г., 20:17 Tom Callaway :
> Hi folks,
>
> I spent some time this weekend trying to get Chromium 72 building on
> Fedora, but I kept running into a C++ issue that I was not able to resolve.
> This happened with gcc-9.0.1-0.8.fc30.x86_64 an
Hi folks,
I spent some time this weekend trying to get Chromium 72 building on
Fedora, but I kept running into a C++ issue that I was not able to resolve.
This happened with gcc-9.0.1-0.8.fc30.x86_64 and gcc-8.3.1-2.fc29.x86_64.
Here's a sample of the error (it happens in a few places), from Fedo
On 04/20/2010 12:09 PM, Bernd Stramm wrote:
> Can you give me a link? I'll take a look, see if there is anything I can
> do.
Just checkout xmms2 and esperanza from Fedora CVS, then build the
packages in the devel branch.
This will help if you're not familiar with Fedora CVS:
https://fedoraproject
On Tue, 2010-04-20 at 09:50 -0400, Tom "spot" Callaway wrote:
> Sadly, I am facing a task which exceeds my very meager C++ skills.
>
> I own a package called "esperanza", which is a QT4 xmms2 client written
> in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed
> to any branch, b
Sadly, I am facing a task which exceeds my very meager C++ skills.
I own a package called "esperanza", which is a QT4 xmms2 client written
in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed
to any branch, but checked into rawhide CVS), the esperanza client no
longer works (it b
23 matches
Mail list logo
