Message-ID: <CA+icZUWc3ZoK1MQ2uFqYVK8DHeh9w-nQWe+TfkH68R3GDi95KQ@mail.gmail.com>
Date:	Tue, 8 Sep 2015 07:45:25 +0200
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Use (two) different compilers at build-time?

On Tue, Sep 8, 2015 at 12:30 AM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Mon, Sep 7, 2015 at 11:20 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> On Mon, Sep 7, 2015 at 10:59 PM, Linus Torvalds
>> <torvalds@...ux-foundation.org> wrote:
>>> On Mon, Sep 7, 2015 at 1:53 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>>>>
>>>> That does not work.
>>>
>>> .. because you didn't do what I told you to do.
>>>
>>>> I copied a gcc-compiled percpu.o OR deleted/renamed percpu.o and
>>>> re-invoked make - this starts a complete new build from scratch.
>>>
>>> Right. Because you changed the compiler name, so now the build system
>>> realizes that the old build instructions are stale.
>>>
>>> Which is why you have to:
>>>
>>>>> Use a wrapper around the compiler (and point to that wrapper with the
>>>>> "to switch compilers from under the make, without the build paths
>>>>> changing (because otherwise our makefile auto-machinery notices that
>>>>> flags and command changed).
>>>>>
>>>>> Use CC (or CROSS_COMPILE) to point at your wrapper.
>>>>
>>>> No idea how to realize that, sorry.
>>>
>>> Literally just do something like this:
>>>
>>>  - have a shell script call "mycompiler" and make it do gcc/llvm "$@".
>>>
>>>  - or even just use a symlink (the script has the advantage that you
>>> can play with the options etc too)
>>>
>>>  - change the shell script (or symlink) itself, and make sure to use
>>> the same CC for "make" at all times, so that the build script never
>>> sees that the underlying command is now different.
>>>
>>> It should work fine, I've done it a couple of times (although
>>> admittedly not recently)
>>>
>>
>> OK, I have created a mycompiler shell-script and use that for CC and
>> HOSTCC in my own build-script.
>>
>> Using CLANG...
>>
>> [ /usr/bin/mycompiler ]
>>
>> #!/bin/bash
>>
>> clang "$@"
>> - EOF -
>>
>> $ mycompiler --version
>> clang version 3.7.0 (tags/RELEASE_370/final)
>> Target: x86_64-unknown-linux-gnu
>> Thread model: posix
>>
>> Switching to GCC...
>>
>> [ /usr/bin/mycompiler ]
>>
>> #!/bin/bash
>>
>> gcc-4.9 "$@"
>> - EOF -
>>
>> $ mycompiler --version
>> gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> Thanks, that helped me a lot.
>>
>
> Sadly, this trick does not work here with Linux v4.2.
>

So, the problem is any change to your make-lines.
Means $COMPILER and/or compiler flags!

I simplified in Makefile...

COMPILER := clang
export COMPILER

and then did a symlink gcc-4.9 -> clang.

This did NOT work because clang uses a compiler-flag
'-no-integrated-as' which does not exist for gcc!

So, switching from gcc -> clang or vice-versa is not possible with
your compiler-wrapper-script trick :-(.

Anyway, I need a different solution.

One of my ideas was to hack the mm/Makefile.

--- a/mm/Makefile
+++ b/mm/Makefile
@@ -2,6 +2,9 @@
 # Makefile for the linux memory manager.
 #

+COMPILER := gcc
+export COMPILER
+
 KASAN_SANITIZE_slab_common.o := n
 KASAN_SANITIZE_slub.o := n

@@ -78,3 +81,6 @@ obj-$(CONFIG_CMA)     += cma.o
 obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
 obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
 obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+
+COMPILER := clang
+export COMPILER

Not sure if this works.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists