kbuild: LDFLAGS_MODULE unusable for external module builds (2.6.23-rc2)
Henry Nestler
> kbuild: use LDFLAGS_MODULE only for .ko links
>
> Sam Ravnborg pointed out that Documentation/kbuild/makefiles.txt already
> says this is what it's for. This patch makes the reality live up to the
> documentation. This fixes the problem of LDFLAGS_BUILD_ID getting into too
> many places.
LDFLAGS_MODULE is not usable in module build out of kernel tree since
2.6.23-rc2. LDFLAGS_$@ should use, but does never work. - Not for
external module builds with the option "M=..."
What macro should set for linker parameters of foo.o ? I'm not shure.
Currently found, that only LDFLAGS is usable. But, found LDFLAGS in
modpost calls, there also exist a --start-group/--end-group. Is it right
to use it for external module?
Here examples and the outputs. Host and target is an i686 SMP Linux.
mkdir /tmp/test; cd /tmp/test
cat >Makefile <<EOF
obj-m := name.o
name-objs := foo.o
# Use multipe defines, hope any would work
LDFLAGS_MODULE += --start-group
LDFLAGS_name += --start-group
LDFLAGS_name.o += --start-group
EOF
cat >foo.c <<EOF
#include <linux/module.h>
#include <linux/init.h>
int init_module(void) {return 0;}
void cleanup_module(void) {return;}
EOF
#2.6.22 works. LDFLAGS_MODULE was used:
make V=1 -C src/linux-2.6.22 M=$PWD | grep " ld "
ld -m elf_i386 -m elf_i386 -r --start-group -o /tmp/name.o /tmp/foo.o
ld -m elf_i386 -m elf_i386 -r -o /tmp/name.ko /tmp/name.o /tmp/name.mod.o
#2.6.23-rc7 does not work. Nothing from LDFLAGS can seen in linker line:
make V=1 -C src/linux-2.6.23-rc7 M=$PWD | grep " ld "
ld -m elf_i386 -m elf_i386 -r -o /tmp/name.o /tmp/foo.o
ld -m elf_i386 -r -m elf_i386 -o /tmp/name.ko /tmp/name.o
/tmp/name.mod.o
------
Perhaps anybody can give better idea for Makefile with
recursive depens of libraries? What I'm missing, is a setup for
--start-group AND the --end-group arrount the lib.a files. Currently
--start-groups is somether before the first object and has no --end-group.
obj-y := dir1/ dir2/ dir3/
obj-m := name.ko
name-objs = foo.o dir1/lib.a dir2/lib.a dir3/lib.a
LDFLAGS += --start-group # Deal with recursive depens of libraries
--
Henry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sam Ravnborg
On Tue, Sep 25, 2007 at 11:49:44AM +0200, Henry Nestler wrote:
> In reference of git 114f51577724b782a30f4f5ceaee9880de93d776:
> > kbuild: use LDFLAGS_MODULE only for .ko links
> >
> > Sam Ravnborg pointed out that Documentation/kbuild/makefiles.txt
> > already
> > says this is what it's for. This patch makes the reality live up to
> > the
> > documentation. This fixes the problem of LDFLAGS_BUILD_ID getting
> > into too
> > many places.
>
> LDFLAGS_MODULE is not usable in module build out of kernel tree since
> 2.6.23-rc2. LDFLAGS_$@ should use, but does never work. - Not for
> external module builds with the option "M=..."
LDFLAGS_MODULE are reserved for architectures and modules be external
or not should never ude LDFLAGS_MODULE.
And LDFALGS_$@ have never been documented to work for modules - dunno
where you have that from.
IIRC we only use LDFALGS_$@ in the ld macro to be used by bootloaders.
>
> What macro should set for linker parameters of foo.o ? I'm not shure.
Have you read:
Documentation/kbuild/makfilefiles.txt?
Here it is documented how to use the relevant variables.
> Currently found, that only LDFLAGS is usable. But, found LDFLAGS in
> modpost calls, there also exist a --start-group/--end-group. Is it right
> to use it for external module?
LDFLAGS are a kernel wide variable. Modules shall not fiddle with it!
From your description you want to add a specific set of options to
the linker in a specific Kbuild file.
This is what EXTRA_LDFLAGS are present to help you with.
As for the:
> # Deal with recursive depens of libraries
I am not sure what you mean (despite yout comprehensive description).
Please try if EXTRA_LDFLAGS := --start-group lib.a --end-group
will solve your need.
I'm afraid not due to the placement of the --start-group --end-group.
If this does not help you please give me specific examples of how
the ld command-line should be then I can see how we tweak kbuild
to help you.
Sam
Henry Nestler
Sam Ravnborg wrote:
> Hi Henry.
>
> On Tue, Sep 25, 2007 at 11:49:44AM +0200, Henry Nestler wrote:
>> In reference of git 114f51577724b782a30f4f5ceaee9880de93d776:
>>> kbuild: use LDFLAGS_MODULE only for .ko links
>>>
>>> Sam Ravnborg pointed out that Documentation/kbuild/makefiles.txt
>>> already
>>> says this is what it's for. This patch makes the reality live up to
>>> the
>>> documentation. This fixes the problem of LDFLAGS_BUILD_ID getting
>>> into too
>>> many places.
>> LDFLAGS_MODULE is not usable in module build out of kernel tree since
>> 2.6.23-rc2. LDFLAGS_$@ should use, but does never work. - Not for
>> external module builds with the option "M=..."
>
> LDFLAGS_MODULE are reserved for architectures and modules be external
> or not should never ude LDFLAGS_MODULE.
> And LDFALGS_$@ have never been documented to work for modules - dunno
> where you have that from.
> IIRC we only use LDFALGS_$@ in the ld macro to be used by bootloaders.
>
>> What macro should set for linker parameters of foo.o ? I'm not shure.
> Have you read:
> Documentation/kbuild/makfilefiles.txt?
Yes. This was a *very* helpfull. And many examples spokes about
LDFLAGS_$@ there. Not directly described for modules.
>>From your description you want to add a specific set of options to
> the linker in a specific Kbuild file.
> This is what EXTRA_LDFLAGS are present to help you with.
>
> As for the:
>> # Deal with recursive depens of libraries
> I am not sure what you mean (despite yout comprehensive description).
depens = lib1 has external dependently from lib2, and lib2 later depends
on externals from lib1. The main problem is, how can add multiple lib.a
to module?
> Please try if EXTRA_LDFLAGS := --start-group lib.a --end-group
> will solve your need.
isn't usable. There I have problems with dependencies. dir/lib.a would
not build, if lib.a is not in the list "...-objs".
> I'm afraid not due to the placement of the --start-group --end-group.
> If this does not help you please give me specific examples of how
> the ld command-line should be then I can see how we tweak kbuild
> to help you.
An abstracted Makefile shows:
obj-y := dir1/ dir2/ dir3/
obj-m := name.ko
name-objs = foo.o dir1/lib.a dir2/lib.a dir3/lib.a
EXTRA_LDFLAGS := --start-group # recursive dependencies of libraries
From short testing was seen the flags ok. The current project Makefile
is in [1]. I will try "EXTRA_LDFLAGS := --start-group" without the
end-group in the project tree and mail again. Thanks for your help.
--
Henry
Sam Ravnborg
> >Have you read:
> >Documentation/kbuild/makfilefiles.txt?
>
> Yes. This was a *very* helpfull. And many examples spokes about
> LDFLAGS_$@ there. Not directly described for modules.
Took a deeper look.
I saw one reference to LDFLAGS_$@ that is wrong:
LDFLAGS Generic $(LD) options
Flags used for all invocations of the linker.
Often specifying the emulation is sufficient.
Example:
#arch/s390/Makefile
LDFLAGS := -m elf_s390
Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise
the flags used. See chapter 7.
The chapter reference is also bad...
The other references to the LDFLAGS_$@ are in other situations - it is
used in several places.
If your example requires the LDFALGS_$@ I wil introduce it - for now
it has not been required (except for vdso support where it was hacked).
Sam
Henry Nestler
Sam Ravnborg wrote:
>>>> What macro should set for linker parameters of foo.o ? I'm not shure.
>>> Have you read:
>>> Documentation/kbuild/makfilefiles.txt?
>> Yes. This was a *very* helpfull. And many examples spokes about
>> LDFLAGS_$@ there. Not directly described for modules.
>
> Took a deeper look.
> I saw one reference to LDFLAGS_$@ that is wrong:
> LDFLAGS Generic $(LD) options
>
> Flags used for all invocations of the linker.
> Often specifying the emulation is sufficient.
>
> Example:
> #arch/s390/Makefile
> LDFLAGS := -m elf_s390
> Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise
> the flags used. See chapter 7.
>
> The chapter reference is also bad...
> The other references to the LDFLAGS_$@ are in other situations - it is
> used in several places.
>
> If your example requires the LDFALGS_$@ I wil introduce it - for now
> it has not been required (except for vdso support where it was hacked).
I will check EXTRA_LDFLAGS compatibilities with older kernel versions.
Than I come back with results. Currently I no need LDFLAGS_$@.
--
Henry
Henry Nestler
Henry Nestler wrote:
> Sam Ravnborg wrote:
>>>>> What macro should set for linker parameters of foo.o ? I'm not shure.
>>>> Have you read:
>>>> Documentation/kbuild/makfilefiles.txt?
>> [...]
>>
>> If your example requires the LDFALGS_$@ I wil introduce it - for now
>> it has not been required (except for vdso support where it was hacked).
>
> I will check EXTRA_LDFLAGS compatibilities with older kernel versions.
> Than I come back with results. Currently I no need LDFLAGS_$@.
>
Ok, EXTRA_LDFLAGS is good. I use it now.
To explain, a full example: function2 to function4 will be locate in
alternated directories A, B and than A again. Without --start-group,
function4 would be missing. That's why we need it.
>>> cat testing.sh >>>
rm -rf /tmp/test; mkdir /tmp/test; cd /tmp/test
mkdir A B
cat >Makefile <<EOF
obj-y := A/ B/
obj-m := module.o
module-objs := file1.o A/lib.a B/lib.a
EXTRA_LDFLAGS := --start-group # Solve circular references in archives
EOF
cat >A/Makefile <<EOF
lib-m := file2.o file4.o
EOF
cat >B/Makefile <<EOF
lib-m := file3.o
EOF
cat >file1.c <<EOF
#include <linux/module.h>
#include <linux/init.h>
void function2(void);
int init_module(void) {function2(); return 0;}
void cleanup_module(void) {return;}
EOF
cat >A/file2.c <<EOF
void function3(void);
void function2(void) {function3();}
EOF
cat >B/file3.c <<EOF
void function4(void);
void function3(void) {function4();}
EOF
cat >A/file4.c <<EOF
#include <linux/module.h>
void function4(void) {printk("done\n");}
EOF
make V=1 -C $HOME/kernel/linux-2.6.git2-smp-repg M=$PWD | grep " ld "
<<< end testing.sh <<<
Output is:
ld -m elf_i386 -m elf_i386 --start-group -r -o /tmp/test/built-in.o
/tmp/test/A/built-in.o /tmp/test/B/built-in.o
ld -m elf_i386 -m elf_i386 --start-group -r -o /tmp/test/module.o
/tmp/test/file1.o /tmp/test/A/lib.a /tmp/test/B/lib.a
ld -m elf_i386 -r -m elf_i386 -o /tmp/test/module.ko
/tmp/test/module.o /tmp/test/module.mod.o
Currently can not put lib.a into EXTRA_LDFLAGS, because "--start-group
.. lib.a --end-group" would bring the lib.a before the object list,
with more problems. The other is the path, that this needs. Example:
cat >Makefile <<EOF
obj-y := A/ B/
obj-m := module.o
module-objs := file1.o
EXTRA_LDFLAGS := --start-group \$(KBUILD_EXTMOD)/A/lib.a
\$(KBUILD_EXTMOD)/B/lib.a --end-group
EOF
Result from the make and grep ld:
ld -m elf_i386 -m elf_i386 --start-group /tmp/test/A/lib.a
/tmp/test/B/lib.a --end-group -r -o /tmp/test/module.o /tmp/test/file1.o
WARNING: "function2" [/tmp/test/module.ko] undefined!
Idea for future:
An 'APPEND_LDFLAGS' would be nice to append flags behind the last .o
object. Than can be close the group with --end-group.
Exactly linker call would be with grouping only archives, and the group
block behind the last object, for example:
ld -m elf_i386 -r -o module.o file1.o --start-group A/lib.a B/lib.a
--end-group
But remember: We can very good live with EXTRA_LDFLAGS, it's usable in
all 2.6 kernels.
Many thanks.
Sam Ravnborg
Snipped a very detaild an good example...
Thanks for your comprehensive feedback on this topic.
>
> Idea for future:
> An 'APPEND_LDFLAGS' would be nice to append flags behind the last .o
> object. Than can be close the group with --end-group.
>
> Exactly linker call would be with grouping only archives, and the group
> block behind the last object, for example:
> ld -m elf_i386 -r -o module.o file1.o --start-group A/lib.a B/lib.a
> --end-group
>
> But remember: We can very good live with EXTRA_LDFLAGS, it's usable in
> all 2.6 kernels.
As there is no dire need for it now I will not add EXTRA_APPEND_LDFLAGS.
But I will keep your suggestion in mind should it be useful to solve the
hackish use in the vdso Makefile's.
Thanks for your feedback and do not hesistate to ask if you run into
additional troubles in the future.
Sam