From: email@example.com To: firstname.lastname@example.org Subject: [Bug 204125] New: FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__ Date: Wed, 10 Jul 2019 13:24:01 +0000 Message-ID: <email@example.com/> (raw) https://bugzilla.kernel.org/show_bug.cgi?id=204125 Bug ID: 204125 Summary: FTBFS on ppc64 big endian and gcc9 because of -mcall-aixdesc and missing __linux__ Product: Platform Specific/Hardware Version: 2.5 Kernel Version: any Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: PPC-64 Assignee: firstname.lastname@example.org Reporter: email@example.com Regression: No On ppc64 big endian, the kernel builds with `-mcall-aixdesc` which since gcc 9.x removes `__linux__` from the list of macros being defined. This behavior is supposed to be more correct (as it's in this case nothing but a hack, the flag should apparently only be used when building for AIX) but sadly it breaks build since several things within the tree rely on `__linux__` being defined and `#ifdef` some of their code based on said macro. Just removing `-mcall-aixdesc` (and using just `-mabi=elfv1`) is however not enough, as that instead causes countless undefined references to just about every symbol when linking `vmlinux`. It would seem that `-mcall-aixdesc` changes the way symbols are declared in a way that is not expected. Little endian is not affected because that one uses `-mabi=elfv2` exclusively. For now I worked around it in my distro by explicitly adding `-D__linux__` in the kbuild where `-mcall-aixdesc` is inserted into flags, and it works, but that's obviously just a workaround. I'm not sure what the proper fix would be. Also, is there any reason not to allow an ELFv2 kernel to be built on big endian? There are some supposed performance benefits, and ELFv2 itself supports either endianness. The current kbuild logic pretty much forces ELFv1 for big endian and ELFv2 for little endian. -- You are receiving this mail because: You are watching the assignee of the bug.
next reply index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-10 13:24 bugzilla-daemon [this message] 2019-07-10 15:37 ` [Bug 204125] " bugzilla-daemon 2019-07-10 15:41 ` bugzilla-daemon 2019-07-10 15:57 ` bugzilla-daemon 2019-07-10 16:01 ` bugzilla-daemon 2019-07-10 16:04 ` bugzilla-daemon 2019-07-12 1:41 ` bugzilla-daemon 2019-07-12 2:11 ` bugzilla-daemon 2019-07-12 15:36 ` bugzilla-daemon 2019-09-08 14:57 ` bugzilla-daemon
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org/ \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LinuxPPC-Dev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linuxppc-dev/0 linuxppc-dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linuxppc-dev linuxppc-dev/ https://lore.kernel.org/linuxppc-dev \ email@example.com firstname.lastname@example.org public-inbox-index linuxppc-dev Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git