hash table entries to 64bit on s390x.
However the *GNU* hash tables entries are always 32bit.
The "bucket" pointer is shared between both hash algorithms.
--
On s390x the GNU algorithm assigns and dereferences this pointer to a
64bit value as a pointer to a 32bit value, leading to compiler
table entries to 64bit on s390x.
> > However the *GNU* hash tables entries are always 32bit.
> > The "bucket" pointer is shared between both hash algorithms.
> --
> > On s390x the GNU algorithm assigns and dereferences this pointer to a
> > 64bit value as a pointer to
On Mon, Feb 17, 2025 at 02:04:18PM +0100, Thomas Weißschuh wrote:
> Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for
> s390x")
> changed the type of the ELF hash table entries to 64bit on s390x.
> However the *GNU* hash tables entries are alway
Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
changed the type of the ELF hash table entries to 64bit on s390x.
However the *GNU* hash tables entries are always 32bit.
The "bucket" pointer is shared between both hash algorithms.
On s390x the G
On Thu, Feb 13, 2025 at 01:47:26PM +0100, Jens Remus wrote:
> On 13.02.2025 10:41, Thomas Weißschuh wrote:
> > Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for
> > s390x")
> > changed the type of the ELF hash table entries to 64bit on s3
On 13.02.2025 10:41, Thomas Weißschuh wrote:
Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
changed the type of the ELF hash table entries to 64bit on s390x.
However the *GNU* hash tables entries are always 32bit.
The "bucket" pointer is shar
Commit 14be4e6f3522 ("selftests: vDSO: fix ELF hash table entry size for s390x")
changed the type of the ELF hash table entries to 64bit on s390x.
However the *GNU* hash tables entries are always 32bit.
The "bucket" pointer is shared between both hash algorithms.
On s390x the G
Some kernel elf files have various notes that also happen to have an elf
note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
"GNU". For example, this note trips up the existing logic:
Owner Data size Description
Xen0x0008 Unkno
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
On Fri, Apr 16, 2021 at 08:45:04PM +0530, Naresh Kamboju wrote:
> The arm64 allnoconfig build failed on linux -next tag 20210416
> fpsimd.c:(.text+0x144): undefined reference to `sve_load_state'
> aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `fpsimd_save'
The arm64 allnoconfig build failed on linux -next tag 20210416
kernel/sched/fair.c:8428:13: warning: 'update_nohz_stats' defined but
not used [-Wunused-function]
static bool update_nohz_stats(struct rq *rq)
^
aarch64-linux-gnu-ld: Unexpected GOT/PLT entrie
On Fri 2021-04-09 18:52:48, Stephen Boyd wrote:
> Some kernel elf files have various notes that also happen to have an elf
> note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
> "GNU". For example, this note trips up the existing logic:
&g
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
Some kernel elf files have various notes that also happen to have an elf
note type of '3', which matches NT_GNU_BUILD_ID but the note name isn't
"GNU". For example, this note trips up the existing logic:
Owner Data size Description
Xen0x0008 Unkno
/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be2881824ae9eb92a35b094f734f9ca7339ddf6d
git
Even better Inu OS, and Inu Licence, merges the relevant parts of Linux
and Gnu, drops the X and rejects other irrelevant parts. This will be
the angle I support.
Serenity.
Ywe Cærlyn
https://www.youtube.com/channel/UC3BcyFY1Bphc7smGH-IGLVw/featured
Den 17.03.2021 10:28, skrev Ywe Cærlyn
>
>In file included from
> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
> from
> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
> from
> /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/plugin.h
On Thu, 18 Mar 2021 11:41:29 -, David Laight said:
> That gcc bug just implies you need a space after "xxx".
> That is easily fixable in the sources.
It's not quite that simple.
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
>
> GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98)
>
> instead of
>
> GCC_FLAVOR = $(call cc-ifversion, -ge, 600, 11, 98)
>
> So, this patch is also requiring to cover two standards:
>
> GCC_VERSION >= 11 : -std=gnu++11
> GCC_VERSION < 11 : -std
From: Valdis Kletnieks
> Sent: 18 March 2021 06:02
>
> On Wed, 17 Mar 2021 22:52:56 -0700, Kees Cook said:
> > On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis KlDtnieks wrote:
> > > It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
> > > due
dded code was:
GCC_FLAVOR = $(call cc-ifversion, -ge, 1100, 11, 98)
instead of
GCC_FLAVOR = $(call cc-ifversion, -ge, 600, 11, 98)
So, this patch is also requiring to cover two standards:
GCC_VERSION >= 11 : -std=gnu++11
GCC_VERSION < 11 : -std=gnu++98
--
Best Regards
Masahiro Yamada
On Thu, Mar 18, 2021 at 7:03 AM Valdis Klētnieks
wrote:
>
> Or declare that gcc6 is the minimum for building the kernel.
Cc'ing some interested people in raising GCC's version for one reason
or another, so that we put this as another one in the pile of reasons
:-)
https://lore.kernel.org/lkml/CA
On Wed, 17 Mar 2021 22:52:56 -0700, Kees Cook said:
> On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis KlÄtnieks wrote:
> > It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
> > due to a gcc bug fixed in gcc6, throw errors during the build.
> > The rele
On Mon, Mar 08, 2021 at 03:40:21AM -0500, Valdis Klētnieks wrote:
> It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
> due to a gcc bug fixed in gcc6, throw errors during the build.
> The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
>
&
When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find GNU cross tools,
which will not be used indirectly when using the integrated assembler.
All of the tools are invoked directly from PATH or a full path specified
via the co
orrect code as follows?
>
>
> ifneq ($(LLVM_IAS),1)
> CLANG_FLAGS += -no-integrated-as
> ifneq ($(CROSS_COMPILE),)
> CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
> GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
> CLANG_FLAGS += --prefix=$(G
On Wed, Mar 3, 2021 at 6:07 AM Nathan Chancellor wrote:
>
> When building with LLVM_IAS=1, there is no point to specifying
> '--prefix=' because that flag is only used to find the cross assembler,
> which is clang itself when building with LLVM_IAS=1. All of the other
> tools are invoked directly
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
prefix='.
> > >
> > >Sharing commands to reproduce issues becomes a little bit easier without
> > >a '--prefix=' value because that '--prefix=' value is specific to a
> > >user's machine due to it being an absolute path.
> > &g
ut
> >a '--prefix=' value because that '--prefix=' value is specific to a
> >user's machine due to it being an absolute path.
> >
> >Signed-off-by: Nathan Chancellor
>
> Reviewed-by: Fangrui Song
>
> clang can spawn GNU as (
eing an absolute path.
Signed-off-by: Nathan Chancellor
Reviewed-by: Fangrui Song
clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
With LLVM_IAS=1, these cases are ruled out.
When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find the cross assembler,
which is clang itself when building with LLVM_IAS=1. All of the other
tools are invoked directly from PATH or a full path specified via the
command line, which does
t; >
> > Acked-by: Randy Dunlap
>
> except the Subject has a typo in it.
> s/gnu/gpu/
>
And pls follow gvt subsys's subject line as drm/i915/gvt: xxx in future.
I'll fix the title and queue this.
Thanks!
> >> ---
> >> drivers/gpu/drm/i915/gvt/g
On 2/22/21 6:21 AM, Randy Dunlap wrote:
> On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote:
>>
>> s/negtive/negative/
>> s/possilbe/possible/
>>
>> Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
except the Subject has a typo in it.
s/gnu/gpu/
&g
On 2/22/21 12:18 AM, Bhaskar Chowdhury wrote:
>
> s/negtive/negative/
> s/possilbe/possible/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/g
s/negtive/negative/
s/possilbe/possible/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 897c007ea96a..dc5834bf4de2 100644
--- a/dri
ached .config to linux build tree
> make W=1 ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
>In file included from
> /usr/lib/gcc/x86_64-linu
: kernel test robot
All warnings (new ones prefixed by >>):
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/tm.h:27,
from
/usr/lib/gcc/x86_64-linux-gnu/5/plugin/include/gcc-plugin.h:31,
from
/usr/lib/gcc/x86_64-linux-gnu/5/
arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf77be87eacb8f305528d24d892dfcf15cf0341
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel
uild):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> #
> ht
/raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> #
> https://git.kernel.org/
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1da81e5562fac8286567422cc56a7fbd0dc646d4
git remote add linus
https://git.kernel.org/pub/scm
/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773c16705058e9be7b0f4ce124e89cd231c120a2
git remote add linus
https
+x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2add5cacff3531e54c50b0832128299faa9f0563
git remote add linus
https
~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9fddc15e803945a744f357a4d1c94301e1ed6681
git remote add linus
https
uild):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> #
> ht
/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6938cc1cb7763a363f62b78147f1f2fb972f49c
git remote add linus
https
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910
git remote add linus
https://git.kernel.org/pub
t; https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> #
> https://git.kernel.
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910
git remote add linus
https://git.kernel.org/pub
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3e5d80d0c48c0cc7bce56473672f4e6e1210910
git remote add linus
https://git.kernel.org/pub
It turns out that older gcc (4.9 and 5.4) have gnu++11 support, but
due to a gcc bug fixed in gcc6, throw errors during the build.
The relevant gcc bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959
Version the option based on what gcc we're using.
Signed-off-by: Valdis Kletnieks
/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba66a25536dd24b73d36e380c68593e95e4e06a8
git remote add linus
https
On 2020-07-09, 'Nick Desaulniers' via Clang Built Linux wrote:
Hi Segher, Rasmus, and Ramana,
I am working on finalizing a proposal for an LLVM microconference at
plumbers, which is focusing on a lot of issues we currently face on
the LLVM side.
I'd really like to host a sessio
Em Fri, Jul 10, 2020 at 07:27:12PM +0530, Srikar Dronamraju escreveu:
> * Masami Hiramatsu [2020-07-10 22:11:33]:
>
> > Warn if the probe target function is GNU indirect function (GNU_IFUNC)
> > because it may not what the user want to probe.
> >
> > The
* Masami Hiramatsu [2020-07-10 22:11:33]:
> Warn if the probe target function is GNU indirect function (GNU_IFUNC)
> because it may not what the user want to probe.
>
> The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
> is the dynamic solved symbol at
Warn if the probe target function is GNU indirect function (GNU_IFUNC)
because it may not what the user want to probe.
The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
is the dynamic solved symbol at runtime. IFUNC function is a selector
which is invoked from the elf
Hi,
Here are the v2 patches to fix some issues of probing on GNU IFUNC,
duplicated symbols, and memory leak, which were reported by Andi.
V1 is here:
https://lkml.kernel.org/r/159428201109.56570.3802208017109058146.stgit@devnote2
In this version, I've added Srikar's reviewed-by
_point(struct
> > > > debuginfo *dinfo,
> > > > address = sym->start;
> > > > else
> > > > address = map->unmap_ip(map, sym->start) -
> > > > map->reloc;
> > >
@@ static int find_alternative_probe_point(struct
> > debuginfo *dinfo,
> > address = sym->start;
> > else
> > address = map->unmap_ip(map, sym->start) - map->reloc;
> > + if (sym->type == STT_GNU_
else
> > > address = map->unmap_ip(map, sym->start) - map->reloc;
> > > + if (sym->type == STT_GNU_IFUNC) {
> > > + pr_warning("Warning: The probe address (0x%lx) is in a
> > > GNU indirect function.\n"
> &
t; address = map->unmap_ip(map, sym->start) - map->reloc;
> + if (sym->type == STT_GNU_IFUNC) {
> + pr_warning("Warning: The probe address (0x%lx) is in a
> GNU indirect function.\n"
> +
t;type == STT_GNU_IFUNC) {
> > + pr_warning("Warning: The probe address (0x%lx) is in a
> > GNU indirect function.\n"
> > + "This may not work as you expected unless you
> > intend to probe the indirect function.\n
Hi Segher, Rasmus, and Ramana,
I am working on finalizing a proposal for an LLVM microconference at
plumbers, which is focusing on a lot of issues we currently face on
the LLVM side.
I'd really like to host a session with more GNU toolchain developers
to discuss collaboration more.
I was cu
ginfo
> *dinfo,
> address = sym->start;
> else
> address = map->unmap_ip(map, sym->start) - map->reloc;
> + if (sym->type == STT_GNU_IFUNC) {
> + pr_warning("Warning: The prob
Warn if the probe target function is GNU indirect function (GNU_IFUNC)
because it may not what the user want to probe.
The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
is the dynamic solved symbol at runtime. IFUNC function is a selector
which is invoked from the elf
Hi,
Here are patches to fix some issues of probing on GNU IFUNC, duplicated
symbols, and memory leak, which were reported by Andi.
Andi reported that some issues on probing memcpy function in glibc,
which was related to GNU IFUNC (indirect function). As I described
in the patch [4/4], it is hard
>> fields out of the inode and into the "gnu.*" xattr namespace.
> >>
> >> In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has
> >> now been brought into compliance[2] with that.
> >>
> >> This patch add
On Wed, 3 Jun 2020 at 14:31, Naresh Kamboju wrote:
>
> arm64 build failed on Linux-next 20200603.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64
> CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache
> aarch64-linux-gnu-gcc" O=build Image
> #
arm64 build failed on Linux-next 20200603.
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache
aarch64-linux-gnu-gcc" O=build Image
#
aarch64-linux-gnu-ld: cannot find
./drivers/firmware/efi/libstub/lib.abuilt-in.a: No su
Theodore Y. Ts'o writes:
Hello!
> On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote:
>> The Hurd gained[0] support for moving the translator and author
>> fields out of the inode and into the "gnu.*" xattr namespace.
>>
>> I
On Mon, May 25, 2020 at 09:39:40PM +0200, Jan (janneke) Nieuwenhuizen wrote:
> The Hurd gained[0] support for moving the translator and author
> fields out of the inode and into the "gnu.*" xattr namespace.
>
> In anticipation of that, an xattr INDEX was reserved[1]. T
The Hurd gained[0] support for moving the translator and author
fields out of the inode and into the "gnu.*" xattr namespace.
In anticipation of that, an xattr INDEX was reserved[1]. The Hurd has
now been brought into compliance[2] with that.
This patch adds support for reading and wr
It has been 3 years since GNU Make 4.2.1 was released. The maintainer
of GNU Make, Paul Smith, has announced that the new version (4.3?) will
be released soon.
I reported a bug about the $? behavior some time ago, but it has not
been fixed yet. I am eager to see it fixed for the new release
Yes, then I think we have solved the behavioural problem of Linux, and it seems
to come down to the GNU idol, that seems based on Morphine Psychosis. And such
the worst Stallman fans, have irate behaviour.
And much have pointed to that already, and much criticism done, and indeed the
GNU idol
s://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 83a50840e72a5a964b4704fcdc2fbb2d771015ab
> commit: acaf892ecbf5be7710ae05a61fd43c668f68ad95 sh: fix multiple function
> definition build errors
> date: 3 weeks ago
> config: sh-allmodconfig (attach
rrors
date: 3 weeks ago
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git che
Masahiro Yamada wrote:
> Why should this patch be included in a
> totally unrelated patch series?
Sorry, I forgot to exclude it. It's in all my branches that I've touched
since upstream got broken. I've now rebased and it's gone from this branch.
David
; annoyed people who want to wrap the top Makefile with GNUmakefile
> > or something in order to customize it for their use.
> >
> > On second thought, we do not need to run the sub-make for in-tree
> > build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
for their use.
>
> On second thought, we do not need to run the sub-make for in-tree
> build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> on GNU Make 3.x.
>
> With this commit, people will get back the workflow, and the Debian
> make-kpkg will s
h Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
on GNU Make 3.x.
With this commit, people will get back the workflow, and the Debian
make-kpkg will still work.
Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
Reported-by: Andreas Schwab
Reported
ought, we do not need to run the sub-make for in-tree
> build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
> on GNU Make 3.x.
>
> With this commit, people will get back the workflow, and the Debian
> make-kpkg will still work.
>
> Fixes: 2b50f7ab6368 (&
'MAKEFLAGS += -rR' issue only happens
on GNU Make 3.x.
With this commit, people will get back the workflow, and the Debian
make-kpkg will still work.
Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
Reported-by: Andreas Schwab
Reported-by: David Howells
> Hi,
>
> Ben Finney wrote:
> > > In other words: Any copyright holder can *say* they wish to
> > > retroactively revoke the GNU GPL to some party.
>
> Well, everybody is free to express wishes. But a granted license with no
> applicable revocation clause is irrevocable.
hrooms (Terence McKenna Christmas Dub Special)
https://www.youtube.com/watch?v=jZKNQAXWN1U
Next time GNU Stallman prophesizes on LSD, without understandings for economics
(like indeed most hippies were), think of Digi G' Alessio
Peas. (As indeed the NKM version goes).
And indeed behaviour like Linus, who has threatened to kill people over
printers is not acceptable.
Linus Benedict Torvalds, genius, or pisscrazy?
A song made in remembrance of Linus temper: Archetypical Geek - Printernerd
Hate. https://www.youtube.com/watch?v=1oel17-9N7o
If indeed people do n
, builds on the earlier.
GNU Is Not Unix, builds on the earlier, but in hippie times, is also associated
with LSD.
Amiga 500, an Irix for the home computer, not available source, builds on
earlier, and probably LSD aswell.
Microsoft Windows, not available source, builds on earlier aswell, LSD and
Hello.
As a researcher I started a trend in here a few years ago, where criticism of
the lack of coherent philosophy behind Linux, now seems to have resulted in a
few lines of pseudoreligious statements, that supposedly is the answer to this,
called "GNU Kind Communication Guidelines"
GNU senorship hit me again, on Phoronix. This is LKML, a usenet mailing
list. So lets try again here.
Linus Torvalds, Richard Stallman, and Andrew Tanenbaum all are
pedophilia victims. And oddly enough think they are gods because of this.
On Linux forums, fanboys attack, because they
Slight retweak, to %ÿ4 Coding OS.
Having had a bit of feel with the namechange I think I can do even
better. Looking at what really needs to be fixed with the internet,
starting with Fair Pay, getting rid of poor and thieving GNU, and
warezpups in general, LKML/GNU Attitude problems, and
lude/stdio.h:27,
from samples/seccomp/bpf-fancy.c:16:
/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or
directory
# include
^~~~
compilation terminated.
make[2]: *** [scripts/Makefile.host:107: samples/seccomp/bpf-fancy.o] Error 1
make[1
2018-03-24 2:59 GMT+09:00 Jason Gunthorpe :
> There is a change in how command line parsing is done in this version.
> Excludes and includes are now ordered with the file list. Since
> the spec file puts the file list before the exclude list it means newer
> tar ignores the excludes and packs all t
On Mon, Mar 26, 2018 at 5:06 PM, Sandra Loosemore
wrote:
> On 03/26/2018 07:30 AM, Arnd Bergmann wrote:
>>
>>
>> Another interesting question is the status of your toolchain support. I
>> see your
>> github account contains binutils and gcc repositories, but they are not
>> upstream
>> yet. Are yo
On 03/26/2018 07:30 AM, Arnd Bergmann wrote:
Another interesting question is the status of your toolchain support. I see your
github account contains binutils and gcc repositories, but they are not upstream
yet. Are you working on getting those included in the respective upstream
projects alread
There is a change in how command line parsing is done in this version.
Excludes and includes are now ordered with the file list. Since
the spec file puts the file list before the exclude list it means newer
tar ignores the excludes and packs all the build output into the
kernel-devel RPM resulting
Reviewed-by: Nick Desaulniers
These patches add macros for detecting the linker name and version,
and apply fixes and workarounds needed to link the arm64 kernel with
GNU gold.
Changes since v1:
- moved LD_DEAD_CODE_DATA_ELIMINATION fixes to the beginning of the
patch set and removed mentions of gold
- renamed ld-if
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec
instead of aarch64linux.
Signed-off-by: Sami Tolvanen
Acked-by: Yury Norov
---
arch/arm64/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b35788c909f1
All current versions of GNU gold crash when linking kernel modules
with ARM64_MODULE_PLTS due to a known bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14592
To work around the problem, this change removes NOLOAD from .plt
and .init.plt.
Signed-off-by: Sami Tolvanen
Acked-by: Ard
Some versions of GNU gold are known to produce broken code with
--fix-cortex-a53-843419 as explained in this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21491
If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass
--no-fix-cortex-a53-843419 to the linker to ensur
1 - 100 of 294 matches
Mail list logo
