d reason to remove them. Please
allow GCJ to continue to exist in the GCC and provide what little
maintenance it may require. It is entirely possible the frontend may
experience renewed interest in the future.
Respectfully,
R0b0t1
io and
associated utilities. At some point I believe the decision to support
superior software needs to be made regardless of its adoption amongst
other projects, and that one of the factors to consider is the
readability and maintainability of that software as viewed from
outside of its project.
If it does not seem wise to adopt a new compression format now, I
would recommend reconsidering the issue after some time, perhaps a
year or two.
R0b0t1.
page for their web portal and an administrator followed up with a
friendly question.
Inasmuch as the issue needs to be discussed, that is what I can think
of that might be relevant.
R0b0t1.
P.S. David, not that I mind everyone knowing of my interest, but I
didn't reply publicly. This li
I have checked a few of the mirrors listed on
https://gcc.gnu.org/mirrors.html. That page lists a few keys that
releases might be signed by, but on all of the mirrors I checked I do
not actually see any signed files. What am I missing?
Thanks in advance,
R0b0t1.
if I
should have continued it.
R0b0t1.
On Wed, Aug 16, 2017 at 3:53 PM, R0b0t1 wrote:
> Hello,
>
> I have no problem working GnuPG. However, files on ftp://ftp.gnu.org
> are signed by individuals, at least for the projects I am interested
> in (binutils, gcc, gdb). Where might I find a GNU's endorsement of the
>
verification
schemes.
Respectfully,
R0b0t1.
d GCC but I will
need more time if it is even possible. If work stopped on it I would
be left without a trustworthy compiler. A person of my modest position
and stature does not deserve to use such a capable piece of software.
R0b0t1.
advance,
R0b0t1.
On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote:
> When compiling libssp, ssp.c, function __guard_setup:
> O_RDONLY is undeclared (ssp.c:93:34),
> ssize_t is an unknown type name (ssp.c:96:7), and
> size_t is an unknown type name (ssp.c:113:25).
>
> ../../src/gcc-7.2.0/configur
On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin wrote:
> On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
>> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote:
>> > When compiling libssp, ssp.c, function __guard_setup:
>> > O_RDONLY is undeclared (ssp.c:93:34),
>>
entation of this software?
Full disclosure: despite my interest in the architecture I have not
been able to get access to a POWER8 machine. A server costs about as
much as a new car. Any account reseller recommendations or any other
options you can think of? If you don't mind responding feel free to do
it privately so it doesn't clutter this thread.
Cheers,
R0b0t1.
On Thu, Sep 7, 2017 at 1:10 AM, Jeffrey Walton wrote:
> On Thu, Sep 7, 2017 at 1:39 AM, R0b0t1 wrote:
>> On Wed, Sep 6, 2017 at 11:37 PM, Jeffrey Walton wrote:
>>> Hi Everyone,
>>>
>>> I'm on gcc rather than gcc-help because we need to talk with some GC
Hello list, has anyone experienced problems on the AIX POWER8 system?
-- Forwarded message --
From: R0b0t1
Date: Sun, Sep 10, 2017 at 9:58 AM
Subject: Re: [cfarm-admins] Extremely Slow Disk Access On GCC119
To: David Edelsohn
Do you care to explain? I'm not trying to tel
ystem. I'm
currently fixing a lot of ppc64(le) issues, but I did get an
environment working on GCC10.
Respectfully,
R0b0t1
>
>
> On Sunday, 10 September 2017, R0b0t1 wrote:
>>
>> Hello list, has anyone experienced problems on the AIX POWER8 system?
>>
>&g
Thank you for the reply!
On Sun, Sep 10, 2017 at 2:49 PM, David Edelsohn wrote:
> On Sun, Sep 10, 2017 at 9:08 PM, R0b0t1 wrote:
>> On Sun, Sep 10, 2017 at 1:06 PM, Jonathan Wakely
>> wrote:
>>> Yes, the disks are very slow. You just have to live with it.
>>>
pe) that I am extremely privileged to use the
machines that make up the GCC CF. Hopefully my surprise at the results
of running the commands I did seems reasonable.
In any case, my computations on that machine are proceeding now; at
least as well as they can.
Respectfully,
R0b0t1
widely
> deployed and used for many projects. LLVM utilizes a Buildbot
> cluster.
>
I would like to verify that Buildbot is reliable. I worked with a
(small) project that was using it for their builds. In my opinion
Buildbot is more approachable and easier to customize. The only
complaint I have (that applies to a few other Python projects as well,
like Scons) is that configuration is actually a script file that uses
Python syntax. In some cases this can be odd.
As to its supporting technology, Python's developers see their project
as a serious work that provides infrastructure for others. A lot of
Python projects inherit this mindset and are very stable.
I think Java-based infrastructure is starting to be underestimated and
that Jenkins is a good candidate, but someone appears to have already
done the work.
Respectfully,
R0b0t1
that it may depend on being used for the toolchain?
Ideally these toolchains would not use system libraries if CHOST is
the same as BHOST.
3) Are there any architecture specific options for any of the possible targets?
Is there anything else I should be aware of?
Respectfully,
R0b0t1
On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely wrote:
> On 26 September 2017 at 22:05, R0b0t1 wrote:
>> Hello,
>>
>> I am having problems understanding the build instructions for GCC. I
>> can almost always produce toolchains which function but I can find
>>
On Wed, Sep 27, 2017 at 12:34 AM, Jonathan Wakely wrote:
> On 27 September 2017 at 05:49, R0b0t1 wrote:
>> On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely
>> wrote:
>>> On 26 September 2017 at 22:05, R0b0t1 wrote:
>>>> Hello,
>>>>
&
On Wed, Sep 27, 2017 at 12:34 AM, Jonathan Wakely wrote:
> On 27 September 2017 at 05:49, R0b0t1 wrote:
>> On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely
>> wrote:
>>> On 26 September 2017 at 22:05, R0b0t1 wrote:
>>>> Hello,
>>>>
&
arted trying to do something very
simple. Now I am here, because this is the most direct way to
accomplish what I was trying to do. When I type most questions I have
into Google I get no results, and when I ask them I receive no
responses.
I can not remember what I was originally trying to do.
Respectfully,
R0b0t1
On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore
wrote:
> On 09/26/2017 03:05 PM, R0b0t1 wrote:
>>
>> Hello,
>>
>> I am having problems understanding the build instructions for GCC. I
>> can almost always produce toolchains which function but I can find
>&g
On Tue, Oct 3, 2017 at 6:22 PM, Sandra Loosemore
wrote:
> On 10/03/2017 03:27 PM, R0b0t1 wrote:
>>
>> On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore
>> mailto:san...@codesourcery.com>> wrote:
>
>
> [snip]
>
> FAOD, R0b0t1 forwarded mail I deliberately s
On Wed, Oct 4, 2017 at 3:33 AM, David Brown wrote:
>
> R0b0t1, you might not realise this but CodeSoucery is a major
> contributor to gcc and other gnu tools. Individuals and companies pay
> them for their services - to put together tested, qualified and
> documented bundles of de
On Wed, Oct 4, 2017 at 5:34 AM, Jonathan Wakely wrote:
> On 3 October 2017 at 22:27, R0b0t1 wrote:
>> I decline to do your company's market research for them. They could choose
>> to pay me, of course. Based on the failures I am experiencing I doubt that
>> your co
not know how to fix extant problems. Something
that seems reasonable to me is that new features are documented but
also indexed based on usage. Some people do not like this suggestion,
and I understand.
On Thu, Oct 5, 2017 at 3:17 PM, R0b0t1 wrote:
> On Wed, Oct 4, 2017 at 5:34 AM, Jonathan Wa
it seemed to me that most
operations should be done on the GIMPLE representation as it contains
the most information. Is there any reason you gravitated towards RTL?
I apologize for the minor diversion of topicality.
Cheers,
R0b0t1
On Thu, Oct 19, 2017 at 8:46 AM, Geoff Wozniak wrote:
> R0b0t1 writes:
>>
>> When I first looked at the GCC codebase, it seemed to me that most
>> operations should be done on the GIMPLE representation as it contains the
>> most information. Is there any reason
appropriate.
Cheers,
R0b0t1
for a solution, but they were all more or
less "disable libssp."
Thanks in advance,
R0b0t1
On Sun, Feb 18, 2018 at 1:42 AM, R0b0t1 wrote:
> Taking inspiration from
> https://github.com/FreddieChopin/bleeding-edge-toolchain, I have a
> script which runs:
>
> ../../source/${dname}/configure \
> --target=${TARGET} \
> --enable-languages=c \
>
lpath ../../${DIR_PREFIX}/host/${isl_dname}` \
--with-pkgversion=${VERSION} \
--with-multilib-list=rmprofile
# If this is the top-level multilib, build all the other
# multilibs.
/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/xgcc
-B/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/
-B/home/R
On Thu, Feb 22, 2018 at 8:44 AM, R0b0t1 wrote:
> Would any other information be helpful? All results called for the
> installation of binary packages, which is not possible (I don't use
> apt).
>
>
> ../../source/${dname}/configure \
> --target=${TARGET} \
&g
Hello list,
I have been told to solve this error I should pass -fPIC and
-mcmodel=large. I believe I understand the reasons.
Sadly the error persists. Any advice?
Thanks in advance,
R0b0t1
---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.3.0
On Mon, Jul 30, 2018 at 4:32 PM, R0b0t1 wrote:
> Hello list,
>
> I have been told to solve this error I should pass -fPIC and
> -mcmodel=large. I believe I understand the reasons.
>
> Sadly the error persists. Any advice?
>
It looks like I may have to recompile everythin
On Mon, Jul 30, 2018 at 6:28 PM, Jonathan Wakely wrote:
> On Mon, 30 Jul 2018 at 22:53, R0b0t1 wrote:
>>
>> On Mon, Jul 30, 2018 at 4:32 PM, R0b0t1 wrote:
>> > Hello list,
>> >
>> > I have been told to solve this error I should pass -fPIC and
>&
38 matches
Mail list logo
