Error making - code model kernel does not support PIC mode

[ctgreybeard]

When attempting to make the module I get:

make -C /lib/modules/4.15.0-20-generic/build M=/home/bill/Projects/intel_nuc_led modules
make[1]: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
  CC [M]  /home/bill/Projects/intel_nuc_led/nuc_led.o
cc1: error: code model kernel does not support PIC mode
scripts/Makefile.build:339: recipe for target '/home/bill/Projects/intel_nuc_led/nuc_led.o' failed
make[2]: *** [/home/bill/Projects/intel_nuc_led/nuc_led.o] Error 1
Makefile:1552: recipe for target '_module_/home/bill/Projects/intel_nuc_led' failed
make[1]: *** [_module_/home/bill/Projects/intel_nuc_led] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
Makefile:8: recipe for target 'default' failed
make: *** [default] Error 2

This is a new install on a NUC7i5BNH with Ubuntu Server 18.04.

╰─➤  uname -a
Linux hyrule 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[milesp20]

@ctgreybeard Can you add this extra CFLAG to the Makefile and try compiling?

-fno-pie

[ahmebane]

Will do. On your fix re: strsep(), where is the memory leak coming from? The value of input is not changed by strsep(), only the memory it points to. I will give it a test this morning & let you know. When I build with kmalloc()/kfree() the leak was reduced by a factor of about 1000.

…

On Mon, May 7, 2018 at 6:57 PM, milesp20 ***@***.***> wrote: @ctgreybeard <https://github.com/ctgreybeard> Can you add this extra CFLAG to the Makefile and try compiling? -fno-pie — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYOCG1nfq5ETMesrbkk5xhieAL4gN-ZQks5twPuPgaJpZM4T0DW1> .

[ahmebane]

Upon further reading if the strsep() doc, I see it does store back into the input pointer! What I did was just save the pointer when allocated, then use that saved value in the free(). There is one slight spot where a leak can occur, and thats if copy_from_user() fails for some reason. Its a small corner case admittedly. :) Thanks for writing the driver! Its a nice piece of work.

…

On Tue, May 8, 2018 at 8:39 AM, Holt Mebane ***@***.***> wrote: Will do. On your fix re: strsep(), where is the memory leak coming from? The value of input is not changed by strsep(), only the memory it points to. I will give it a test this morning & let you know. When I build with kmalloc()/kfree() the leak was reduced by a factor of about 1000. On Mon, May 7, 2018 at 6:57 PM, milesp20 ***@***.***> wrote: > @ctgreybeard <https://github.com/ctgreybeard> Can you add this extra > CFLAG to the Makefile and try compiling? > > -fno-pie > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#10 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AYOCG1nfq5ETMesrbkk5xhieAL4gN-ZQks5twPuPgaJpZM4T0DW1> > . >

[ctgreybeard]

@milesp20 Adding that flag did get me farther but I'm now running into some includes that I don't have yet. It started with stdargs.h iirc and went from there. I am thinking that the Server edition isn't intended to be a dev machine. I decided to use that one because I didn't want the gui baggage. Maybe I'll spin up a desktop version to do the build on.

But if you know which packages I will need then that would be helpful.

Bill