Re: compiling external modules

From: Axel Weiss (aweiss_at_informatik.hu-berlin.de)
Date: 04/16/04

  • Next message: Arjan van de Ven: "Re: SATA support merge in 2.4.27" 
    To: Sam Ravnborg <sam@ravnborg.org>
Date:	Fri, 16 Apr 2004 14:34:25 +0200

    Hi, Sam,

    excuse me (and forget my previous mail), I've found the reason for the missing
    exported symbols in the C-source.

    I will continue simplifying the Makefile...

    Regards,
    Axel

    On Friday 16 April 2004 14:06, Axel Weiss wrote:
    > Hi, Sam,
    >
    > I have patched to 2.6.6-rc1 (patch-2.6.6-rc1 over kernel 2.6.5 - am I right
    > or am I missing some patches in between?), and now symbol exports between
    > modules fails. An example with two module-objects - one exports some
    > symbols used by the other - shows compile output:
    >
    > scripts/Makefile.build:36: kbuild: /home/axel/freeSP-1.0.4/drivers/linux/
    > adc64/busmaster/Makefile - Usage of export-objs is obsolete in 2.6. Please
    > fix!
    >
    > 8<
    >
    > *** Warning: "adc64_count" [/home/axel/freeSP-1.0.4/drivers/linux/adc64/
    > driver/adc64.ko] undefined!
    > *** Warning: "release_adc64_busmaster"
    > [/home/axel/freeSP-1.0.4/drivers/linux/ adc64/driver/adc64.ko] undefined!
    > *** Warning: "get_adc64_busmaster" [/home/axel/freeSP-1.0.4/drivers/linux/
    > adc64/driver/adc64.ko] undefined!
    >
    > 8<
    >
    > The first (exporting) module loads cleanly (lsmod shows the loaded module),
    > but insmod'ing the second fails with:
    >
    > insmod: error inserting './adc64.ko': -1 Unknown symbol in module
    >
    > What's the trick in 2.6.6?
    >
    > Regards,
    > Axel
    >
    > On Thursday 15 April 2004 23:59, Sam Ravnborg wrote:
    > > On Thu, Apr 15, 2004 at 11:05:49PM +0200, Axel Weiss wrote:
    > > > Hi,
    > > >
    > > > after some study of kernel Makefiles, I'm able now to compile externel
    > > > modules for both, 2.4 and 2.6 kernels correctly. I'd like to share my
    > > > Makefiles here, maybe somebody finds them useful.
    > >
    > > Thanks.
    > >
    > > > 2.6-compilation of drivers consisting of more than one module leaded to
    > > > very ugly warnings from scripts/Makefile.modpost, when make was invoked
    > > > after 'make clean'. The reason were lying-around objects in
    > > > .tmp_versions directory which were not deleted by 'make clean'.
    > > > Solution: clean must explicitly delete the version-object in
    > > > .tmp_versions.
    > >
    > > With 2.6.5-rc1 the warning are gone.
    > >
    > > > 2.4-compilation requires inclusion of Rules.make and an additional rule
    > > > for module-object linkage. In 2.6 Rules.make does not exist, and the
    > > > linking rule would conflict with an already defined one. Solution:
    > > > distinct current kernel version.
    > >
    > > You should be able to use:
    > > -include Rules.make
    > >
    > > See 'info make' - look after the include directive.
    > >
    > > > When I gave the rule:
    > > > clean:
    > > > $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
    > > > the whole kernel tree was cleaned. This is not my intention, when I'm
    > > > working on external modules and want to make clean e.g. for cvs
    > > > commits. So I defined my own clean rule, kicking away everything but
    > > > source files.
    > >
    > > With 2.6.5-rc1 this will only cause files in the $(PWD) dir to be
    > > deleted, not the kernel tree.
    > >
    > > > So far the difficulties. Next I propose an assumption about filenames,
    > > > when a module consists of several objects which will be linked
    > > > together. Let <module-name> be a basic name for the module, so
    > > > <module-name>.(k)o (with k for 2.6, without for 2.4) will be the final
    > > > target. I assume that all elementary object-filenames begin with
    > > > <module-name>, for
    > > > clarification. E.g. the module adc64.ko is composed of adc64_module.o,
    > > > adc64_device.o, adc64_io.o and so on. Generally, the name of an object
    > > > is <module-name>_<object-name>.o, and the object-names can be collected
    > > > in a symbol <module-name>-obj-names. Some objects may export symbols to
    > > > other modules, they can be collected in a <module-name>-exp-names list.
    > >
    > > I really do not see the benefit compared to the current more free
    > > naming scheme - which works.
    > >
    > > > Finally, all the modules' Makefiles were very similar, so I split them
    > > > into two files: one Makefile for every module and a common
    > > > Makefile.module which is included by each Makefile. Each
    > > > module-specific Makefile contains the definition of
    > > > - <module-name>
    > > > - <module-name>-obj-names
    > > > - <module-name>-exp-names
    > > > - EXTRA_CFLAGS
    > > > which makes up all information Makfile.module needs.
    > >
    > > The general feedback is that it looks like you have
    > > made it less simple than it ought to be.
    > >
    > > You should also consider that you end up with files
    > > that does not look like ordinary kbuild makefiles.
    > >
    > > When I get some spare time I will try to come up with a simpler example.
    > >
    > > Sam
    > > -
    > > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
    > > in the body of a message to majordomo@vger.kernel.org
    > > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > > Please read the FAQ at http://www.tux.org/lkml/
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/

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

  • Next message: Arjan van de Ven: "Re: SATA support merge in 2.4.27"

    Relevant Pages

    • Re: Record Layout of Windows Security Event log records ?.
      ... > I noticed 565 was missing, but as you said you'd already found that info ... >> which is applied to the Accesses field. ...
      (microsoft.public.windows.server.security)
    • Link errors building rather simple application which uses C++ IO facilities
      ... [beginning of sample program] ... This is the makefile I am using to build it: ... [beginning of relevant linker output] ... What is missing in my build setting? ...
      (microsoft.public.dotnet.languages.vc)
    • Re: Record Layout of Windows Security Event log records ?.
      ... I now have the record descriptions I need, - and I'll try the tool Paul ... Kind regards from ... >> how they implemented reading the event log records. ...
      (microsoft.public.windows.server.security)
    • makefile delimma
      ... Each of the tasks call a seperate makefile. ... Each of these individual tasks are dependant of several files within a ... one to run and one to report missing data. ... So I need to have wrappers that will take unvalidated input. ...
      (comp.unix.programmer)
    • Re: Look up sheet name determined in cell
      ... Here is the correction: ... > Perhaps I am missing something but when I try to use your formula it says ... >> Regards, ... >> Tom Ogilvy ...
      (microsoft.public.excel.programming)