| Message ID | 1439549533-8716-1-git-send-email-p.fedin@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2015-08-14 12:52, Pavel Fedin wrote: > Certain platforms (e. g. BSD-based ones) define some ELF constants > according to host. This patch fixes problems with cross-building > Linux kernel on these platforms (e. g. building ARM 32-bit version > on x86-64 host). > > Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Thanks, applied to kbuild.git#kbuild. But it seems that arch/x86/tools/relocs needs the same fix. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello! > Thanks, applied to kbuild.git#kbuild. But it seems that > arch/x86/tools/relocs needs the same fix. Perhaps. I tried to compile only ARM kernels, no x86. By the way, i have several more fixes which could increase kbuild portability. For example, there are several issues on Cygwin with .exe extensions of some tools. Could we upstream them also? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-08-20 14:31, Pavel Fedin wrote: > Hello! > >> Thanks, applied to kbuild.git#kbuild. But it seems that >> arch/x86/tools/relocs needs the same fix. > > Perhaps. I tried to compile only ARM kernels, no x86. > > By the way, i have several more fixes which could increase kbuild portability. For example, there > are several issues on Cygwin with .exe extensions of some tools. Could we upstream them also? If you already have the patches, it won't hurt to send them. Although I was under the impression that the .exe suffix is somehow automagically handled by Cygwin..? Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > If you already have the patches, it won't hurt to send them. I have one of them, need to make more. > Although I > was under the impression that the .exe suffix is somehow automagically > handled by Cygwin..? In 99% of cases - yes. But at least there is a problem with implicit rules in GNU Make. Actually, here i am talking about patch 0002 from this set: https://www.cygwin.com/ml/cygwin/2012-06/msg00221.html. This HOWTO was created when the kernel was really old, and now some more tools face a similar problem, like certificate generator for security subsystem. I will check this. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-08-20 15:18, Pavel Fedin wrote: > Hi! > >> If you already have the patches, it won't hurt to send them. > > I have one of them, need to make more. > >> Although I >> was under the impression that the .exe suffix is somehow automagically >> handled by Cygwin..? > > In 99% of cases - yes. But at least there is a problem with implicit rules in GNU Make. That sounds good. I feared we would have to write scripts/foo$(EXE) everywhere. > Actually, here i am talking about patch 0002 from this set: > https://www.cygwin.com/ml/cygwin/2012-06/msg00221.html. Patch 0002 has been merged in the meantime. > This HOWTO was created when the kernel was > really old, and now some more tools face a similar problem, like certificate generator for security > subsystem. I will check this. OK. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello! > > Actually, here i am talking about patch 0002 from this set: > > https://www.cygwin.com/ml/cygwin/2012-06/msg00221.html. > > Patch 0002 has been merged in the meantime. Sorry, my fault. I meant 0001. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michal, 2015-08-20 20:31 GMT+09:00 Michal Marek <mmarek@suse.com>: > On 2015-08-14 12:52, Pavel Fedin wrote: >> Certain platforms (e. g. BSD-based ones) define some ELF constants >> according to host. This patch fixes problems with cross-building >> Linux kernel on these platforms (e. g. building ARM 32-bit version >> on x86-64 host). >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com> > > Thanks, applied to kbuild.git#kbuild. But it seems that > arch/x86/tools/relocs needs the same fix. > > Michal I am not happy with getting weird code to work around issues on non-Linux systems. Is it justified to make efforts to build Linux on other systems than Linux? Documentation/Changes implies that already running a Linux system is the requirement: Again, keep in mind that this list assumes you are already functionally running a Linux kernel. I work on U-boot, which allows to be built on non-Linux systems. This is what happened in U-boot community. In order to build U-boot on non-Linux OSes, GNU-extensions are forbidden even if they are cool. After all, such patches are here and there. http://patchwork.ozlabs.org/patch/395588/ http://patchwork.ozlabs.org/patch/397453/ http://patchwork.ozlabs.org/patch/378773/ Actually, 99% developers work on Linux systems, i.e. they only build on Linux systems and send patches. 1% developers send work-around patches to build on other OSes. Nobody can cover all systems, such as Cygwin, BSD, Mac-OS, etc. After a long run, mysterious code is sprinkled, which nobody can judge if it is correct or not.
Hello! > I am not happy with getting weird code to work around issues on > non-Linux systems. What is your criteria of being weird? Why are four #undef's weird ? Do you want to tell that "all OSes except Linux are weird?" Isn't it too childish? I can say that i use Windows as my desktop OS because only Windows has all the necessary corporate software, and using Linux inside a virtual machine just for running builds is inconvenient. And vast majority of corporate users use Windows. Well, it's just my opinion, i'm not going to start another "Lin vs Win" war, i think it's just stupid. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-08-25 16:47 GMT+09:00 Pavel Fedin <p.fedin@samsung.com>: > Hello! > >> I am not happy with getting weird code to work around issues on >> non-Linux systems. > > What is your criteria of being weird? Why are four #undef's weird ? I am not criticizing your particular patch. Once we decide to support building on other OSes, I fear more and more patches would come in to fix building issues. I guess shell-scripts are often encountered with portability issues. People tend to do coding without caring about the portability. > Do you want to tell that "all OSes except Linux are weird?" Isn't it too childish? I am saying that at all. > I can say that i use Windows as my desktop OS because only Windows has all the necessary corporate software, and using Linux inside a virtual machine just for running builds is inconvenient. And vast majority of corporate users use Windows. > Well, it's just my opinion, i'm not going to start another "Lin vs Win" war, i think it's just stupid. We are not talking about the majority among corporate uses in general. Linux is absolutely the majority among kernel developers. They might also use Windows too, but they most likely run Linux (on a real hardware, or a virtual machine, whatever) for developing the kernel.
Hello! > I am not criticizing your particular patch. Ok :) > Once we decide to support building on other OSes, > I fear more and more patches would come in > to fix building issues. Well, we could agree on some policy like "patches should be small and elegant", and there should be no things like #if defined(__freebsd__) ... #elif defined(__CYGWIN__)... etc I am skipping the rest because it's already "strawberry vs eggs". Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-08-25 10:18, Masahiro Yamada wrote: > 2015-08-25 16:47 GMT+09:00 Pavel Fedin <p.fedin@samsung.com>: >> Hello! >> >>> I am not happy with getting weird code to work around issues on >>> non-Linux systems. >> >> What is your criteria of being weird? Why are four #undef's weird ? > > > I am not criticizing your particular patch. > > Once we decide to support building on other OSes, > I fear more and more patches would come in > to fix building issues. While nowadays Linux is often the first OS ported to a new architecture and is cross compiled on another Linux system, I think portable code is a virtue on its own, _unless_ it requires having compatibility wrappers for half of the library calls and whatnot. It's hard to draw a line, but it'd say patches to enable build on Cygwin are OK (since it emulates a POSIX system quite well), whereas patches to enable build on native Windows, dealing with pathname lookup differences, .exe suffixes, adding a libc wrapper, etc, would be frowned upon. Would you agree to such loosely defined criteria? Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello! > While nowadays Linux is often the first OS ported to a new architecture > and is cross compiled on another Linux system, I think portable code is > a virtue on its own, _unless_ it requires having compatibility wrappers > for half of the library calls and whatnot. It's hard to draw a line, but > it'd say patches to enable build on Cygwin are OK (since it emulates a > POSIX system quite well), whereas patches to enable build on native > Windows, dealing with pathname lookup differences, .exe suffixes, adding > a libc wrapper, etc, would be frowned upon. > > Would you agree to such loosely defined criteria? I absolutely agree. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h index 168b43d..6a5e151 100644 --- a/scripts/mod/modpost.h +++ b/scripts/mod/modpost.h @@ -11,6 +11,12 @@ #include "elfconfig.h" +/* On BSD-alike OSes elf.h defines these according to host's word size */ +#undef ELF_ST_BIND +#undef ELF_ST_TYPE +#undef ELF_R_SYM +#undef ELF_R_TYPE + #if KERNEL_ELFCLASS == ELFCLASS32 #define Elf_Ehdr Elf32_Ehdr
Certain platforms (e. g. BSD-based ones) define some ELF constants according to host. This patch fixes problems with cross-building Linux kernel on these platforms (e. g. building ARM 32-bit version on x86-64 host). Signed-off-by: Pavel Fedin <p.fedin@samsung.com> --- v1 => v2 - Replaced "Cygwin" with "BSD-alike OS-es" --- scripts/mod/modpost.h | 6 ++++++ 1 file changed, 6 insertions(+)