Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391975 > unrolled thread

Re: [PATCH v7 1/6] Shared library support

Started byMasahiro Yamada <yamada.masahiro@socionext.com>
First post2016-05-02 07:10 +0200
Last post2016-05-05 20:40 +0200
Articles 9 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v7 1/6] Shared library support Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-05-02 07:10 +0200
    Re: [PATCH v7 1/6] Shared library support Emese Revfy <re.emese@gmail.com> - 2016-05-02 19:50 +0200
      Re: [PATCH v7 1/6] Shared library support Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-05-03 04:10 +0200
        Re: [PATCH v7 1/6] Shared library support Emese Revfy <re.emese@gmail.com> - 2016-05-03 23:30 +0200
          Re: [PATCH v7 1/6] Shared library support Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-05-04 06:10 +0200
            Re: [PATCH v7 1/6] Shared library support Emese Revfy <re.emese@gmail.com> - 2016-05-05 20:40 +0200
      Re: [PATCH v7 1/6] Shared library support Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-05-03 04:10 +0200
    Re: [PATCH v7 1/6] Shared library support Emese Revfy <re.emese@gmail.com> - 2016-05-03 23:20 +0200
      Re: [PATCH v7 1/6] Shared library support Emese Revfy <re.emese@gmail.com> - 2016-05-05 20:40 +0200

#1391975 — Re: [PATCH v7 1/6] Shared library support

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-05-02 07:10 +0200
SubjectRe: [PATCH v7 1/6] Shared library support
Message-ID<ruehk-5Uk-11@gated-at.bofh.it>
Hi Emese,


2016-04-23 3:21 GMT+09:00 Emese Revfy <re.emese@gmail.com>:
> Infrastructure for building independent shared library targets.
> This effectively also reverts commit 62e2210798ed38928ab24841e8b4878a
> (Masahiro Yamada, kbuild: drop shared library support from Makefile.host).
>
> Signed-off-by: Emese Revfy <re.emese@gmail.com>
> ---
>  Documentation/kbuild/makefiles.txt | 39 ++++++++++++++++-----
>  scripts/Makefile.build             |  2 +-
>  scripts/Makefile.clean             |  3 +-
>  scripts/Makefile.host              | 70 +++++++++++++++++++++++++++++++++++++-
>  4 files changed, 103 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 13f888a..250729b 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -23,10 +23,11 @@ This document describes the Linux kernel Makefiles.
>         === 4 Host Program support
>            --- 4.1 Simple Host Program
>            --- 4.2 Composite Host Programs
> -          --- 4.3 Using C++ for host programs
> -          --- 4.4 Controlling compiler options for host programs
> -          --- 4.5 When host programs are actually built
> -          --- 4.6 Using hostprogs-$(CONFIG_FOO)
> +          --- 4.3 Defining shared libraries
> +          --- 4.4 Using C++ for host programs
> +          --- 4.5 Controlling compiler options for host programs
> +          --- 4.6 When host programs are actually built
> +          --- 4.7 Using hostprogs-$(CONFIG_FOO)
>
>         === 5 Kbuild clean infrastructure
>
> @@ -643,7 +644,29 @@ Both possibilities are described in the following.
>         Finally, the two .o files are linked to the executable, lxdialog.
>         Note: The syntax <executable>-y is not permitted for host-programs.
>
> ---- 4.3 Using C++ for host programs
> +--- 4.3 Defining shared libraries
> +
> +       Objects with extension .so are considered shared libraries, and
> +       will be compiled as position independent objects.
> +       Kbuild provides support for shared libraries, but the usage
> +       shall be restricted.
> +       In the following example the libkconfig.so shared library is used
> +       to link the executable conf.
> +
> +       Example:
> +               #scripts/kconfig/Makefile
> +               hostprogs-y     := conf
> +               conf-objs       := conf.o libkconfig.so
> +               libkconfig-objs := expr.o type.o


Do you use this case?


> +       Shared libraries always require a corresponding -objs line, and
> +       in the example above the shared library libkconfig is composed by
> +       the two objects expr.o and type.o.
> +       expr.o and type.o will be built as position independent code and
> +       linked as a shared library libkconfig.so. C++ is not supported for
> +       shared libraries.

You are supporting C++ shared libraries.

Please do not revert as is, but change the comments to make sense.


In the first place,
I am wondering if we need to revive this documentation.
What this commit is only interested in *.so generation,
not host program support.





> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -60,7 +60,7 @@ endif
>  endif
>
>  # Do not include host rules unless needed
> -ifneq ($(hostprogs-y)$(hostprogs-m),)
> +ifneq ($(hostprogs-y)$(hostprogs-m)$(hostlibs-y)$(hostlibs-m)$(hostcxxlibs-y)$(hostcxxlibs-m),)
>  include scripts/Makefile.host
>  endif
>
> diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean
> index 55c96cb..e4e88ab 100644
> --- a/scripts/Makefile.clean
> +++ b/scripts/Makefile.clean
> @@ -38,7 +38,8 @@ subdir-ymn    := $(addprefix $(obj)/,$(subdir-ymn))
>  __clean-files  := $(extra-y) $(extra-m) $(extra-)       \
>                    $(always) $(targets) $(clean-files)   \
>                    $(host-progs)                         \
> -                  $(hostprogs-y) $(hostprogs-m) $(hostprogs-)
> +                  $(hostprogs-y) $(hostprogs-m) $(hostprogs-) \
> +                  $(hostlibs-y) $(hostlibs-m) $(hostlibs-)

$(hostcxxlibs-y)$(hostcxxlibs-m) is missing here.


BTW, are you planning to support hostlibs without .so extention in the future?


You are changing the top Makefile to clean with "*.so" pattern rule.

Do you need to change both the top Makefile and Makefile.clean
for belt-and-braces cleaning?




>  __clean-files   := $(filter-out $(no-clean-files), $(__clean-files))
>
> diff --git a/scripts/Makefile.host b/scripts/Makefile.host
> index 133edfa..3439bd8 100644
> --- a/scripts/Makefile.host
> +++ b/scripts/Makefile.host
> @@ -20,7 +20,25 @@
>  # Will compile qconf as a C++ program, and menu as a C program.
>  # They are linked as C++ code to the executable qconf
>
> +# hostprogs-y := conf
> +# conf-objs  := conf.o libkconfig.so
> +# libkconfig-objs := expr.o type.o
> +# Will create a shared library named libkconfig.so that consists of
> +# expr.o and type.o (they are both compiled as C code and the object files
> +# are made as position independent code).
> +# conf.c is compiled as a C program, and conf.o is linked together with
> +# libkconfig.so as the executable conf.
> +# Note: Shared libraries consisting of C++ files are not supported

Again, do you need to support "hostprogs-y" based on .so library?



> +# hostcc-option
> +# Usage: cflags-y += $(call hostcc-option,-march=winchip-c6,-march=i586)
> +
> +hostcc-option = $(call try-run,\
> +       $(HOSTCC) $(HOSTCFLAGS) $(HOST_EXTRACFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))
> +
>  __hostprogs := $(sort $(hostprogs-y) $(hostprogs-m))
> +__hostlibs := $(sort $(hostlibs-y) $(hostlibs-m))
> +__hostcxxlibs := $(sort $(hostcxxlibs-y) $(hostcxxlibs-m))
>
>  # C code
>  # Executables compiled from a single .c file
> @@ -42,6 +60,18 @@ host-cxxmulti        := $(foreach m,$(__hostprogs),$(if $($(m)-cxxobjs),$(m)))
>  # C++ Object (.o) files compiled from .cc files
>  host-cxxobjs   := $(sort $(foreach m,$(host-cxxmulti),$($(m)-cxxobjs)))
>
> +# Shared libaries (only .c supported)
> +# Shared libraries (.so) - all .so files referenced in "xxx-objs"
> +host-cshlib    := $(sort $(filter %.so, $(__hostlibs)))
> +host-cxxshlib  := $(sort $(filter %.so, $(__hostcxxlibs)))


Do you use $(filter %.so, ...) on purpose?
i.e.  are you planning to support both hostlibs with/without .so?



> +# Remove .so files from "xxx-objs"
> +host-cobjs     := $(filter-out %.so,$(host-cobjs))
> +host-cxxobjs   := $(filter-out %.so,$(host-cxxobjs))

Why do you need to do this?


> +# Object (.o) files used by the shared libaries
> +host-cshobjs   := $(sort $(foreach m,$(host-cshlib),$($(m:.so=-objs))))
> +host-cxxshobjs := $(sort $(foreach m,$(host-cxxshlib),$($(m:.so=-objs))))
> +
>  # output directory for programs/.o files
>  # hostprogs-y := tools/build may have been specified.
>  # Retrieve also directory of .o files from prog-objs or prog-cxxobjs notation
> @@ -56,6 +86,10 @@ host-cmulti  := $(addprefix $(obj)/,$(host-cmulti))
>  host-cobjs     := $(addprefix $(obj)/,$(host-cobjs))
>  host-cxxmulti  := $(addprefix $(obj)/,$(host-cxxmulti))
>  host-cxxobjs   := $(addprefix $(obj)/,$(host-cxxobjs))
> +host-cshlib    := $(addprefix $(obj)/,$(host-cshlib))
> +host-cxxshlib  := $(addprefix $(obj)/,$(host-cxxshlib))
> +host-cshobjs   := $(addprefix $(obj)/,$(host-cshobjs))
> +host-cxxshobjs := $(addprefix $(obj)/,$(host-cxxshobjs))
>  host-objdirs    := $(addprefix $(obj)/,$(host-objdirs))
>
>  obj-dirs += $(host-objdirs)
> @@ -124,5 +158,39 @@ quiet_cmd_host-cxxobjs     = HOSTCXX $@
>  $(host-cxxobjs): $(obj)/%.o: $(src)/%.cc FORCE
>         $(call if_changed_dep,host-cxxobjs)
>
> +# Compile .c file, create position independent .o file
> +# host-cshobjs -> .o
> +quiet_cmd_host-cshobjs = HOSTCC  -fPIC $@
> +      cmd_host-cshobjs = $(HOSTCC) $(hostc_flags) -fPIC -c -o $@ $<
> +$(host-cshobjs): $(obj)/%.o: $(src)/%.c FORCE
> +       $(call if_changed_dep,host-cshobjs)
> +
> +# Compile .c file, create position independent .o file


Please explain why c++ compiler should be used to compile .c files.

This is not clear, so worth commenting.



> +# host-cxxshobjs -> .o
> +quiet_cmd_host-cxxshobjs       = HOSTCXX -fPIC $@
> +      cmd_host-cxxshobjs       = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
> +$(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
> +       $(call if_changed_dep,host-cxxshobjs)
> +
> +# Link a shared library, based on position independent .o files
> +# *.o -> .so shared library (host-cshlib)
> +quiet_cmd_host-cshlib  = HOSTLLD -shared $@
> +      cmd_host-cshlib  = $(HOSTCC) $(HOSTLDFLAGS) -shared -o $@ \
> +                         $(addprefix $(obj)/,$($(@F:.so=-objs))) \
> +                         $(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
> +$(host-cshlib): FORCE
> +       $(call if_changed,host-cshlib)
> +$(call multi_depend, $(host-cshlib), .so, -objs -cshobjs)

should be

$(call multi_depend, $(host-cshlib), .so, -objs)


> +# Link a shared library, based on position independent .o files
> +# *.o -> .so shared library (host-cxxshlib)
> +quiet_cmd_host-cxxshlib        = HOSTLLD -shared $@
> +      cmd_host-cxxshlib        = $(HOSTCXX) $(HOSTLDFLAGS) -shared -o $@ \
> +                         $(addprefix $(obj)/,$($(@F:.so=-objs))) \
> +                         $(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
> +$(host-cxxshlib): FORCE
> +       $(call if_changed,host-cxxshlib)
> +$(call multi_depend, $(host-cxxshlib), .so, -objs -cxxshobjs)

should be

$(call multi_depend, $(host-cxxshlib), .so, -objs)




-- 
Best Regards
Masahiro Yamada

[toc] | [next] | [standalone]

#1392413

FromEmese Revfy <re.emese@gmail.com>
Date2016-05-02 19:50 +0200
Message-ID<ruq8P-7OL-19@gated-at.bofh.it>
In reply to#1391975
On Mon, 2 May 2016 14:03:00 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

> In the first place,
> I am wondering if we need to revive this documentation.
> What this commit is only interested in *.so generation,
> not host program support.

I agree that we don't need this documentation. I'll remove it.
  
> > @@ -124,5 +158,39 @@ quiet_cmd_host-cxxobjs     = HOSTCXX $@
> >  $(host-cxxobjs): $(obj)/%.o: $(src)/%.cc FORCE
> >         $(call if_changed_dep,host-cxxobjs)
> >
> > +# Compile .c file, create position independent .o file
> > +# host-cshobjs -> .o
> > +quiet_cmd_host-cshobjs = HOSTCC  -fPIC $@
> > +      cmd_host-cshobjs = $(HOSTCC) $(hostc_flags) -fPIC -c -o $@ $<
> > +$(host-cshobjs): $(obj)/%.o: $(src)/%.c FORCE
> > +       $(call if_changed_dep,host-cshobjs)
> > +
> > +# Compile .c file, create position independent .o file
> 
> 
> Please explain why c++ compiler should be used to compile .c files.
> 
> This is not clear, so worth commenting.

Where do you think that the C++ compiler is used above? I think HOSTCC can only be C compiler.

-- 
Emese

[toc] | [prev] | [next] | [standalone]

#1392981

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-05-03 04:10 +0200
Message-ID<ruxWG-7p8-1@gated-at.bofh.it>
In reply to#1392413
Hi Emese,


2016-05-03 2:56 GMT+09:00 Emese Revfy <re.emese@gmail.com>:
> On Mon, 2 May 2016 14:03:00 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> In the first place,
>> I am wondering if we need to revive this documentation.
>> What this commit is only interested in *.so generation,
>> not host program support.
>
> I agree that we don't need this documentation. I'll remove it.
>
>> > @@ -124,5 +158,39 @@ quiet_cmd_host-cxxobjs     = HOSTCXX $@
>> >  $(host-cxxobjs): $(obj)/%.o: $(src)/%.cc FORCE
>> >         $(call if_changed_dep,host-cxxobjs)
>> >
>> > +# Compile .c file, create position independent .o file
>> > +# host-cshobjs -> .o
>> > +quiet_cmd_host-cshobjs = HOSTCC  -fPIC $@
>> > +      cmd_host-cshobjs = $(HOSTCC) $(hostc_flags) -fPIC -c -o $@ $<
>> > +$(host-cshobjs): $(obj)/%.o: $(src)/%.c FORCE
>> > +       $(call if_changed_dep,host-cshobjs)
>> > +
>> > +# Compile .c file, create position independent .o file
>>
>>
>> Please explain why c++ compiler should be used to compile .c files.
>>
>> This is not clear, so worth commenting.
>
> Where do you think that the C++ compiler is used above? I think HOSTCC can only be C compiler.
>

Not above, but *below*.

This comment "Compile .c file, create position independent .o file"
is for the following code block.


# Compile .c file, create position independent .o file
# host-cxxshobjs -> .o
quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
      cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
                           $(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
                           $(call if_changed_dep,host-cxxshobjs)




We generally use HOSTCC to compile *.c files,
and HOSTCXX to compile *.cc files.


But, here, you mention to use HOSTCXX to compile .c files
such as cyc_complexity_plugin.c, sancov_plugin.c, etc.

This is not straight-forward.  It is worthwhile to comment the reason.


-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]

#1393829

FromEmese Revfy <re.emese@gmail.com>
Date2016-05-03 23:30 +0200
Message-ID<ruQ3f-7p9-5@gated-at.bofh.it>
In reply to#1392981
On Tue, 3 May 2016 11:00:56 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

Hi,

> # Compile .c file, create position independent .o file
> # host-cxxshobjs -> .o
> quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
>       cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
>                            $(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
>                            $(call if_changed_dep,host-cxxshobjs)
> 
> 
> 
> 
> We generally use HOSTCC to compile *.c files,
> and HOSTCXX to compile *.cc files.
> 
> 
> But, here, you mention to use HOSTCXX to compile .c files
> such as cyc_complexity_plugin.c, sancov_plugin.c, etc.
> 
> This is not straight-forward.  It is worthwhile to comment the reason.

I wrote a comment about it here:
https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/74f6343a7f13c071e00c417332051e25f15009ea

-- 
Emese

[toc] | [prev] | [next] | [standalone]

#1393941

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-05-04 06:10 +0200
Message-ID<ruWim-4Sa-1@gated-at.bofh.it>
In reply to#1393829
Hi Emese,


2016-05-04 6:29 GMT+09:00 Emese Revfy <re.emese@gmail.com>:
> On Tue, 3 May 2016 11:00:56 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
> Hi,
>
>> # Compile .c file, create position independent .o file
>> # host-cxxshobjs -> .o
>> quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
>>       cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
>>                            $(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
>>                            $(call if_changed_dep,host-cxxshobjs)
>>
>>
>>
>>
>> We generally use HOSTCC to compile *.c files,
>> and HOSTCXX to compile *.cc files.
>>
>>
>> But, here, you mention to use HOSTCXX to compile .c files
>> such as cyc_complexity_plugin.c, sancov_plugin.c, etc.
>>
>> This is not straight-forward.  It is worthwhile to comment the reason.
>
> I wrote a comment about it here:
> https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/74f6343a7f13c071e00c417332051e25f15009ea
>



+# Note that plugin capable gcc versions can be either C or C++ based
+# therefore plugin source files have to be compilable in both C and C++ mode.
+# This is why a C++ compiler is invoked on a .c file.

Thanks.

Please let me confirm if I understood correctly.


We generally have to do something with the name-space conflict
(with 'extern "C"') in the mixture of C/C++.

Depending on the GCC version,
GCC-plugin-related libraries could be built for C or C++.

So, we need to check the GCC version and choose correct one
from C or C++.


Am I right?


-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]

#1395274

FromEmese Revfy <re.emese@gmail.com>
Date2016-05-05 20:40 +0200
Message-ID<rvwlQ-5gq-13@gated-at.bofh.it>
In reply to#1393941
On Wed, 4 May 2016 13:09:05 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

> Hi Emese,
> 
> 
> 2016-05-04 6:29 GMT+09:00 Emese Revfy <re.emese@gmail.com>:
> > On Tue, 3 May 2016 11:00:56 +0900
> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> > Hi,
> >
> >> # Compile .c file, create position independent .o file
> >> # host-cxxshobjs -> .o
> >> quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@
> >>       cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<
> >>                            $(host-cxxshobjs): $(obj)/%.o: $(src)/%.c FORCE
> >>                            $(call if_changed_dep,host-cxxshobjs)
> >>
> >>
> >>
> >>
> >> We generally use HOSTCC to compile *.c files,
> >> and HOSTCXX to compile *.cc files.
> >>
> >>
> >> But, here, you mention to use HOSTCXX to compile .c files
> >> such as cyc_complexity_plugin.c, sancov_plugin.c, etc.
> >>
> >> This is not straight-forward.  It is worthwhile to comment the reason.
> >
> > I wrote a comment about it here:
> > https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/74f6343a7f13c071e00c417332051e25f15009ea
> >
> 
> 
> 
> +# Note that plugin capable gcc versions can be either C or C++ based
> +# therefore plugin source files have to be compilable in both C and C++ mode.
> +# This is why a C++ compiler is invoked on a .c file.
> 
> Thanks.
> 
> Please let me confirm if I understood correctly.
> 
> 
> We generally have to do something with the name-space conflict
> (with 'extern "C"') in the mixture of C/C++.
> 
> Depending on the GCC version,
> GCC-plugin-related libraries could be built for C or C++.
> 
> So, we need to check the GCC version and choose correct one
> from C or C++.

The plugin source files have to be compilable by both versions
because gcc versions 4.5 and 4.6 are compiled by a C compiler,
gcc-4.7 can be compiled by a C or a C++ compiler,
and versions 4.8+ can only be compiled by a C++ compiler.

-- 
Emese

[toc] | [prev] | [next] | [standalone]

#1392986

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-05-03 04:10 +0200
Message-ID<ruxWG-7p8-13@gated-at.bofh.it>
In reply to#1392413
Hi Emese,

2016-05-03 2:56 GMT+09:00 Emese Revfy <re.emese@gmail.com>:
> On Mon, 2 May 2016 14:03:00 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> In the first place,
>> I am wondering if we need to revive this documentation.
>> What this commit is only interested in *.so generation,
>> not host program support.
>
> I agree that we don't need this documentation. I'll remove it.

OK.
Also, rephrase the git-log of this patch.

This patch is almost your original code,
not reverting 62e2210798ed38928ab24841e8b4878a.



-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]

#1393825

FromEmese Revfy <re.emese@gmail.com>
Date2016-05-03 23:20 +0200
Message-ID<ruPTA-7jM-17@gated-at.bofh.it>
In reply to#1391975
On Mon, 2 May 2016 14:03:00 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

Hi,

> > diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean
> > index 55c96cb..e4e88ab 100644
> > --- a/scripts/Makefile.clean
> > +++ b/scripts/Makefile.clean
> > @@ -38,7 +38,8 @@ subdir-ymn    := $(addprefix $(obj)/,$(subdir-ymn))
> >  __clean-files  := $(extra-y) $(extra-m) $(extra-)       \
> >                    $(always) $(targets) $(clean-files)   \
> >                    $(host-progs)                         \
> > -                  $(hostprogs-y) $(hostprogs-m) $(hostprogs-)
> > +                  $(hostprogs-y) $(hostprogs-m) $(hostprogs-) \
> > +                  $(hostlibs-y) $(hostlibs-m) $(hostlibs-)
> 
> $(hostcxxlibs-y)$(hostcxxlibs-m) is missing here.
> 
> 
> BTW, are you planning to support hostlibs without .so extention in the future?
> 
> 
> You are changing the top Makefile to clean with "*.so" pattern rule.
> 
> Do you need to change both the top Makefile and Makefile.clean
> for belt-and-braces cleaning?

It doesn't delete the *.so files without the hunk from the top Makefile. 
The mrproper and distclean targets remove them with this patch:
https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/f23b7eb247ccc9f1007e53313af343980dd52591
But I think this isn't the best solution much like doing it from the top Makefile.

-- 
Emese

[toc] | [prev] | [next] | [standalone]

#1395273

FromEmese Revfy <re.emese@gmail.com>
Date2016-05-05 20:40 +0200
Message-ID<rvwlP-5gq-5@gated-at.bofh.it>
In reply to#1393825
On Tue, 3 May 2016 23:25:27 +0200
Emese Revfy <re.emese@gmail.com> wrote:

> > Do you need to change both the top Makefile and Makefile.clean
> > for belt-and-braces cleaning?
> 
> It doesn't delete the *.so files without the hunk from the top Makefile. 
> The mrproper and distclean targets remove them with this patch:
> https://github.com/ephox-gcc-plugins/gcc-plugins_linux-next/commit/f23b7eb247ccc9f1007e53313af343980dd52591
> But I think this isn't the best solution much like doing it from the top Makefile.

Do you think this patch will be good enough? In this case I can resend the patch set.

-- 
Emese

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web