On Wed, Jun 19, 2019 at 12:37:11PM -0600, Ross Zwisler wrote:
> On Sun, Jun 9, 2019 at 1:00 PM Johannes Hirte
> wrote:
> > On 2019 Jun 09, Klaus Kusche wrote:
> > > Hello,
> > >
> > > Same problem for linux 5.1.7:
> > > Kernel building fails with the same relocation error.
> > >
> > > 5.1.5 does
On Sun, Jun 9, 2019 at 1:00 PM Johannes Hirte
wrote:
> On 2019 Jun 09, Klaus Kusche wrote:
> > Hello,
> >
> > Same problem for linux 5.1.7:
> > Kernel building fails with the same relocation error.
> >
> > 5.1.5 does not have the problem, builds fine for me.
> >
> > Is there anything I can do to
On 2019 Jun 09, Klaus Kusche wrote:
>
> Hello,
>
> Same problem for linux 5.1.7:
> Kernel building fails with the same relocation error.
>
> 5.1.5 does not have the problem, builds fine for me.
>
> Is there anything I can do to investigate the problem?
>
Please try linux 5.1.8. The
Hello,
Same problem for linux 5.1.7:
Kernel building fails with the same relocation error.
5.1.5 does not have the problem, builds fine for me.
Is there anything I can do to investigate the problem?
--
Prof. Dr. Klaus Kusche
Private address: Rosenberg 41, 07546 Gera, Germany
+49 365
On Wed, Jun 05, 2019 at 11:16:06AM -0700, Kees Cook wrote:
> On Wed, Jun 05, 2019 at 11:08:13AM -0500, Alec Ari wrote:
> > I'm having this problem too, build is failing:
> >
> > Invalid absolute R_X86_64_32S relocation: _etext
> >
> > I stayed on the 4.14 branch to help prevent these kind of
On Wed, Jun 05, 2019 at 11:08:13AM -0500, Alec Ari wrote:
> I'm having this problem too, build is failing:
>
> Invalid absolute R_X86_64_32S relocation: _etext
>
> I stayed on the 4.14 branch to help prevent these kind of breakages,
> so much for that idea. Gentoo GCC 8.3.0.
It seems to be a
Hi,
I'm having this problem too, build is failing:
Invalid absolute R_X86_64_32S relocation: _etext
I stayed on the 4.14 branch to help prevent these kind of breakages,
so much for that idea. Gentoo GCC 8.3.0.
Alec
Hello,
same problem here.
gcc version 9.1.0 (Gentoo 9.1.0 p1.0)
linux-5.1.6
RELOCS arch/x86/boot/compressed/vmlinux.relocs
Invalid absolute R_X86_64_32S relocation: _etext
make[2]: *** [arch/x86/boot/compressed/Makefile:130:
arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[2]: ***
On Thu, May 16, 2019 at 03:56:07PM +0200, Johannes Hirte wrote:
> On 2019 Mai 15, Kees Cook wrote:
> > Various stupid questions: did you wipe the whole bulid tree and start
> > clean?
>
> No I didn't. And this fixed it now. After a distclean I'm unable to
> reproduce it. So sorry for the noise.
On 2019 Mai 15, Kees Cook wrote:
> On Tue, May 14, 2019 at 06:10:55PM +0200, Johannes Hirte wrote:
> > On 2019 Mai 14, Kees Cook wrote:
> > > On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > > > This breaks the build on my system:
> > > >
> > > > RELOCS
On Tue, May 14, 2019 at 06:10:55PM +0200, Johannes Hirte wrote:
> On 2019 Mai 14, Kees Cook wrote:
> > On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > > This breaks the build on my system:
> > >
> > > RELOCS arch/x86/boot/compressed/vmlinux.relocs
> > > CC
On 2019 Mai 14, Kees Cook wrote:
> On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > On 2019 Apr 23, Kees Cook wrote:
> > > When building x86 with Clang LTO and CFI, CFI jump regions are
> > > automatically added to the end of the .text section late in linking. As a
> > > result,
On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> On 2019 Apr 23, Kees Cook wrote:
> > When building x86 with Clang LTO and CFI, CFI jump regions are
> > automatically added to the end of the .text section late in linking. As a
> > result, the _etext position was being labelled
On 2019 Apr 23, Kees Cook wrote:
> When building x86 with Clang LTO and CFI, CFI jump regions are
> automatically added to the end of the .text section late in linking. As a
> result, the _etext position was being labelled before the appended jump
> regions, causing confusion about where the
When building x86 with Clang LTO and CFI, CFI jump regions are
automatically added to the end of the .text section late in linking. As a
result, the _etext position was being labelled before the appended jump
regions, causing confusion about where the boundaries of the executable
region actually
15 matches
Mail list logo