modules out of tree issue

modules out of tree issue

[Hänel-Baas, Alexander]

Hi,
no idea what is going wrong, when i include the output path in obj-m variab=
le?=20

obj-m :=3D out/alex.o                                              <-- work=
s not under 3.18 but in older versions
out/alex-y :=3D internal/src/sm36502_uio.o=20

obj-m :=3D alex.o                                                       <--=
 works
alex-y :=3D internal/src/sm36502_uio.o

I found a diff in /scripts/Makefile.build=20

$(multi-used-m): FORCE                                             <- kerne=
l 3.18
$(multi-used-m) : %.o: $(multi-objs-m) FORCE <- kernel 3.17.8

I'm not sure but the dependencies are lost???=20

When I set $(multi-used-m): FORCE  to  $(multi-used-m) : %.o: $(multi-objs-=
m) FORCE in the 3.18/scripts/makefile.build, all my external modules make f=
iles are lucky.

I hope that helps to find out what is going wrong and we find a solution ho=
w I can use a outputdir in the obj-m variable.

---
Alexander=20

modules out of tree issue

[Hänel-Baas, Alexander]

Hi Lucas

i have played with the make files and find out that the problem is the
OUTDIR setting in the TARGET.

makefile:
OUTDIR=3Dout/
SOURCES =3D internal/src/sm36502_uio.o
TARGET=3D${OUTDIR}alex                                <-- works not

OBJECTS :=3D $(SOURCES:.c=3D.o)
obj-m :=3D $(TARGET).o
$(TARGET)-y :=3D $(OBJECTS)

This works NOT at Kernel 3.18 but with older kernels

I miss the compile state and get:
sm@debianVM:~/temp/ARMg3k036502Uio$ make
make  ARCH=3Darm CROSS_COMPILE=3D/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3Xeno=
ArmImx.Bsp.V2/selected_toolchain/arm-v7a-linux-gnueabi- -C /opt/g3DevelBase=
/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-=
3.18 M=3D$PWD  modules
make[1]: Entering directory `/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmI=
mx.Bsp.V2/platform-sm-arm/build-target/linux-3.18'
LD [M]  /home/sm/temp/ARMg3k036502Uio/out/alex.o
/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/selected_toolchain/=
arm-v7a-linux-gnueabi-ld: no input files

Without given OUTDIR in TARGET it works.

makefile:
SOURCES =3D internal/src/sm36502_uio.o
TARGET=3Dalex                                                      <--NO  p=
roblem

OBJECTS :=3D $(SOURCES:.c=3D.o)
obj-m :=3D $(TARGET).o
$(TARGET)-y :=3D $(OBJECTS)

sm@debianVM:~/temp/ARMg3k036502Uio$ make
make  ARCH=3Darm CROSS_COMPILE=3D/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3Xeno=
ArmImx.Bsp.V2/selected_toolchain/arm-v7a-linux-gnueabi- -C /opt/g3DevelBase=
/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-=
3.18 M=3D$PWD  modules
make[1]: Entering directory `/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmI=
mx.Bsp.V2/platform-sm-arm/build-target/linux-3.18'
CC [M]  /home/sm/temp/ARMg3k036502Uio/internal/src/sm36502_uio.o
  LD [M]  /home/sm/temp/ARMg3k036502Uio/alex.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/sm/temp/ARMg3k036502Uio/alex.mod.o
  LD [M]  /home/sm/temp/ARMg3k036502Uio/alex.ko

Then I played with kernelversion too:
3.17.8 works with my OUTDIR in TARGET
3.18 works not

I found a diff in /scripts/Makefile.build=20

@@ -386,7 +386,7 @@
               $(call if_changed,link_multi-y)
$(call multi_depend, $(multi-used-y), .o, -objs -y)

+$(multi-used-m): FORCE
-$(multi-used-m) : %.o: $(multi-objs-m) FORCE
               $(call if_changed,link_multi-m)
               @{ echo $(@:.o=3D.ko); echo $(link_multi_deps); } > $(MODVER=
DIR)/$(@F:.o=3D.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y)

I'm not sure but the dependencies are lost???=20

When I set $(multi-used-m): FORCE  to  $(multi-used-m) : %.o: $(multi-objs-=
m) FORCE in the makefile.build,
all my modules make files are lucky.

I hope that helps to find out what is going wrong and we find a solution ho=
w I can
use a outputdir in the makefile.


---
Alexander=20

modules out of tree issue

[Hänel-Baas, Alexander]

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hi Lucas

i have played with the make files and find out that the problem is the
OUTDIR setting in the TARGET.

makefile:
OUTDIR=out/
SOURCES = internal/src/sm36502_uio.o
TARGET=${OUTDIR}alex                                <-- works not

OBJECTS := $(SOURCES:.c=.o)
obj-m := $(TARGET).o
$(TARGET)-y := $(OBJECTS)

This works NOT at Kernel 3.18 but with older kernels

I miss the compile state and get:
sm@debianVM:~/temp/ARMg3k036502Uio$ make
make  ARCH=arm CROSS_COMPILE=/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/selected_toolchain/arm-v7a-linux-gnueabi- -C /opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-3.18 M=$PWD  modules
make[1]: Entering directory `/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-3.18'
LD [M]  /home/sm/temp/ARMg3k036502Uio/out/alex.o
/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/selected_toolchain/arm-v7a-linux-gnueabi-ld: no input files

Without given OUTDIR in TARGET it works.

makefile:
SOURCES = internal/src/sm36502_uio.o
TARGET=alex                                                      <--NO  problem

OBJECTS := $(SOURCES:.c=.o)
obj-m := $(TARGET).o
$(TARGET)-y := $(OBJECTS)

sm@debianVM:~/temp/ARMg3k036502Uio$ make
make  ARCH=arm CROSS_COMPILE=/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/selected_toolchain/arm-v7a-linux-gnueabi- -C /opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-3.18 M=$PWD  modules
make[1]: Entering directory `/opt/g3DevelBase/g3Toolchain/g3Bsp/sd3XenoArmImx.Bsp.V2/platform-sm-arm/build-target/linux-3.18'
CC [M]  /home/sm/temp/ARMg3k036502Uio/internal/src/sm36502_uio.o
  LD [M]  /home/sm/temp/ARMg3k036502Uio/alex.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/sm/temp/ARMg3k036502Uio/alex.mod.o
  LD [M]  /home/sm/temp/ARMg3k036502Uio/alex.ko

Then I played with kernelversion too:
3.17.8 works with my OUTDIR in TARGET
3.18 works not

I found a diff in /scripts/Makefile.build

@@ -386,7 +386,7 @@
               $(call if_changed,link_multi-y)
$(call multi_depend, $(multi-used-y), .o, -objs -y)
+$(multi-used-m): FORCE
-$(multi-used-m) : %.o: $(multi-objs-m) FORCE
               $(call if_changed,link_multi-m)
               @{ echo $(@:.o=.ko); echo $(link_multi_deps); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y)

I'm not sure but the dependencies are lost???

When I set $(multi-used-m): FORCE  to  $(multi-used-m) : %.o: $(multi-objs-m) FORCE in the makefile.build,
all my modules make files are lucky.

I hope that helps to find out what is going wrong and we find a solution how I can
use a outputdir in the makefile.


With best regards,
Alexander


[-- Attachment #2: Type: text/html, Size: 10199 bytes --]

Re: modules out of tree issue

[Lucas De Marchi]

Hi,

On Thu, Apr 16, 2015 at 6:41 AM, H=C3=A4nel-Baas, Alexander
<alexander.haenel-baas@sieb-meyer.de> wrote:
> Hi,
>
> I cross compile my own kernelmodule out of tree.
> Now I changed the kernel to 3.18.1 and when I compile my own module I get=
 the error:
> -ld: no input files

could you share your makefile? otherwise it's difficult to say what's happe=
ning.


> The first call is the ld and not the compiler. This is the problem.
>
> With kernel 3.14 and older always compiled good.
>
> Is there any changes in the kernel makefile to build the kernel out of tr=
ee?

Not that I'm aware of.  I compile out-of-tree modules just fine. See
https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/tree/testsuite/modul=
e-playground/Makefile
for an example.


> Any ideas?
>
> I'm not sure is this the right group, sorry.

You probably should CC lkml as well. Doing it now.


--=20
Lucas De Marchi

modules out of tree issue

[Hänel-Baas, Alexander]

Hi,

I cross compile my own kernelmodule out of tree.
Now I changed the kernel to 3.18.1 and when I compile my own module I get the error:
-ld: no input files

The first call is the ld and not the compiler. This is the problem.

With kernel 3.14 and older always compiled good.

Is there any changes in the kernel makefile to build the kernel out of tree?
Any ideas?

I'm not sure is this the right group, sorry.

With best regards,
Alexander H�nel-Baas