Issues building gcc natively on mipsel

Hello, I'm trying to build gcc-7.3.0 (md5 747d5010b7c6938b480bc6e4d7c4be9a of tar.gz) natively on a MACHTYPE=mipsel-unknown-linux-gnu MIPS p5600 machine under Debian Stretch. I'm getting an illegal instruction during libstdc++ build phase: libtool: compile: /home/gru/proj/gcc_build/./gcc/xgcc -s

Re: Relocation Truncated to Fit: R_X86_64_PC32

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 > > -mcmodel=large. I believe I understand the reasons. > > > > Sadly the error persists. Any advice? > > > > It look

Re: Relocation Truncated to Fit: R_X86_64_PC32

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 everything with -mcmodel=large (htt

Relocation Truncated to Fit: R_X86_64_PC32

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/lto

Re: c plugin guidance wanted

On Mon, 2018-07-30 at 10:51 -0400, David Malcolm wrote: > On Sun, 2018-07-29 at 13:41 -0700, Joe Perches wrote: > > I would like to implement a gcc plugin that can compress an > > __attribute__((format(printf, x, y))) const char array before > > storage so that the formats can be size reduced when

Re: That light at the end of the tunnel?

Michael Clark : > Can you not roll back to a version of reposurgeon used for the last > successful conversion? Assuming you know the date of the last successful > conversion, then you can use the reposurgeon version from that date. I don't remember the date of the last successful conversion. Nex

Re: [RFC] Adding Python as a possible language and it's usage

On Jul 30 2018, Joseph Myers wrote: > Python has been used for some glibc tests for some time. Using it for tests is ok, since they are not part of the bootstrap cycle. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9

Re: c plugin guidance wanted

On Sun, 2018-07-29 at 13:41 -0700, Joe Perches wrote: > I would like to implement a gcc plugin that can compress an > __attribute__((format(printf, x, y))) const char array before > storage so that the formats can be size reduced when stored and > expanded appropriately before use. > > As this is

Re: [RFC] Adding Python as a possible language and it's usage

On Sat, 28 Jul 2018, Ramana Radhakrishnan wrote: > > Obviously if you're bootstrapping core packages and their build > > dependencies, use in glibc is more or less equivalent to use in GCC. (But > > if build dependencies include those involved in testing, you already have > > python as one for gl

Re: [RFC] Adding Python as a possible language and it's usage

On Fri, 27 Jul 2018, Paul Smith wrote: > If Perl is already in the bootstrap set and the awk scripts are hard to > maintain then why can't the awk scripts be rewritten in Perl instead of > Python? That would avoid adding more prerequisites and surely Perl is > sufficiently expressive that it can

Re: That light at the end of the tunnel?

Joseph Myers : > On Mon, 23 Jul 2018, Richard Earnshaw (lists) wrote: > > > So traditional git bisect is inherently serial, but we can be more > > creative here, surely. A single run halves the search space each time. > > But three machines working together can split it into 4 each run, 7 > > mac

Re: That light at the end of the tunnel?

> On 31/07/2018, at 12:47 AM, Eric S. Raymond wrote: > > Richard Biener : >> Ok, so let me ask whether you can currently convert trunk and >> gcc-{6,7,8}-branch >> successfully, ignoring "merges" into them (shouldn't have happened). All >> other >> branches can in theory be converted later i

Re: That light at the end of the tunnel?

Richard Biener : > Ok, so let me ask whether you can currently convert trunk and > gcc-{6,7,8}-branch > successfully, ignoring "merges" into them (shouldn't have happened). All > other > branches can in theory be converted later if required, right? Trunk conversionm is currently broken. That's

Re: That light at the end of the tunnel?

David Edelsohn : > I realize that reverting the change would cause another regression. > My suggestion is that the bisection of reposurgeon may be easier / > faster and could help you pinpoint the root cause. Then you could > consider a different solution to the problem that you were trying to > f